Scribd
Upload
38 views3 pages

1234

Uploaded by

Khadar Basha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
38 views3 pages

1234

Uploaded by

Khadar Basha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

n my PNR script I define the antenna rules (from a file provided by the fab), specifying that the max

MET4 to gate area ratio should be 400. At the end of my finishing section after inserting redundant
vias and re-running route_opt, I load these antenna rules and run check_routes. It detects no
antenna violations.

Straight after I run signoff_check_drc with the runset provided by the fab. It detects a couple of
antenna violations on MET4. It thinks the ratios are ~530. All errors are in the same area of the
design, 4 are all right next to each other, 2 a bit further away but still close. all with MET4 (out of 6
metal layers, MET1-4, METTP, METTPL).

I'm a bit lost here. I'm pretty sure if my pnr script detected the violations it would be able to fix
them, but since it doesn't detect them I'm not sure how to fix them. I could try to manually cut the
routes, but I'm sure there's a better way.

signoff_fix_drc doesn't attempt to fix the issues.

I've compared the antenna rules in my pnr script (and run report_antenna_rules, to check they
applied correctly), with the runset, but I don't really know how to make sense of the runset, the
values given (400.0) are the same, but maybe there's some subtlety I'm missing, for example I'm not
sure how to check the -mode and -diode_mode parameters from my pnr script against the runset.
Both these rules came from the fab so they <should> be correct.

One thing I noticed is the runset uses: "net_area_ratio_with_accumulate_cond(..." and there's a


ICC2 command: define_antenna_accumulation_mode. I checked that with all 4 possible values (-
cut_to_metal -metal_to_cut) but check_routes still insists there's no antenna violations.

The affected nets are all internal nets named stuff like n2223, so I don't think it's anything to do with
my IO pins, although all 6 of the violations are pretty close to those pins.

In my PNR script if I reduce the max antenna ratio for MET4 to 1 (from 400) and then re-run
check_routes, it still gives no error, this sort of suggests it's not really running the checks at all.
However the output to check_routes does suggest it's using the new value.

*****Start reporting antenna related parameters*****

Antenna/diode mode:

Antenna mode 1; diode mode 4

..

Metal lay (MET4)3; maxRatio 2147483648.000 maxPRatio 2147483648.000 maxNRatio


2147483648.000; vector (0.000 0.000 1.000 0.000 0.000)

Cut lay (VIATP)4; maxRatio 20.000 maxPRatio 2147483648.000 maxNRatio 2147483648.000;


vector (0.000 0.000 0.000 10000000.000 0.000)

..

Antenna mode 4; diode mode 4

..

Metal lay (MET4)3; maxRatio 1.000 maxPRatio 2147483648.000 maxNRatio 2147483648.000;


vector (0.000 0.000 0.000 10000000.000 0.000)
Cut lay (VIATP)4; maxRatio 2147483648.000 maxPRatio 2147483648.000 maxNRatio
2147483648.000; vector (0.000 0.000 1.000 0.000 0.000)

..

Accumulate from metal to cut == false

Accumulate from cut to metal == false

Top lay antenna ratio fix threshold == -1

Antenna max pin count threshold == -1

Check PG net == false

MergeGate == true

Break antenna to port mode == float

Break antenna to macro pin mode == normal

*****End reporting antenna related parameters*****

Start net based rule analysis

Found 0 antenna instance ports

End net based rule analysis

...

Total number of antenna violations = 0

In ICV the results told me the problem was with nets n2223, ... however when looking at ICC2's error
browser with the results of the signoff_check_drc, it didn't specify nets, but close to where the Xs
were I noticed a pretty long path on MET4. Looking at that it was from an input port.

In the check_routes command, there were a bunch of warnings:

Warning: Skipping antenna analysis for net blah. The pin blah on cell my_design does not have
enough gate area information. (ZRT-311).

I'd been ignoring that (temporarily) as it didn't seem related to the nets specified by ICV as being the
problem. However two of those warnings mapped to the nets with long paths on MET4.

The solution was to tell the tools to ignore gate sizes on terminals:

icc2_shell> set_app_options -name route.detail.default_port_external_gate_size -value 0.0


My understanding of this is ICC2 doesn't know if this input net is connected to another gate outside
of my block. And so it just refuses to do any analysis on that net. I don't really get why it doesn't just
assume there's nothing out there and warn you that it's doing that, but ...

Anyway that solved the issue.

You might also like