Thanks <@U016HU5HK8V>, Can you share a DEF + scrip...
# openlane
Thanks @User, Can you share a DEF + script to replicate the issue ?
You might have to guide me on where to find that 😅
In openroad, it should be in one of the results folder. I am not sure where they sit in openlane. @Amr Gouhar 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
Global Route= Fast Route
+ your scripts for these steps
So this contains the whole
folder with all scripts / config / intermediate results.
is after TritonRoute
Trying to find the one after fast route.
Ah well
@tnt 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
Where would you be expecting the diodes?
is that creating a DRC error
Well I'd expect it anywhere else really 😛 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?
(it shouldn't be the case)
Mmm, you're right.
There are
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.