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?

Interested to hear how you get on, I have no idea how to reduce them.

How many are we talking about here ?

last run was 75 antenna violations, on a design with 27.5K cells

How many were you getting with strategy 3 ?

110+ last time I tried it with 3

You can try strategy 3 with multi iterations :

set ::env(GLB_RT_MAX_DIODE_INS_ITERS) 5

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

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.

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.

Ok, just pushed my stuff there : https://github.com/PyFive-RISC-V/pyfive_top_202011

cool, going to try this with the basic script soon and will see how it goes

🤞

Lots of

[x] skipping small net

logs, seemed to go through with no errors

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.

yeah wow I misjudged that 15 minute estimate...poor old MBP is nearly done, at

Running spice export

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.

👍 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

I'm pretty sure 521 is fine.

I'll save these runs incase we do get a pass on them if it turns out they're fine

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.

if that's the case then I probably have 3 or 4 other runs that are probably fine to manufacture, that's reassuring

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?

run_magic_antenna_check

lists them with the ratio.

Is that something I can run inside the docker? Or is it a makefile target?

I call

flow.tcl

with argument

-interactive

(in addition to the other args) to get a shell. and then:

package require openlane
run_magic_antenna_check

Thanks

-tag

?

thanks!

yeah, they have slightly different criteria and algorithm and aren't 100% consitent.

normal? design 1 ratio is very low, so I think I will ignore it

@tnt for some reason when I use your diode insertion script, it creates a massive number of metal holes area violations

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 ?