Let's start a thread with questions for the meeting tomorrow

How reproductible does the build need to be ? For instance, I might need patch to openlane or manual intermediate fixups on def/gds to actually get a design that meets DRC.

Adding to @tnt’s question, I recently updated my openlane branch to latest

develop

which also updated OpenROAD, which for the same config resulted in 10K+ extra DRC violations, no config changes made in between Is the openlane / openROAD verison used to do the automatic precheck going to be fixed and if so, when can we expect it? (hard to patch things if needed otherwise)

remember to record the call for people who can't make it

Any good infos ?

yeah

Does it have to be a single macro or if you have several macro and just need "wiring" between them, can that be done at the top level ?

hm, I should have asked that.

@tnt, @Matt Venn: Yes, you need a single macro named "user_project_wrapper", but you can have as many macros routed in whatever way you like inside. Or do you mean outside the user project area?

I think Sylvain's design is 3 blocks: 2 srams and a usb core. So I think he'll be doing the same that I am. Combining all together like the multiple macro example. Then that final macro is the one we use to replace user_project_wrapper

Yeah one of the block is the usb_core but there will possibly be a couple of smaller one or glue logic but ... given how hard it is to harden the USB ones, once I get a GDS, I'm not touching so I need to integrate it as a pre-made block 😅

@tnt: Sounds good. I imagine the hierarchy would be like that:

user_project_wrapper
    |
    |_ usb_core
    |
    |_ SRAM0
    |
    |_ SRAM1
    |
    |_ some standard cells

Right?

No more like :

user_project_wrapper

@tnt: Got it. I can think of some challenges routing power to usb_core though if you already use metal 5 for its internal power grid.

Well how else am I supposed to do it ?

I'm doing this:

set ::env(DESIGN_IS_CORE) 0

will only generate power stripes on met4.

So you only get the vertical ones ?

on the sub designs. Then when I link them together it uses metal5 for the routing

@tnt: Is there anyway you could restructure it such that the SRAM blocks would be directly under the wrapper?

Well there is always a way but it's a major pain, basically to modify all the verilog files to bring all the signals up to the top level.

The issue is that the SRAM block (the wrapper we created) has two met4 stripes for power connections. If you want to automate that connection, the only way to do it (right now) is to drop vias from met5 from whatever macro that contains it (see the storage area and mgmt_core blocks).

An if I don't do it, wont the top level drop via to those when doing the final route ?

If you don't do that, then you can power usb_core by dropping vias (met5->met4) from the top-level, but then the SRAM blocks wouldn't be powered automatically while hardening usb_core.

Sure, but I'm fine with that.

I can look into an alternative using power rings and drawing it just outside the macro boundaries so that u can still drop vias from above without actually intersecting the macro.

I'm also interested in an easy solution to this. I was thinking of doing a framebuffer/vga driver that I can control from SoC

I mean, I can also manually draw giant power rails on met4 to connect to the vertical rails of the standard grid. (which was my original plan).

@tnt: You can do that as well but adjusting the right PDN pitches/offsets. You can use an interactive script to achieve the second solution as well.

Hm? Are you referring to the horizontal met5 stripe?

Yeah, normally they only go above the standard cell part ... here I forced them to go higher.

This is already possible automatically though?

I have no idea how that worked for them. I actually think it might be because they are vertical ... so they actually have

ROW

covering the whole

Y

span ...

pdngen will only generate the rails where there are ROWS, but it should generate the stripes anyway unless some metal layer is set as an obstruction at https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/openlane/common_pdn.tcl.

It most definitely doesn't.

Hmm, could you compare your custom pdn config with this: https://github.com/efabless/caravel/blob/release/openlane/storage/pdn.tcl?

Yeah I based mine on that : https://pastebin.com/ghkE6CSp

You need

#	connect {{met4_PIN_ver met5}}

uncommented though.

It throws an error if I do that

Oh, I see... Sounds like a wrong assumption there, so if macros block entire rows, they wouldn't be considered.

But in any case what you're saying is I shouldn't have those

met5

horizontal lines anyway so ... doesn't really matter.

Yea, you could set the maximum routing layer to prevent that.

If I have

met4

vertical lines going all the way down, will pdngen connect them to the rails ?

Do you mean a met4 vertical stripe from a top-level block onto the rails of macro inside it?

So, what I was thinking is to manually create in teh DEF before PDN a

met4

vertical stripe that would "continue" the ones already in the macro and that would go all the way to the bottom.

Hm, I see. I guess it only considers its internal data structures, so the created from within.

Ok, so I'd need to do that after PDN and then create the vias through all the layers myself.