( ESNUG 416 Item 10 ) ------------------------------------------- [07/30/03]
From: Mark Hofmann <hopper=user domain=reshape spot calm>
Subject: Milkyway DB, Star-RCXT, & Astro Antenna Protection Diode Problems
Hi John,
A colleague and I recently used Star-RCXT on a multi-million gate SOC for
for netlist extraction. We stepped into two quagmires, one apparently
related to an out-of-sync Milkyway DB and another having to do with
shortcomings in how both Star-RCXT and Astro are able to cope with antenna
protection diodes. So that fellow ESNUG readers can avoid these marshy
areas, here are the issues and our workarounds.
Star-RCXT Version: U-2003.03 says:
Internal error on /auspex/apd/starrc/group/build/dbXtract \
/2003.03.0.8/src/skipcells/SkipCellCacheOfPorts.C@71
--------------------------------------------------------------
| ERROR: Synopsys Internal Error
--------------------------------------------------------------
| INTERNAL_ERROR!
--------------------------------------------------------------
...and wishes you a pleasant day.
It turns out that this is caused by having a set of reflibs that are not
self-consistent, or, rather at least one reflib that is somehow out of date.
In our fairly large case, the block referred to 22 separate reflibs -- some
of which referred to multiple reflibs themselves. By painstakingly
replacing each library with a re-built version of the same library we
finally isolated this to a single reflib pointer that was stale. When we
opened a cell in this library we saw messages of this form:
Open cell clocks_blk.CEL;1 OK
Update cellInstMaster of [inverter.FRAM]
Update cellInstMaster of [dfflop.FRAM]
Update cellInstMaster of [mux21.FRAM]
Update cellInstMaster of [decap.FRAM]
(This message can occur when a cell's "type" is modified or when a reflib's
path, version or timestamp changes. In general, the parent cell needs to be
updated after each add/replace of a reflib.) Simply doing an open and an
immediate save of the cell updated the disk image of the parent .CEL view
and our subsequent run of the higher-level block, which referred to this
library, now ran cleanly, without producing any capitalized exclamations of
horror.
Neither Astro nor Star-RCXT fully recognize antenna protection diode ports.
In Astro, after adding antenna diodes to our design and referring to
the published Synopsys methodology we ran auECOByNetCmp followed by
cmCmdECODump. We got:
+I antenna_diode_1 aDiode
+P vdd! antenna_diode_1 vdd!
+P gnd! antenna_diode_1 gnd!
That is, the added diode instances and their power ports are listed. The
antenna diode pin is missing. Running cmCmdECODump by itself we saw:
+I antenna_diode_1 aDiode
+P ANTPIN antenna_diode_1 scan_net_128
...the added instances and the diode pin, but no power ports. What we
desire, but cannot produce via Astro is the combination:
+I antenna_diode_1 aDiode
+P ANTPIN antenna_diode_1 scan_net_128
+P vdd! antenna_diode_1 vdd!
+P gnd! antenna_diode_1 gnd!
To solve this issue in our automated full-chip implementation system we
had to write a smidgen of Scheme to fetch and print all diode-connected
nets. This is a bit tricky since DIODE-PIN objects are special and
require special Scheme commands to access them. Here is the code:
;;;; Print out all names of nets which are hooked to diode pins.
;;;; Assumes an open library and open cell.
(define listDiodeNets
(lambda ()
(let* ((cellId (geGetEditCell)))
(db-foreach cellId '() "cellInst" instId
(let* (
(masterId (dbFetchObjectField cellId instId "cellInstMasterId"))
(masterName (dbFetchObjectField cellId masterId "cellName"))
(instName (dbFetchObjectField cellId instId "name"))
)
(db-foreach cellId instId "ExtraPortInst" portInstId
(let* (
(netId (dbFetchObjectField cellId portInstId "netId"))
(netName (dbFetchObjectField cellId netId "netName"))
(portMasterId
(dbFetchObjectField cellId portInstId "extraPortInstMasterId"))
(portName (dbFetchObjectField cellId portMasterId "name"))
)
(display "Master: ") (display masterName)
(display " Inst: ") (display instName)
(display " Port: ") (display portName)
(display " NetId: ") (display netId)
(display " Net: ") (display netName)
(newline)
#t
)
)
#t
)
)
(display "#t\n")
))
)
Despite the fact that our antenna diode cell was properly defined as type
"standard cell", Star-RCXT, running off the Milkyway CEL view, refuses to
acknowledge the existence of the DIODE-PIN in this cell. The extracted
netlist output (in SPEF format in our case) omits the diode pin altogether.
[Star-RCXT based on the Hercules XTR view should run fine.] If you're using
this output for LVS or PrimeTime purposes (PrimeTime wants to be able to
compare the Verilog netlist with the RC-annotated, extracted netlist), the
nets will mismatch and the comparison will fail. More than one customer has
noticed this longstanding flaw and Synopsys promises a fix in the September,
2003 time frame.
If, unaccountably, you find you cannot wait until then, here is an ugly
workaround: Copy the library containing your diode cell. Open up the .FRAM
view of the cell, smash the hierarchy if necessary, and delete the diode
pin. Create a new pin of the same name in the same location as the old
diode pin. (The "modify" command does not work on diode pins.) Save the
cell and replace the reference library pointer in the block to be extracted
with a reference to your modified library. Star-RCXT should now produce an
extracted netlist with ersatz diode pins which will inherit the capacitance
and other attributes of the real diode pin.
Note: This is an extremely dangerous operation; make sure you run this
experiment on a copy of your layout database to avoid corrupting either
your reference library or your layout. Keep this DB separate from your
golden DB and do not use this modified database for anything other than
extraction.
- Mark Hofmann
ReShape, Inc. Mountain View, CA
|
|
