<@U016HU5HK8V> we could have a call later today if...
# openroad
m
@User we could have a call later today if it helps going through the antenna stuff
t
Thanks. But if a fix is coming in openroad to place the diode in the grid rather than outside, I guess I'd have to wait for that first anyway unless you have any other suggestions ?
m
Yes, I think it makes sense to wait for the fix.
@User @User @User Following is the fixed for Sylvain's issue: https://github.com/The-OpenROAD-Project-private/OpenROAD/tree/fr_fix_antennas
r
That's a -private ๐Ÿ˜…
t
@Riking28 @mehdi yeah, I was about to say the same :)
m
Yeah... I tagged @Amr Gouhar since he has access so he could try it or help you guys have this in openlane
a
@mehdi: I don't think niether Ghazy nor I have access to that repository.
m
Oh I see.. I was told efabless has access. I will check.
a
@mehdi: Nope, don't have access either.
t
@mehdi If it's a single patch, can you email it or post it here ?
m
fork*
Can you try it and let me know.
t
Ack, I'll test that.
@mehdi So the
flute3
submodule on that branch points to a commit that doesn't exist in the public repo ... is that an issue or can I use the older
flute3
?
m
@tnt the older
flute3
should be fine.
โœ”๏ธ 1
t
@mehdi Well the good news is that it didn't place diode outside the grids. It went all the way through the flow. The bad news is this ended with :
Copy code
Number of pins violated: 27
Number of nets violated: 24
m
@tnt are those the remaining antenna violations?
t
yes.
m
How many were remaining the previous time?
t
Let me re-do a run changing just the diode strategy to make sure it's the only variable.
a
@tnt: you can try increasing
::env(GLB_RT_MAX_DIODE_INS_ITERS)
t
@Amr Gouhar Ah thanks I'll give that a shot too.
@mehdi @Amr Gouhar So with "Spray" stragery (
1
), I get
5 pin / 5 net
violations. When increasing
GLB_RT_MAX_DIODE_INS_ITERS
to
5
then I get
38 pin / 35 net
๐Ÿ˜•
a
@tnt: Then, it's a tradeoff between area and number of antenna violations. But it's interesting that the diveregence avoidance during the iterations didn't work... Can you check the log files for each iteration and confirm that it did choose the DEF file with the lowest antenna violations (or share your testcase).
t
@Amr Gouhar yeah, the increase was probably due to slight change in density ... the spray method wouldn't route so I had to tweak it. Trying now on the complete design (previous was just a reduced one) which has more free room ... but doesn't look promising, the fast route finished with still antenna violations reported.
yeah indeed fina checks reports plenty of error ๐Ÿ˜•

https://i.imgur.com/in8aigT.pngโ–พ

Design has plenty of free space.
Most of the failure seem to happen on input pins basically.
(input to the whole design I mean).
But something more worrying is that it also breaks LVS ๐Ÿ˜•
m
@tnt 24 antenna violations isn't that bad tbh
t
I thought we were supposed to get to 0 for submission.
m
we are working on making a heuristic loop that would fix all the violations but I am not sure about the timeline
yes we have to have 0 antenna I think
r
Fab tweaks can happen after nov30 I think
There are unimplemented drc rules and somebody's going to hit them
m
@tnt What is the status on this? Sorry I have a few deadlines coming and lost track on this
t
The branch you pointed to does indeed places diode on the grid now, but (1) still plenty of violations left and (2) when running multiple iterations it does very bad things : https://app.slack.com/client/T01699QAZBQ/C016H8WJMBR/thread/C016ULUQXDF-1606339001.245400
(see the thread in channel, not as replies)
m
Thanks, checking. I am suspecting the extra legalization after each iteration is creating issues.
@User Sorry I have had a couple deadlines this week. Could you please check: https://github.com/eder-matheus/OpenROAD/tree/fr_repair_antennas There is an option to set the number of iterations in the Tcl script, so these weird things are not supposed to happens. The new syntax of repair_antennas isย 
repair_antennas diode_name iterations
ย . Example for sky130: repair_antennas sky130_fd_sc_hs__diode_2/DIODE 3
t
@mehdi Ok, I'll give that a shot, probably this weekend and report back !
๐Ÿ‘ 1
@mehdi It doesn't build.
There are some missing
#include
I was able to fix, but the OpenDB submodule points to a non-existant / non-public commit. I tried building it with the same commit as OpenROAD master points to but it ends up in error.
m
Ok, will check
t
Mm ... actually ... I think it was some stale swig autogenerated files that didn't get rebuilt automatically.
I mean, the OpenDB commit is definitely not public but ... not sure if it's needed for that branch to work or not.
m
I did not try it with the public stuff. But it builds fine
t
I used
7d78630dce0b6b50a091b7ae0ae8d0ffcbf6b38e
for OpenDB instead of the
948108aec398bb418ff46c59b75faf76d39b8140
yeah, deleting the whole build dir and restarting from scratch worked ... it just didn't like just doing an incremental build.
Mmm, looks like something else changed and it doesn't work with the openlane script :
Error: or_route.tcl, 54 Wrong number of arguments :FastRoute::run_fastroute onlySignal  argument 1
m
Ahh.. Still did not use openlane yet. Maybe check with @Ahmed Ghazy what's the best way. I am not close to my machine rn.
t
Is there a documentation of what the new syntax for
FastRoute::run_fastroute
is ?
Obviously it wants some arguments now ...
m
There are documentation on tbe github link I sent you
a
FastRoute::run_fastroute 0
probably?
m
Yes
t
that's what I ended up trying ... run in progress ...
Nope, still screws with the orientation of the cells.
Actually it maybe have flipped them all ...
And again, with a single iteration, I don't get the issue. And this is with the built-in multi iteration thing. I disabled the "while" look in openlane that was manually running fast route several times and modified it to call repair_antenna with the number of iterations directly. It's also "unlocking" placement of some stuff ... like I have the SRAM macros marked as
FIXED
and fastroute puts them as
PLACED
...