open-source-silicon.dev

Thanks <@U016HU5HK8V>, Can you share a DEF + script to replicate the issue ?

You might have to guide me on where to find that :sweat_smile:

In openroad, it should be in one of the results folder. I am not sure where they sit in openlane. <@U01634FSETZ> Do you know where I could find the DEF for his experiemnt?

Well I have plenty of DEF at various stages of the process.

Okay, I need the one after TritonRoute and after global route

<https://people.osmocom.org/~tnt/stuff/sky130/usb-run.tar.bz2>

So this contains the whole `runs`  folder with all scripts / config / intermediate results.

`/results/routing/usb_sky130.def` is after TritonRoute

<@U016HU5HK8V> I will fwd this internally to the person in charge and let you know

Looking at it, it just seems like those diodes shouldn't be there in the first place and diode insertion is done by OpenLane right ? not OpenRoad.

The two are using the same tools. As mentionned earlier, this will happen after antenna repair

and the diode are inserted next to the sink

I don't think Macros are handled correctly

Well I'd expect it anywhere else really :stuck_out_tongue:  There are no macro pins near where the diode is placed. And those are SRAM macros, at this point in the flow it would have no clue if there is a transistor gate connected there.

Really I'd want to tell it : don't worry about it and assume the macro has internal diodes if  it needs them.

Ok but how would you fix the natenna error later on

Always have diodes on input pins of your macros ?

I mean it has no idea what's in there and how much internal metal there is right ?

so seems like the only safe way would be for the macro to ensure it always has diodes on its inputs.

Normally in the LEF file there is gate antenna ratio or DIFF antenna ration porperties

and that's how the antenna error is detected and fixed

I still did not look at the testcase but can you see if the diodes are inserted for each pin?

There are `ANTENNAGATEAREA` for all input pins of the macros.

(all the same value though which is a bit suspicious)

probably because all inputs are connected to the same instances (FF or buffer) which has the same ratio

I guess in this particular instance, it'd be easier to handle this by forcing layer change having a small jumper to a high layer to break the antenna near the macro pin.

Yes, adding a jumper would work but it is not fully supported I think.