( ESNUG 454 Item 13 ) ------------------------------------------- [04/28/06]
Subject: ( SNUG 04 #12 ) Hercules debug useful, Calibre debug is confusing
> It's nowhere as easy to debug LVS errors in Hercules as it is with Calibre.
> What's the deal with all the different report files? Calibre has only one,
> and it's much easier to understand. The Hercules Explorer DRC/LVS debug
> interface is also nowhere as nice as Calibre. I hate it.
>
> - Robert Maxwell of Mediaworks-ISI
From: [ The Man in the Iron Mask ]
Hi John,
Please keep my name and company anonymous.
I use both Hercules and Calibre in my company. Calibre is required by my
foundry for sign-off. I saw Hercules taking a beating for LVS ease of use
in ESNUG. Here's my example of how it provides better information for LVS
debug than Calibre.
Both Calibre and Hercules provide LVS information about mismatched nets,
devices, and ports. On the same design, I ran both Calibre and Hercules.
Calibre summarizes its information like this:
NUMBERS OF OBJECTS AFTER TRANSFORMATION
---------------------------------------
Layout Source Component Type
------ ------ --------------
Ports: 22 22
Nets: 4431 4424 *
Instances: 4099 4099 MN (4 pins)
------ ------
Total Inst: 4099 4099
Hercules summarizes its information like this:
(CMP-12): Post-Merge Netlist Statistics:
Schematic Layout
--------- ------
2048 2048 [nflash_a, nflash_a]
2051 2051 [nflash_fg, nflash_fg]
--------- ------
4099 4099 Total Devices
4423 4429 Total Nets
It's pretty obvious that my layout had opens because the number of devices
is the same and the number of nets is larger in the layout.
So, where are these opens?
I started with the Calibre output file first. Here's what Calibre told me
about mismatched nets that were possible opens:
**********************************************************************
INCORRECT OBJECTS
**********************************************************************
INCORRECT NETS
**********************************************************************
DISC# LAYOUT NAME SOURCE NAME
**********************************************************************
1 Net PAD20(1579.000,-35.870) PAD20
-------------------------- --------------
** missing connection ** I34/I283/mM2:b
** missing connection ** I34/I283/mM0:b
** missing connection ** I34/I99/mM2:b
** missing connection ** I34/I99/mM0:b
** missing connection ** I34/I98/mM2:b
** missing connection ** I34/I98/mM0:b
** missing connection ** I34/I97/mM2:b
** missing connection ** I34/I97/mM0:b
** missing connection ** I34/I96/mM2:b
( similar information for the next 49 lines )
----------------------------------------------------------------------
2 Net PAD21(1769.000,-35.870) PAD21
-------------------------- --------------
** missing connection ** I34/I283/mM3:b
** missing connection ** I34/I283/mM1:b
** missing connection ** I34/I99/mM3:b
** missing connection ** I34/I99/mM1:b
** missing connection ** I34/I98/mM3:b
** missing connection ** I34/I98/mM1:b
** missing connection ** I34/I97/mM3:b
** missing connection ** I34/I97/mM1:b
( similar information for the next 49 lines )
----------------------------------------------------------------------
3 Net 990(-1707.825,17.165) I28/net01307
-------------------------- --------------
2302(-1708.005,17.165):d ** missing connection **
** missing connection ** I28/I143/mM1:d
There were 31 fields, each reporting a net that had missing connections
between the layout and the schematic listed in this format. This was a bit
confusing because based on the "after transformation" table, I expected
4431 - 4424 = 7 nets to be open.
Hercules reports the situation in a tabular format like this:
ERROR: There are unmatched devices/nets in the design.
Schematic Netlist Status Layout Netlist Status
---------------------- ----------------------
Unmatched Devices = 0 Unmatched Devices = 0
Unmatched Nets = 2 Unmatched Nets = 8
This information makes more sense. There are 8 - 2 = 6 opens in this design.
To cross check, looking at the "post-merge" statistics reported by Hercules,
there are 4429 - 4423 = 6 opens in the design.
Next debug step is to identify where are these open nets? Or, you could say,
what devices are these mismatched nets connected to?
Looking at the Calibre report file, Calibre states the following information
about mismatched nets:
--- Devices on layout net 187(-773.685,10.255) ---
1025(-741.535,25.105) MN(nflash_fg) ** no similar instance **
g: 250(-741.595,7.735) ** unmatched net **
s: 2525(-741.845,25.105) ** unmatched net **
d: 2541(-741.355,25.105) ** unmatched net **
b: 187(-773.685,10.255) ** no similar net **
1024(-741.535,24.665) MN(nflash_fg) ** no similar instance **
g: 250(-741.595,7.735) ** unmatched net **
s: 2524(-741.845,24.665) ** unmatched net **
d: 2540(-741.355,24.665) ** unmatched net **
b: 187(-773.685,10.255) ** no similar net **
1023(-741.535,20.295) MN(nflash_fg) ** no similar instance **
g: 250(-741.595,7.735) ** unmatched net **
s: 2521(-741.845,20.295) ** unmatched net **
d: 2537(-741.355,20.295) ** umatched net **
b: 187(-773.685,10.255) ** no similar net **
( this information continued past 35 devices. .. I stopped counting )
From this report it looks like net 187 in the layout is connected to the bulk
of device MN(nflash_fg), instance 1025. The error message states that there
is "no similar net" in the schematic column.
What is confusing is that if it appears that all of the devices match in this
design because the quantities are the same, why are there messages here about
"no similar instance"? And, if I am expecting to debug 6 opens, why are
there so many "unmatched nets"?
Also confusing, I searched for net 187 in the "INCORRECT NETS" section and
did not find any reference to this net?! So, why is this net mentioned with
devices that have no similar instance?
Searching further through the lvs.report provides additional information about
what nets are connected to which devices:
**********************************************************************
DETAILED INSTANCE CONNECTIONS
LAYOUT NAME SOURCE NAME
**********************************************************************
(This section contains detailed information about connections of
matched instances that are involved in net discrepancies.)
----------------------------------------------------------------------
1799(953.225,19.855) MN(nflash_fg) I34/I283/mM2 MN(nflash_fg)
g: 381(953.165,7.185) g: I34/net027
s: 4100(952.915,19.855) d: I34/net02083
d: PAD17(935.055,19.925) s: PAD17
b: 348(936.265,10.255) ** no similar net **
** PAD20(1579.000,-35.870) ** b: PAD20
----------------------------------------------------------------------
(There were 32 more entries below this one, with similar information.)
OK, this is good. It appears that the problem lies in PAD20 net. What this
does not say is what the problem is. Another confusion is why is there a
5th line of information on this device? There are only 4 terminals.
The number of entries (32) provided for debug information does not equal the
size of the problem I am trying to solve. This is similar to the quantity
listed for the nets that did not match in the "INCORRECT NETS" section.
Hercules provided a significantly better level of detail to identify where
to go on this same design:
ERROR: LAY_OPEN_NETS
The following unmatched nets are highly suspected to indicate source of
opens in layout netlist:
Schematic Net Layout Net
---------------------- ----------------------
PAD21 : 2048 2502/SWITCH_PWELL : 512
PAD21 : 512
28 : 512
30 : 512
---------------------- ----------------------
PAD20 : 2048 2 : 512
PAD20 : 512
10 : 512
2502/SENSE_PWELL : 512
It is clear from here in the Hercules data that the nets connected to PAD21
and PAD20 are open in my layout.
Layout nets 2502/SWITCH_PWELL, 28 and 30 need to be connected to net PAD21.
Layout nets 2, 10 and 2502/SENSE_PWELL need to be connected to net PAD20.
Doing the math, that's 3 open nets for PAD20 and PAD21, respectively; which
is the same problem size expected in earlier parts of the file.
To fix this, all I needed to do is connect the following layout nets:
502/SWITCH_PWELL : 512 \
28 : 512 >----- to PAD21
30 : 512 /
And
2 : 512 \
10 : 512 >----- to PAD20
2502/SENSE_PWELL : 512 /
This was all of the information I needed to fix the problem and Hercules had
it inside a single 30.1 K file. In contrast, for the same debug Calibre's
report file was a whopping 249 K and it didn't even provide sufficient
information to find the issues quickly.
I hope this example showed you, John, how needlessly verbose Calibre debug
is compared to Hercules debug.
- [ The Man in the Iron Mask ]
Index
Next->Item
|
|
