#magic anyone have experience with antenna checks in Magic? If so, do you see a challenge running the antenna checks on a flat design? Background: I have a SAR, and when I run antenna checks on a hierarchical design I get a bunch of antenna check errors (some obviously wrong). When I run flat, however, all antenna errors disappear. Now, am I fooling myself in trusting the lack of antenna errors on my flat design 🙂

From a (somewhat rusty) mixed signal IC designer's point of view: That shouldn't be a problem. Antenna rules are essentially tests whether all interconnects that connect to gate oxide have the equivalent of a lighning rod, i.e., a sufficiently large reverse biased junction to substrate or well, somewhere in the net, as the interconnect layers are being stacked up on the semiconductor and thin oxides. I was worried (and you confirm my worries) that as you verify a hierarchical design from the bottom up, you might catch antenna rule violations for interconnects to thin oxide with no reverse biased junction lightning rod on the individual building block you're verifying.

I'd like to see the example. I thought I had all the issues worked out in the antenna rule checks.

Antenna rule violation in front of my house: Two workers on a lifting platform installed new lightning rods (copper wire) next door in horrific weather. I distracted them from Important Work and asked them how they would ground the lightning rod (copper wire from the roof). Turned out aftewards that while driving substrate taps (grounding rods) into the soil, they hit an underground power cable and got shocked. Twice. Without reporting the damage. … which had to be fixed with the equivalent of a Focused Ion Beam (small excavator) a few weeks later.

@Tim Edwards sure thing.

#- Clone

git clone git@github.com:wulffern/tt06-sar.git --recursive git checkout antenna_debug cd tt06-sar/ip/tt06_sar_sky130nm/work/ #Antenna check make ant #Flat antenna check make antf

I notice that your script has

extract path extfiles

followed by `extract do local`: These are mutually exclusive;

extract do local

is equivalent to

extract path .

. So following that with

antennacheck -p extfiles

means that you are probably not picking up the correct .ext files.

Ok, changed to: select top cell extract no all extract all antennacheck debug antennacheck

I'm running manually so I don't get confused by anything in the scripts. When running hierarchically, I'm getting output like

Effective antenna ratio inf > limit 3185.76

. I assume

inf

can only come from a divide-by-zero result, which suggests something went wrong with the computation, which would point to why there are so many errors (since

inf

is greater than everything!).

@Tim Edwards Fantastic, as always, big thanks for debugging for me. I know what to do in my compiler then (although I'm not sure how I'll fix it yet).

@carsten: If you hold off for a little bit, I may be able to fix this in magic first. It doesn't make sense that poly over a gate won't be seen as connected to the gate. That has to be a straight-up error somewhere.

Could be. There is a metal 2 bridge at the bottom of the SAR for that net. That net is the right most signal in the SAR, and it is very long. But if that’s the only one left I’d be happy to add a ndio to remove.

Still running things manually, if I flatten the design and run antenna checks, I get the same result of one antenna violation on the same net. So I think this is working. I will do more tests and if it continues to look like it does not introduce unexpected consequences, then I will commit the fix.

Whatever you did to magic, it introduced a side effect that causes

make install

of

open_pdks

just freeze up without any error message. This has already cost me about 4 hours I don't have if I'm supposed to take chipalooza "specification" requests and intermediate deadlines seriously.

Building and installing open_pdks runs in about 15 minutes on my computer, although I have a 16 core machine and 64GB memory; that implies that a single-threaded build can take several hours, and if it ends up swapping it could be a lot longer.

On my computer, according to commit of log files: from

open_pdk make veryclean

logfiles saved at 03:47 AM to

open_pdk make

logfiles saved at 04:25 AM from

open_pdk make

logfiles saved at 17:46 to

sudo make install

logfiles saved at 18:24 during the previous installation run. What threw me off (and cost me several hours of sleep restarting the PDK build from scratch): While open_pdk

make

generates conspicuous CPU load, open_pdk

make install

just takes forever, with no stdout or stderr output and no conspicuously high CPU usage. Not a bug per se, but a helpful "Nothing to see yet. Moving along" during install would appease users made impatient by a looming deadline, in particular if the deadline is a bit arbitrary and capricious.

@Christoph Maier: I'm not sure what takes so long with "make install". It runs in about 1 or 2 minutes on my computer. It is running every installed file through a filter to change references to the target location from the staging area to the final install location, and to determine when files in two PDK variants are exactly the same. The filtering takes up compute resources in a way that is not easy to see and is probably heavily buffered and heavily dependent on the amount of memory available. I expect that it could be made a lot more efficient if I spent the time to investigate.

@Tim Edwards the fix worked like a charm on my end. Thanks.