https://open-source-silicon.dev logo
Join Slack
Powered by
Going to spend some time trying to reduce antenna ...
# openlane
d
Going to spend some time trying to reduce antenna violation count on my config. If anyone here did this using the exploration scripts, what parameters made the biggest difference? and if you had success with it, were you using absolute or relative sizing for die area?
m
Interested to hear how you get on, I have no idea how to reduce them.
t
How many are we talking about here ?
d
last run was 75 antenna violations, on a design with 27.5K cells
that was after increasing die area and slightly reducing density, diode insertion strategy 1
before that I was getting 80 - 90 or so I think, but that was a significant increase in area to knock off those 10. Not sure if it is related to that change or just coincidence though
t
How many were you getting with strategy 3 ?
d
110+ last time I tried it with 3
t
You can try strategy 3 with multi iterations : 
set ::env(GLB_RT_MAX_DIODE_INS_ITERS) 5
Alternatively you could also try my custom insertion script 😅 I'm cleaning up some rough edges right now and I'll push it to git in an hour or so.
d
yeah I tried dialing ITERS up to 10 just to see what it would do, it did seem to help as the default seems to give up very quickly and it doesn't take that long to run latest config is here after I reverted to 1. I tried updating it with the latest README info in `develop`: https://github.com/dan-rodrigues/caravel-vdp-lite/blob/vdp-lite-clean/openlane/vdp_lite_user_proj/config.tcl
if your script is general enough to run on other projects too, I'll try it out
the impression I get from the chat is that the DRC violations are pretty much known issues in the skywater libs and are gradually being addressed the antenna violations seem more nebulous and I get mixed results with different strategies. I haven't dug too far into the subject though
got another result, went from 75 -> 65 by increasing density in that config from 0.2 to 0.25. Going to dial it up some more and see if it continues falling or starts climbing again
@Matt Venn did you find any patterns with different configs vs. antenna violation counts for your project?
t
Yeah density is a balance. The more dense design is, the shorter the traces tend to be because everything is closer, so less chance of a long trace forming an antenna, but OTOH, the denser things are, the harder it is to place a diode close to where it should be and route it properly.
d
hoping that balanced config can be found eventually. Atleast there aren't any LVS errors, don't remember getting any of those for a while.
t
The script is in 
scripts/place_diodes.py
and needs an interactive script to customize the build flow to call it at the right time (it's the 
interactive.tcl
in the repo). Now obviously that tcl script is a bit too custom, it includes a bunch of other stuff you don't need/want.
This should be a basic custom flow that just adds the diode insertion.
interactive-base.tcl
You need to set DIODE_STRATEGY to 
0
or ... bad things will happen.
To check things faster you can also comment out everything after 
run_routing
until 
run_antenna_check
No need for the GDS / Extraction / DRC / LVS to run the antenna check.
d
cool, going to try this with the basic script soon and will see how it goes
t
🤞
d
Lots of 
[x] skipping small net
logs, seemed to go through with no errors
will see what the end result is in about 10 or 15 minutes I'm guessing
t
Yeah that message is normal. It doesn't bother inserting diodes if it judges the net is small enough that chances are low it's going to form an antenna. I log them so that if an error happens on one of those nets I can tweak the heuristic.
So ... suspense is killing me 😄
d
yeah wow I misjudged that 15 minute estimate...poor old MBP is nearly done, at 
Running spice export
@tnt ok finally done, 3 antenna violations with that config.tcl. big improvement over what I was typically getting
I have to run soon but if it's that close I might tweak the density a bit and see if I can reach 0 that way
t
Yeah it's definitely not perfect, still kind of a brute force approach, just a tiny bit smarter than strategy 
1
but I've got pretty good results. Things you can tweak is density ( even like 0.39 vs 0.40 mostly to shuffle things ) or the CELL_PAD parameter. You can also look in the report to see what the violations are.
And 
run_magic_antenna_check
as well to see how bad they are.
In the report mostly check if the net where the violation one is one of the 'short' ones ... which would indicate heuristic needs tweaking.
d
👍 I'll try these tomorrow. Nice that most of the violations are gone as a first step, will post how I go with the 
run_magic_antenna_check
results too
down to 2 antenna violations on a recent run, I added the magic antenna check so will post the logs when that's done here
Best run I've had so far, still 2 but the ratio isn't as bad on this one: https://gist.github.com/dan-rodrigues/06a8d20e2e5687d6baaa20621e7f0759
Copy code
Effective antenna ratio 521.824 > limit 400
Is the worst affected with this script, not sure what threshold is considered totally unacceptable though
and earlier run I had one well over 1000
t
I'm pretty sure 521 is fine.
In some runs I still have some as well, I'll either let them be or try to fix them manually. A couple is manageable by hand.
d
I'll save these runs incase we do get a pass on them if it turns out they're fine
t
I know Tim said in another thread that those values are not even checked by the Fab. It's just a factor for yield percentage and that even a double value could potentially be fine. So a single 521 doesn't look bad in that context.
d
if that's the case then I probably have 3 or 4 other runs that are probably fine to manufacture, that's reassuring
m
So the antenna errors reported in the final stats are for antennas that are longer than a certain ratio? And how do I get info on each of the violations to make a call on whether I can Ignore it?
t
run_magic_antenna_check
lists them with the ratio.
All wires that are connected to gate without being connected to an output at some point during manufacture are antenna. It evaluates the surface of the metal vs the surface of the gate area and if the antenna is > 400 times larger, it reports it as a violation.
m
Is that something I can run inside the docker? Or is it a makefile target?
t
I call 
flow.tcl
with argument 
-interactive
(in addition to the other args) to get a shell. and then:
Copy code
package require openlane
run_magic_antenna_check
m
Thanks
I think I'm missing something, running that tries to overwrite previous runs
I looked at the CLI arguments but couldn't see something that would let me specify a previous run
t
-tag
?
m
thanks!
ok, I have run this on the 2 designs I have that still have antenna violations
design 1 reports 1 violation and magic antenna check shows 2
design 2 reports 2 violations and magic antenna check shows 0
t
yeah, they have slightly different criteria and algorithm and aren't 100% consitent.
m
normal? design 1 ratio is very low, so I think I will ignore it
489 > 400
a
@tnt for some reason when I use your diode insertion script, it creates a massive number of metal holes area violations
any idea what could cause that?
t
in 
met1
? Well the script is written to try and allow the router to put a maximum number of connections from pin to diode on 
met1
so I guess this increases the probability of the TritonRouter bug that causes those to occur ... Did you check if they look like : https://imgur.com/afxrQE6 ?
4 Views
Open in Slack
PreviousNext
Powered by