Question on Assura LVS results

Following is the situation,

Some dummy capacitor is added to the layour, based on the unused space
available in the block.

The capacitor needs to be in the schematic. But the problem is that
the LVS will show that the device is missing. So I have to add the
device without knowing the parameter first time, run LVS again to get
the parameter errors. Hence I have to run LVS 3 times to make the
block clean.

Is it possible to get the missing devices with parameter details, in
first time itself so two LVS runs suffice the LVS clean?

Consider that there are huge number of capacitors added in layout,
between various nodes.

Is there any option in avParameters to set? Or do we need to change
the extract rule accordingly?

-
Rajeswaran

 

the LVS tool removes parasitic components from the extracted netlist
because they are inherently absent from the schematic.
if you can tell lvs your component is a parasitic it will not be checked.

this is from diva manual :

"Sometimes the extracted view contains devices, such as parasitic devices,
that
you do not want to include in the netlist for LVS checking. For any devices
that you do not
want to include in the netlist, you must set the lvs view property nlAction
to ignore. The
nlAction property must be placed in the property list of the device's
cellview."

most likely some similar functionnality exists in Assura.

also from diva manual:

"The saveParasitic statement (or extractDevice statement) used during
circuit extraction must
reference one of these special devices instead of a normal device, whenever
that device does
not appear in the schematic. The following special devices are available for
this purpose.
- pcapacitor : Equivalent to the normal device capacitor.
- pdiode : Equivalent to the normal device diode.
Each special device has a symbol cellview, which becomes the default
referenced in the
extracted layout so that it can be viewed. Each special device also has an
lvs cellview for the
LVS netlister, and a SPICE cellview to permit full simulation. If any other
cellview is required,
you must copy it, without change, from the normal cellview of that device
and add it to the cell."

 

If you talk form dummy devices there are different approaches.
Some people filter these dummy devices out of their layout netlist,
so that they don't have to be drawn in the schematic.

For that Assura offers the commands 'filter' and 'filterDevice'
which you have to add in the compare.rul.
For details please look in the docs.

Bernd

 

Bernd,

In divaEXT+LVS you could also filter out by connectivity (ex:
resistors with terminals shorted together will not be checked) you can
use the table A-7 "Diva to Assura Rule Conversion Matrix" in the
divatoassura document (assura3.0) if you already have a diva deck.

My 2 cents on this are: if the designer wants matching, then he should
enter the dummies in his schematic and put a note for the layouter.
There are things like electromigration or matching that are too poorly
automated and can better be left for people to do "by hand". They have
to communicate anyway.

Anyone thought about my question on piezo-induced mismatch ? Should I
put it in another newsgroup ?

 

Well, these are not parasitics and should not be filtered out.

 

I know this will not help you I guess,
but nowadays the most design kits come with PCells.
This PCells have parameters to fill out for the layout.
For C's e.g. capacitance and w and l depends on them or w and l and
c depends on them.
The calculating routine used in the PCell code is the same or nearly
the same as used in the extract rules.
So if you specify values for a C in layout then you should have the
parameters which will be used for extraction and LVS.

If you place a C as a fix cell in your layout you have to calculate the
parameters used in the for extraction and LVS and attach them manual to
the cell or as you already do extract the layout and look what values
are extracted.

No more ideas about this!

Bernd

 

so basically what you want is do the layout in the area
that is left unoccupied (unknown apriori) an then
get the parameters to add this in schematic, right ?

ok if you do the layout, the extract it and look
in the extracted view, locate the capacitor and
find the device resulting from the extraction,
it should contain the parameters you need.
not including parasitics.

(i guess that's what you want.)

 

I think Bernd's approach makes sense - you could always make your dummy
capacitors compare based on the size rather than the value - and since you
know what size the capacitor was when you added it, then this would be OK.

Note, many people do use filtering for _dummy_ (not parasitic) devices.
Personally I'm not so keen on this, but sometimes it's a viable option. However,
if the dummy capacitors are connected to the circuit, you may well want to
compare them - but then again, any kind of flow which you don't know what
you've got until you do an LVS and then add the missing devices found back into
the schematic doesn't seem any better to me than finding a way to filter these
devices in the first place.

Regards,

Andrew.

 

Thanks for your comments.

Here I am trying to give more view about my need, where the filtering
would not be recommended.

I have hand drawn/autorouted layout block. I am trying to create a
schematic for the same. I dont have anyother option than re-using the
earlier schematic design which match the layout in some extent, say
90%. I will have few device mismatches and large parameter mismatches,
If do LVS with the schematic unmodified. To make the schematic to be
compatible with the Layout, I have to do LVS for minimum two trail &
error runs, for device and parameter mismatches respectively. The
design is so huge that the more iterations will eat more time.
So it is very much important to reduce the number of runs.

So my expectation is that, if the LVS can able to say that there are
missing devices, either in layout or schematic, why wouldn't it be
possible to tell their parameters also.

 

I think this is not the approach a layout versa schematic check was
designed for, this is reverse engineering.
A lvs should check a layout against the golden schematic and
tell the layout errors, rather than tell what parameters
you have to put in the schematic.

But Assura lvs is able to tell you what parameters are missing
in the schematic as also in the layout, if in the the compare.rul
the combine function in 'permuteDevice' and/or the compare function
in 'compareDeviceProperty' are setup to do this.

I attach an example for a mimcap combine and compare function to this
posting which is able to tell you missing parameters.

Bernd


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Disclaimer : NO WARRANTY, this SKILL function(s) is(are) released
;; without any warranty. The Author does not warrant,
;; guarantee, or make any representations regarding the
;; use, or the results of use of this SKILL function(s).
;; The entire risk of the use of this SKILL function(s)
;; is with you.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; combine parallel MIM caps
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

procedure( XIparallelMimCap( mimcap1 mimcap2 )
prog( ( parCap missing1 missing2 )

;; set the output plist to nil

parCap = ncons(nil)

;; if 'm' factor is missing, set it to 1

when( !mimcap1->m mimcap1->m = 1 )
when( !mimcap2->m mimcap2->m = 1 )

;; if 'c', 'w' or 'l' is missing, do not combine
;; for generic purpose 'w' and 'l' can be substituted by a prameter for area

foreach( prop '( c w l )
unless( get( mimcap1 prop )
missing1 = cons( prop missing1 )
) ;; unless
unless( get( mimcap2 prop )
missing2 = cons( prop missing2 )
) ;; unless
) ;; foreach

;; report all missing parameters

when( ( missing1 || missing2 )

printf( "\n" )
printf( "** Parallel MIMCAP with missing parameters not combined:\n" )

when( missing1
printf(
" 1st MIMCAP missing parameters: %s \n"
buildString( missing1 "," ) )
) ;; when

when( !missing1
printf(
" 1st MIMCAP with all parameters \n" )
) ;; when

when( missing2
printf(
" 2nd MIMCAP missing parameters: %s \n"
buildString( missing2 ",") )
) ;; when

when( !missing2
printf(
" 2nd MIMCAP with all parameters \n" )
) ;; when

return( "doNotCombine" )

) ;; when

;; now we know that 'c', 'm', 'w' and 'l' are defined for both property lists

;; set variables to make typing easier and code simpler

if( ( mimcap1->w && mimcap2->w ) then
if( stringp( mimcap1->w ) then
W1 = float( evalstring( mimcap1->w ) )
else
W1 = float( mimcap1->w )
) ;; if string
if( stringp( mimcap2->w ) then
W2 = float( evalstring( mimcap2->w ) )
else
W2 = float( mimcap2->w )
) ;; end if string
) ;; end if

if( ( mimcap1->l && mimcap2->l ) then
if( stringp( mimcap1->l ) then
L1 = float( evalstring( mimcap1->l ) )
else
L1 = float( mimcap1->l )
) ;; if string
if( stringp( mimcap2->l ) then
L2 = float( evalstring( mimcap2->l ) )
else
L2 = float( mimcap2->l )
) ;; end if string
) ;; end if

if( ( mimcap1->c && mimcap2->c ) then
if( stringp( mimcap1->c ) then
C1 = float( evalstring( mimcap1->c ) )
else
C1 = float( mimcap1->c )
) ;; if string
if( stringp( mimcap2->c ) then
C2 = float( evalstring( mimcap2->c ) )
else
C2 = float( mimcap2->c )
) ;; end if string
) ;; end if

if( ( mimcap1->m && mimcap2->m ) then
if( stringp( mimcap1->m ) then
M1 = float( evalstring( mimcap1->m ) )
else
M1 = float( mimcap1->m )
) ;; if string
if( stringp( mimcap2->m ) then
M2 = float( evalstring( mimcap2->m ) )
else
M2 = float( mimcap2->m )
) ;; end if string
) ;; end if

;; combine parameters, make sure we set new L and M.
;; correct for m-factor here
;; combine only if 'w' or 'l' are equal

diffW = abs( W2 - W1 )
diffL = abs( L2 - L1 )

cond(
( diffW < 0.005e-6
newW = float( W1 * M1 + W2 * M2 )
newC = float( C1 * M1 + C2 * M2 )
newL = L1
)
( diffL < 0.005e-6
newL = float( L1 * M1 + L2 * M2 )
newC = float( C1 * M1 + C2 * M2 )
newW = W1
)
( t
newC = C1
newW = W1
newL = L1
return( "doNotCombine" )
)
)


parCap->w = newW
parCap->l = newL
parCap->c = newC
parCap->m = float(1.0)

;; report combining to the log file

printf( "\n" )
printf( "** Parallel MIMCAP combined \n" )

printf( " 1st MIMCAP: c = %g w = %g l = %g m = %g\n" C1 W1 L1 M1 )
printf( " 2nd MIMCAP: c = %g w = %g l = %g m = %g\n" C2 W2 L2 M2 )
printf( " Resulting: c = %g w = %g l = %g m = 1 \n" newC newW newL )

return( parCap )

) ;; prog

) ;; procedure XIparallelMimCap


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; compare MIMCAP parameters
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

procedure( XIcompareMimCap( layPlist, schPlist )
prog( ( missingLay missingSch )

tolC = 1.0
tolW = 1.0
tolL = 1.0

;; if m factor is missing, set it to 1

when( !layPlist->m layPlist->m = 1 )
when( !schPlist->m schPlist->m = 1 )

;; if 'c', 'w' or 'l' is missing generate a parameter mismatch

foreach( prop '( c w l )
unless( get( layPlist prop )
missingLay = cons( prop missingLay )
) ;; unless
unless( get( schPlist prop )
missingSch = cons( prop missingSch )
) ;; unless
) ;; foreach

;; report all missing parameters

when( ( missingLay || missingSch )

when( missingSch
sprintf( msg1 "Schematic MIMCAP missing parameters: %s"
buildString( missingSch ",") )
) ;; when
when( !missingSch
sprintf( msg1 "Schematic MIMCAP c/w/l/m %g %g %g %g"
float(schPlist->c)
float(schPlist->w)
float(schPlist->l)
float(schPlist->m)
)
) ;; when

when( missingLay
sprintf( msg2 "Layout MIMCAP missing parameters: %s"
buildString( missingLay ",") )
) ;; when
when( !missingLay
sprintf( msg2 "Layout MIMCAP c/w/l/m %g %g %g %g"
float(layPlist->c)
float(layPlist->w)
float(layPlist->l)
float(layPlist->m)
)
) ;; when

sprintf( msg "Error: %s ; %s" msg1 msg2 )
return( msg )

) ;; when

;; now we know that 'c', 'w', 'l' and 'm' are defined for both plists
;; correct for 'm' here

if( ( layPlist->w && schPlist->w ) then
if( stringp( layPlist->w ) then
layW = float( evalstring( layPlist->w ) )
else
layW = float( layPlist->w )
) ;; if string
if( stringp( schPlist->w ) then
schW = float( evalstring( schPlist->w ) )
else
schW = float( schPlist->w )
) ;; if string
) ;; if

if( ( layPlist->l && schPlist->l ) then
if( stringp( layPlist->l ) then
layL = float( evalstring( layPlist->l ) )
else
layL = float( layPlist->l )
) ;; if string
if( stringp( schPlist->l ) then
schL = float( evalstring( schPlist->l ) )
else
schL = float( schPlist->l )
) ;; if string
) ;; if

if( ( layPlist->c && schPlist->c ) then
if( stringp( layPlist->c ) then
layC = float( evalstring( layPlist->c ) )
else
layC = float( layPlist->c )
) ;; if string
if( stringp( schPlist->c ) then
schC = float( evalstring( schPlist->c ) )
else
schC = float( schPlist->c )
) ;; if string
) ;; if

if( ( layPlist->m && schPlist->m ) then
if( stringp( layPlist->m ) then
layM = float( evalstring( layPlist->m ) )
else
layM = float( layPlist->m )
) ;; if string
if( stringp( schPlist->m ) then
schM = float( evalstring( schPlist->m ) )
else
schM = float( schPlist->m )
) ;; if string
) ;; if

;; combine only if 'w' or 'l' are equal

diffW = abs( W2 - W1 )
diffL = abs( L2 - L1 )

cond(
( diffW < 0.005e-6
layC = float( layC * layM )
layW = float( layW * layM )
schC = float( schC * schM )
schW = float( schW * schM )
)
( diffL < 0.005e-6
layC = float( layC * layM )
layL = float( layL * layM )
schC = float( schC * schM )
schL = float( schL * schM )
)
)

diffC = 100 * (abs( layC - schC ) / schC )
diffW = 100 * (abs( layW - schW ) / schW )
diffL = 100 * (abs( layL - schL ) / schL )

Cerr = nil
Werr = nil
Lerr = nil

when( diffC > tolC Cerr = t )
when( diffW > tolW Werr = t )
when( diffL > tolL Lerr = t )

;; if no errors return nil

when( !Cerr && !Werr && !Lerr return( nil ) )

;; now we know there is a parameter error

sprintf(
msg
"Error: MIMCAP Schematic c %g w %g l %g;
Layout c %g w %g l %g" schC schW schL layC layW layL
)

return( msg )

) ;; prog
) ;; procedure XIcompareMimCap

 

Since *something* generates the layout for these devices, it
would sure be nice if that *something* dumped a listing of
what it did.

But for some reason that is impossible, OK.

After the extract, whether or not you do an LVS,
you've got a perfectly good extracted netlist available
to you,

% vldbToVnl jobdir/jobname.ldb

(There is also vldbToSpice, if you like that better)
If the layout nets are all labeled (say these are all power/ground
caps), you're done.

Sounds like in your case you've got these guys hanging all over the
place, though, too bad.

In that case, I would put listXRef() in avCompareRules(),
and use jobdir/jobname.cxl to map the netnames.

It is possible, I suppose, that LVS will be so unhappy with
the extra devices that you'll not get good cross-reference
results; in that case your first-pass LVS will have to
filterDevice() them. Then turn them back on in the
second pass.

-Jay-

 

Thanks Bernd!!!

I guess the code provided would be what I am expecting. But I was
thinking a simple LVS switch/avParameters-settings/keywords in
compare.rul/extract.rul to achieve the function.

Again, thank you for the code and will let you know about the results.

-
Rajeswaran

 

1. For the record, I ran Bernd's SKILL code through a 5-minute SKILL Survey
(which Customers can run also using the latest DFII software product
#900 SKILL Development Environment) via email from the DFII SKILL
Development Toolbox on the DFII command-interpreter window (just press
on the new "SKILL Surveyor" button) - and sent Bernd the results for
his edification.

2. Based on this static test, Bernd's SKILL code is clean:
- No private functions (i.e., undocumented unsupported dangerous) were used;
- There are 31 public (well documented & supported) functions called;
- There are no deleted functions (since IC440);
- And, no Cadence re-defined public or private functions;
- Also no un-defined functions (typos, mistakes, dependencies, etc.);
- With only compatible enhancements made to the 31 functions called;
- There are two Customer-defined functions;
XIcompareMimCap()
XIparallelMimCap()
- Both are properly named (e.g., starting with a capital-letter prefix);
- And neither is called within the SKILL code itself.

3. I did not run a dynamic test (e.g., SKILL Lint), but based on the
quick static test above, I'm confident this code likely meets Cadence
current coding standards (documented in the latest manuals or available
upon request from your local sales office).