https://open-source-silicon.dev logo
Join Slack
Powered by
Hi. So I'm trying (through openlane2 but with a bu...
# openroad
t
Hi. So I'm trying (through openlane2 but with a bunch of custom tcl / odb py) to have a macro in my design powered through a power switch. But if I try to feed in a verilog netlist with the 
VPWR
of the macro connected through my switch, those net are markes as 
SIGNAL
which ends up not working at various places. So I guess my input verilog shouldn't have the power connections at all, but then how can I define that my macro shouldn't be connected to VPWR (I can do the actual routing myself in a odb routing script, I just need the connection to be marked as such so that tools "see" t should be connected).
m
@Matt Venn did you get something to work like this? @tnt Is the power switch inside the macro or outside?
t
@Mitch Bailey It's outside.
(and this is for TinyTapeout. Last time @Matt Venn used it, he basically hacked the GDS manually and disabled LVS and other things to make it go through )
m
I was thinking about putting the power switch inside the macro. Can you do that? Basically adding another hierarchy level with the power switch encapsulated with the macro. The openroad router will only see the external power connections to the switch. The inner macro power would be “hidden” within the outer macro.
t
No because the idea is that the users provide a GDS ... we can't trust they'll put the power switch in there.
Or we'd need like a magic script that would from the user GDS combine it with the power switch ... Not impossible, but it's also not going to be trivial in the current infrastructure we have.
m
Can you use openlane to wire the macro/power switch combination? At the macro level, use VPWR and VGND as normal power rails, but at the parent level, connect VSWITCH and VGND.
t
I think that'd be more complicated 😅 Because OL is going to want to do a bunch of stuff that I don't want it it when just joining the two macros.
I'm trying now to see if with an odb script I can rewrite the power connection right after pdngen to see if that does the trick.
m
You can disable a lot of the OL stuff - no tap, no fill - and just have it do routing.
t
Thing is I don't want it to do the routing, that's the part I can do easily ...
I just need it to have things connected in the netlist like they should.
m
I apologize, I’m not sure I understand. Doesn’t 
connected in the netlist like they should
= 
routing
?
t
Well for me routing for me means : "Actual geometry drawn that effectively connects them". But just being in the netlist means the 
.v
and the 
.def
has a record that those two pads should be connected and are on the same, but not necessarily any geometry achieving that.
I can draw the geometry myself where I want. (the auto-router doesn't route power nets anyway, they are created by pdngen and getting pdn gen to create what I want would be a nightmare). But I still need to have in the design input DEF a record of what needs to be connected to what for the LVS to pass. And I tried wiring that in the verilog but it doesn't work, you can't use the verilog to route power nets (they get marked as 'SIGNAL' and not 'POWER'). So now, I'm using a custom ODB script that before PDNGen creates the logical connections how they should be. Then PDNGen routes VPWR/VGND of non-switched macros, creating a powergrid and actually connecting things with geometry. And then another custom pass of mine that adds geometry to connect the powerswitch output to the userblock VPWR.
a
Power switch insertion is slowly making its way into OR. The first major step is to support UPF files to specify connections like these, which most of that behavior I believe has been merged to the master branch. The parsing and storage of these properties into OpenDB should be supported. The next step is to find and insert the power switch cells into the design. This hasn't been done yet and isn't expected to be worked on until closer to the end of the year. The last step is to do special routing from the power switch to the mesh or ring for the other power domain. There is a longstanding PR that just got merged in which I'm not sure is the cleanest approach, but it seems to work. Try looking at the sroute command and see if it works for your usecase. It hasn't been well tested yet so it may or may not work for you.
I believe you can also manually override the signal type of a net using 
dbNet::setSigType()
so if a tool does not automatically mark a net as a power/ground (ideally the upf should do this) then you can use an odb tcl command to mark it as such. After that you should be able to use the sroute command to do the routing.
t
Ah thanks, I'll look into that for future TinyTapeouts. ATM I ended up with a pair of custom scripts and it works as I need it.

https://i.imgur.com/4X3952H.png▾

You can see the pairs or VCC/GND straps going all across the chip but only the GND has vias going down to the macro. The VCC goes to the power swithc block on the left and the output of the power switch is then connected to the macro (via the double height strap in the middle).
👍 2
10 Views
Open in Slack
PreviousNext
Powered by