LVS and Shorts in Virtuoso schematics?

[Andreas]

Hello,

I've got a synthesized verilog netlists containing statements, which
connect signals to logic high or low, e. g.

assign xy = 1'b0; //The net xy is tied to gnd (logic low).

The problem is that I have no tiehi or tielo cells in my synthesis
libraries.

After importing the verilog netlist as a Virtuoso schematic into CDE,
these verilog assignments are replaced. Sometimes they're replaced by a
"cds_thru" cell from the "basic" library and sometimes by "short" cell
from the designkit. I don't understand why two different cells are used.

The real Problem occurs, when I want to do a LVS. The LVS tool tells me
that it can not find the "cds_thru" or "short" cells in the layout. LVS
results incorrect, although the layout is correct.

What can I do?

I already searched for an lvsIgnore property, but the "cds_thru" and
"short" cells don't have one.

Thanks for your help,

Andreas

 

[S. Badel]

Andreas,

what LVS tool are you using ?

 

[Riad KACED]

Ciao Andreas,

1. When importing verilogin into cadence, you have fill the following
2 things into your form (The following comes from the Verilog In for
Design Framework IITM User Guide and Reference):
;-------------
1.1 Through CellView to be Used for Port Shorts
Specify the library, cell and view name pf the component to be used
between shorted ports. When the input and output ports of a module in
the input Verilog design are shorted, Verilog In puts a symbol called
cds_thru between the shorted ports. The symbol cds_thru is put instead
of the patch symbol used for other shorts to avoid shorted terminals
connectivity extraction errors from Composer. The default location of
this symbol is basic, cds_thru and symbol for library, cell and view
name respectively. You can customize the location of the symbol from
the Schematic Generation Option form. You can also click on the
Library Manager Browser button to select the design from the Library
Manager.

1.2 Continuous assignment symbol
Specify the library, cell, and view names for the patch symbol and
avoid net shorting. Net shorting happens whenever you use an assign
statement, such as assign a=b; in which both a and b are local nets.
You can click the Library Manager Browser button to select the design
from the Library Manager.
;-------------

path is used for local nets shorting but can't used for (PIN ||
GLOBAL) to (PIN || GLOBAL) conection. The cds_thru is used for this.

The 'patch' device used to cause some troubles by the past but cadence
provide solutions/workarouns for it. Some companies however developed
their inhouse solutions.
I used to work with the 'short' device from the 'STlib' when working
with STMicoelectronics somteime back.

This could explain your first request. Just check your form or
your .ihdlEnvFile

2. It realy depends on your LVS tool and your PDK capabilities (I know
ST PDKs offer the 'short' CAD marker that makes shorts in your
layout).
PLease give a llok at this, it could help ...
http://groups.google.com/group/comp.cad.cadence/browse_thread/thread/1ea0e91a9ea5e0a5/d0ef5c52cb5bf97d?lnk=gst&q=cds_thru#

Riad.

 

[Andreas]

Hi Riad,

many thanks for your help, you already helped me a lot.

The 'patch' device used to cause some troubles by the past but cadence
provide solutions/workarouns for it. Some companies however developed
their inhouse solutions.
I used to work with the 'short' device from the 'STlib' when working
with STMicoelectronics somteime back.

This could explain your first request. Just check your form or
your .ihdlEnvFile

2. It realy depends on your LVS tool and your PDK capabilities (I know
ST PDKs offer the 'short' CAD marker that makes shorts in your
layout).

I'm also using a design kit from ST and I have the 'short' device from
the 'STlib' in my schematic. But the LVS (or PLS as it is called here;
I'm using StarRCXT as extractor and Calibre for DRC, LVS) still tells me
that the LVS is incorrect:

(...)
Error: Different number of ports.
Error: Different number of nets.
Error: Different number of instances.
(...)
**missing instance**
** gnd **
** missing net **
(...)

The 'short' device from 'STlib' and the net shorted to gnd are not found
in the layout.

What can I do so that the missing 'short' device is ignored and the
shorted net connection created? Do I have to change someting in the
layout. Do I have to set special LVS options? I couldn't find anything
in the documentation.

I tried to add a 'lvsIgnore' property (value 'TRUE') to the 'short'
device in the schematic. LVS reports "correct" then, but if I use that
schematic/module as an instance in another schematic, LVS is incorrect
again.
LVS claims that a new net has been found, that is not in the schematic.
The new found net is the net, that should have been/is shorted to gnd.


Thanks for any help,

Andreas

 

[Andrew Beckett]

Andreas wrote, on 04/29/08 16:27:

Hello,

I've got a synthesized verilog netlists containing statements, which
connect signals to logic high or low, e. g.

assign xy = 1'b0; //The net xy is tied to gnd (logic low).

The problem is that I have no tiehi or tielo cells in my synthesis
libraries.

After importing the verilog netlist as a Virtuoso schematic into CDE,
these verilog assignments are replaced. Sometimes they're replaced by a
"cds_thru" cell from the "basic" library and sometimes by "short" cell
from the designkit. I don't understand why two different cells are used.

The real Problem occurs, when I want to do a LVS. The LVS tool tells me
that it can not find the "cds_thru" or "short" cells in the layout. LVS
results incorrect, although the layout is correct.

What can I do?

I already searched for an lvsIgnore property, but the "cds_thru" and
"short" cells don't have one.

Thanks for your help,

Andreas

The "short" (I assume that's equivalent to the "patch" component in the basic
library) effectively creates an alias in the database, which says that two net
names are equivalent. However, aliases can only be created when one of the nets
is internal (i.e. if both are terminals, or both globals, or one terminal and
one global, it can't do it). In that case, a "cds_thru" is used. cds_thru is
something I proposed a few years ago to solve precisely this problem - how to
create a "through" connection - which is perfectly possible in Verilog, but not
in the CDB database. What cds_thru does is get netlisted as an assign in
verilog, an "iprobe" (i.e. a zero-volt source) in spectre, a zero-volt source in
hspice, a "small" resistor in CDL (which can be filtered out in Physical
verification tools such as Dracula, Assura and Calibre), and so on. For Diva and
Assura using the auLvs view, you can add a removeDevice() call in your LVS
rules (I think it's filterDevice() for Assura) which shorts the device with a
particular name.

VirtuosoXL also knows how to treat this pseudo-device as a short.

The "patch" device shouldn't need any special handling though, as this should be
taken care of during netlisting - it will just map to use one of the aliased
names everywhere.

Regards,

Andrew.

 

[S. Badel]

The "short" (I assume that's equivalent to the "patch" component in the
basic library) effectively creates an alias in the database, which says
that two net names are equivalent.

Andrew,

Just out of curiosity, can you explain how the patch accomplishes this ? Is there some magic
involved (perhaps it's treated specially by the schematic editor because of the schType property ?).

In Andreas's case, the STlib short component is rather reminiscent of the cds_thru ; it doesn't
create any alias but gets netlisted as a very small resistor. To get rid of it in Calibre, it should
be filtered by adding a rule such as

LVS FILTER R(SH) SOURCE SHORT

Perhaps the kit provides some switch to automate this process, it would make sense.


Cheers,
Stéphane

 

[Riad KACED]

Ciao Andreas,

Since your problem is related to the ST PDK, I think it's working
asking your favorite CAD support over there in ST. They have got very
skillful and nice chaps, I'm convinced they will be doing their best
to get this issue sorted out for you ! I can give you some names and
feel free to mention myself as reference for your request, no
worries ...

Back to your problem :
The 'short' is just a little resistance (1m Ohm by mind) which
function is to break the connectivity. One typical of using this short
is to connect a net to 2 different ports.
When I was designing LDOs with ST, I have used the 'short' device in
the following case : Tying the output of the amplifier to 2 separate
out pins, I can explain the purpose if needed.
Physically, your layout looks like this : ( ===== is a metal path,
let say metal1).

/==============> Out
OA =========<
\==============> Feedback

This is obviously incorrect in terms of LVS since you've shorted your
Out/Feedback ports. The solution is then to insert something that
makes the LVS happy, that's the 'short' device.
ST provides a CAD maker called 'mkr short' or something like this that
your draw on to of the metal path as shown here :

/==============> Out
OA =========<
\======++++====> Feedback

The ++++ is the marker in question, you can make it overlapping the
metal wire a bit.
In terms of LVS, the Feedback pin is no more connected to Out but it
is now tied to a little resistor : R(SH) r=1e-3

Having a 'short' device in schematic and this marker in layout should
make you LVS smiling !

The 'short' device has a fundamental property : Its value is fixed
(i.e 1m Ohm) regardless :
1. How 'short' is the marker in layout : If your marker is overlapping
100um of a metal length, this 100um is considered as R=1e-3. If it is
only 0.1um, it is considered the same as well.
2. On which metal level. 2 markers on different metal levels (i.e with
different resistivity) will come with the same R=1e-3.
This has been made like this just to make the life of FE designers
easier. They are just worried about putting this device in their
schematic, no matter its value ...
Well, this solution is quite good in 0.25um, 0.18um technology nodes,
but when it comes to work with the CMOS 65nm process where designers
are hunting down every single miscalculation of the wire's RC, this
solution is just baned.

So if you are working with the 65nm PDK from ST, unless it changed
since I left, the 'short' marker is no more supported, you've to use
the metal resistance instead (rm1, rm2, ....). This is very annoying
since you've got any flexibility but it makes your simulations
accurate. The 'short' symbol is still available from the STLib
however. Why ? Simply because the STLib is a generic library which is
technology-independent, like the analogLib from cadence.

As far as I know, Nothing is set to make a smiley LVS with the short
device in the ST C065nm PDK.
A solution like : LVS FILTER R(SH) SOURCE SHORT won't work with the
previous test case I'm afraid (shortening two ports), give it a try to
confirm ...

So my conclusion is : Please contact your ST CAD support, they are one
of the best support teams I've ever known ;-)

Riad.

 

[Riad KACED]

Since your problem is related to the ST PDK, I think it's working
asking your favorite CAD support over there in ST. They have got very

I meant it is WORTH ASKING ... Sorry for the misspelling, It's bed
time I think ...

 

[Andrew Beckett]

S. Badel wrote, on 04/30/08 16:40:

The "short" (I assume that's equivalent to the "patch" component in
the basic library) effectively creates an alias in the database, which
says that two net names are equivalent.

Andrew,

Just out of curiosity, can you explain how the patch accomplishes this ?
Is there some magic involved (perhaps it's treated specially by the
schematic editor because of the schType property ?).

In Andreas's case, the STlib short component is rather reminiscent of
the cds_thru ; it doesn't create any alias but gets netlisted as a very
small resistor. To get rid of it in Calibre, it should be filtered by
adding a rule such as

LVS FILTER R(SH) SOURCE SHORT

Perhaps the kit provides some switch to automate this process, it would
make sense.


Cheers,
Stéphane

Hi Stéphane,

It does it by having magic properties on it, which is recognized by the
schematic extractor. I believe it is the "schType" property that is the root of
this. In fact it definitely is - I created my own component, and provided it has
schType on the symbol, with value "patchCord", it creates the alias during
schematic check. Any other value, it doesn't...

There are a few other legal values of schType, used for other things - which you
can find in the documentation with a little searching.

Andrew.