^ same here - not sure how to deal with antenna fixes when the cells have already been packed together so closely

Looking at my report I'm considering manually adding diodes in my verilog for all input pins.

@Anish: It is likely that openlane and magic compute the antenna ratios slightly differently, so they may come up with different answers. Magic does provide a value in the output, so unless it is showing that the antenna rule is violated by a large amount, I would not worry about it much. Antenna rules are very wishy-washy compared to other DRC rules. They mostly affect yield and therefore are more relevant to production runs than to shuttle runs. You probably need not be concerned about any violation that is not more than, say, 2x the stated rule.

@Tim Edwards I think that's

DIODE_STRATEGY

1

( Spray ). Doesn't remove all violations either 😕 Some diode just end up away from the pin they're supposed to protect, or routed to that pin using a high metal layer, negating protection.

I tried running with diode strategy spray and it generated 3000+ DRC violations on a tiny design

Ouch, that's weird, I don't get any DRC violations because of diodes.

@tnt: That's not quite it, though. "spray" spreads a number of diodes around, but it would still be calculating antenna violations based on what it can see. Errors on digital inputs are generally going to be caused by routing a long signal line to it from elsewhere on the chip. When running place & route on the cell itself, the connection to the digital input is likely to be very short and not flag an error at all. In qflow, adding an antenna to every input was done separately from the "spray" part, and it was done before placement so that the antenna cells were always placed right next to the inputs where they needed to be. It's a guard against whatever the top level routing might do.

AFAIK there is no such options here.

@Tim Edwards just to clarify on your previous note wrt the 2x thing, if the worst antennas are ~1.5x the required ratio, will it pass the foundry checks or does it need to still be fixed somehow?

@Anish : Foundry checks (at SkyWater) do not include antenna violation checks; these are entirely up to you to decide. I will also see if we can make the pre-check more nuanced, so that antenna violations that are "not too serious" can be treated as warnings rather than errors. However, the "2x" rule is just a suggestion; I have no idea what would constitute "not too serious" numerically. Functionally, I would say that if it drops yield by more than a few percent, then it starts to become a real risk of ending up with a dead project returned to you. I would probably have to run an experiment with different antenna lengths attached to logic being monitored through the management SoC and see if any of them come back dead, and try to gather enough of that data to be statistically significant.

Ah alright thanks, I'll try to twiddle it until it's low enough