So the OpenFrame DEF template from : • https://github.com/efabless/openframe_timer_example • https://github.com/efabless/caravel_openframe_project • https://github.com/RTimothyEdwards/caravel_openframe_project/ are all different from each other ... So which one is right ? ( cc @Kareem Farid @Tim Edwards)

I would not trust the one in my own repository to be up-to-date, since I passed the whole thing on to Kareem to fix up the timing for sign-off and tape-out. There were some early and incorrect versions of the DEF file that were missing some pins; make sure the pin count in the DEF file is 917. Also, there is more than one DEF file in some cases; in

openframe_timer_example

there is one in

def/

which is the output from openlane and contains the project macros. The one that is the input to openlane is in

openlane/openframe_project_wrapper/fixed_dont_change

. At a glance, the ones in

caravel_openframe_project

and

openframe_timer_example

appear to be the same except that the power nets in

openframe_timer_example

have been tagged with

SPECIAL

and

USE

, and their location in the NETS list is ordered differently between the two. Since the tagging would have been done on purpose, I assume that

openframe_timer_example

is probably the better one to use.

Yeah, I'm looking only at the templates one from

fixed_dont_change

. the one from

efabless/caravel_openframe_project

only has 914 pins so I guess it's old. And yeah looks like the one from

openframe_timer_example

is the most "correct" one, with pins markes properly as power and also the multiple pins for the same net are grouped which seems to make the parser happier.

Are you confirming that there are LVS issues? The layout in magic marks all ports of the same name with the same port number, so that they should not behave like independent ports in a netlist. But then again, I've had plenty of trouble with ports and LVS. If it really is an issue, one solution might be just to remove the label for any single power supply from all but the one(s) you're connecting to. I'm pretty sure this was somehow made to work for the example designs, which we taped out (at least my openframe example project got taped out).

Mmm ... ATM I'm not yet connecting the rings I have to the pins and this is throwing more LVS errors than I expected for just that error, hence why I think this was an issue, but maybe I'll solve that by somehow connecting the rings to the port and then see if that fixes all the LVS errors.

I did manage to get the openlane team to figure out a workable solution where each of the power supply connections was done through a macro, which is why there are layouts for subcells

vccd1_connection

and

vssd1_connection

. This is, as far as I know, the proper/preferred way to hook up all power supplies. I was trying to avoid the method used for caravel with a power ring around the project wrapper that has to match exactly between the project and the caravel chip, so that the openframe version would be more flexible.

But those macro also require the ring to be in exactly the same place as the expected one or they don't connect properly.

@tnt @Tim Edwards I initially worked on openframe but others resumed the work. I think either @Mohamed Hosni Abdalmonem or @Marwan Abbas can better provide guidance in the matter.

What I'm doing now is : • The power pins are copied from the template when applying the DEF template • I have a custom ODB script that runs after pdn gen that will check for any power pins if there is a matching PDN ring and if so it will create the appropriate strip and via to wire them together What you end up with is very similar to what the macro does in the example but it will automatically adapt to changing template and also to different PDN ring configurations.

@tnt: You appear to have a really nice solution set up there. . .

Yeah, it's not perfect (like it won't handle power pins on top/bottom because then it needs to go from

met3

to

met5

) but that can be added if ever needed. One things I'm still a bit worried about in OpenFrame is that with caravel and the gpio block near each pad, there was a nice

_16

strength buffer driving the output signal (it has to go a long way ....). But my understanding here is that it's directly the

gpiopadv2

driving that and not sure what kind of drive strength it has.

You mean from the GPIO pad's

in

signal into the chip core? I checked, and it's connected in the pad to W=6um, L=0.25um nMOS and W=12um, L=0.25um pMOS, vs. a

buf_16

which is W= 10.4um, L=0.15um nMOS; so W/L for nMOS is 24 in the pad and 69 for the buffer, or about 1/3 the drive strength in the pad vs. the buffer.

@Tim Edwards Yes, exactly what I meant, thanks for checking !