Multiple layout instances with one schematic instance

Hiya,

I'm doing an RF-CMOS design, and as part of the layout have filled
unused areas with a bypass cell. There are a many hundreds of these
cells on the layout. Rather than having to fill my schematic with a
corresponding number of bypass instances, I was wondering if it was
possible to use just one, with a parameter to indicate multiple layout
instances.

My design kit (IBM) has a parameter called Multiplicity that's attached
to many pcells as CDF data, so I tried adding this parameter to my
bypass component using the CDF editor with no luck. It's simply
ignored when I run LVS, so LVS reports that there is a differing number
of components between the extracted and schematic views.

Anyone have any ideas?

Regards,

Suzy

 

[fogh]

Suzy.Jackson@csiro.au wrote:

David Cuthberts idea of using iterated instances in the schematic works
a treat. All I have to do is count the number of bypass instances in
the layout, and enter that in the schematic.

That is a good solution for the problem you have. But when you use another tech,
you can better try multiplicity first. Multiplicity is passed to the pcell, so
you can have all subdevices placed and connected, whereas iterated instance
(vector of devices) is something you have to lay out yourself.

 

[David Cuthbert]

Suzy.Jackson@csiro.au wrote:

My design kit (IBM) has a parameter called Multiplicity that's attached
to many pcells as CDF data, so I tried adding this parameter to my
bypass component using the CDF editor with no luck. It's simply
ignored when I run LVS, so LVS reports that there is a differing number
of components between the extracted and schematic views.

Anyone have any ideas?

Hm... that's peculiar. I'll check the PCR database at work tomorrow to
see if it's a known issue; it could be the PDK, too, though.

In the meantime you could try using iterated instances; just give the
bypass component a name in the form I<n:m>. For example, I<1:7> would
netlist out to seven devices with the names I<1>, I<2>, I<3>, ..., I<7>.
In Virtuoso XL, the angle brackets become parens: |I(1), |I(2), ...

Hope this helps.

 

[G Vandevalk]

(are these cells in parallel?) Permute parallel? (assuming you modify the
lvs deck!)
If not place an iterated instance.

Tell extract to ignore them? (ReadThe Manual! Not for the faint of heart!)

What is a bypass cell? Does it contain any active devices.
(If not, and the supply nets are connected, a properly written lvs deck can
be set up to prune them!)
(This again assumes you examine and modify the lvs deck if required)

You say the lvs netlister ignores the multiplicity cdf. Have you looked at
the CDF in question?
(note that the lvs deck must be crafted to expect this parameter or it is
not useful to try to
netlist this out to LVS.)

If the device is truly a parasitic, then the deck can be written to ignore
it.
also adding a lvsIgnore property of true to the symbol can prevent it from
being netlisted to lvs.
This is only ok for true parasititics that are not feedthru's (i.e.
different code is needed for parasitic resistors!)


--
Gerry Vandevalk vdvalk@rogers.com
IC Tooling Ltd. www.ictooling.com
613-831-1572 613-240-5326(mobile)
3 Jacqueline Crescent,Stittsville
Ontario,Canada K2S 1M1

<Suzy.Jackson@csiro.au> wrote in message
news:1108616066.375524.94530@c13g2000cwb.googlegroups.com...

Hiya,

I'm doing an RF-CMOS design, and as part of the layout have filled
unused areas with a bypass cell. There are a many hundreds of these
cells on the layout. Rather than having to fill my schematic with a
corresponding number of bypass instances, I was wondering if it was
possible to use just one, with a parameter to indicate multiple layout
instances.

My design kit (IBM) has a parameter called Multiplicity that's attached
to many pcells as CDF data, so I tried adding this parameter to my
bypass component using the CDF editor with no luck. It's simply
ignored when I run LVS, so LVS reports that there is a differing number
of components between the extracted and schematic views.

Anyone have any ideas?

Regards,

Suzy

 

[S.Badel]

I don't know what's your bypass cell, neither do I know what software
you use for LVS but i can guess/tell/ask the following:

- bypass is a "dummy cell" (or do you have some instance that "count"
and others that do not?)

- you want lvs to pass regardless of the number of these cells (ie you
want to ignore them, or do you want to match the number?)

LVS softs usually have a mechanism to "ignore cells", typically for
dummies. it can be dangerous but if you know what you're doing it's
fine. for example in diva you can add a property 'lvsIgnore' (not 100%
sure of the name...) to do that. assura has parameter named '?ignoreCell'.
As to have the cells merged into a single 'parrallel equivalent' with m
extracted, it doesn't seem possible (as is) to me. this works only for
mos/res/cap etc.. (lvs just cannot merge any cell - two opamps merged
into one with m=2 does this make sense?). on trick could be to extract
the cell as a device (tell him it's a capacitor for example). then they
could be merged.

maybe you can provide more details

cheers
stéphane


Suzy.Jackson@csiro.au wrote:

Hiya,

I'm doing an RF-CMOS design, and as part of the layout have filled
unused areas with a bypass cell. There are a many hundreds of these
cells on the layout. Rather than having to fill my schematic with a
corresponding number of bypass instances, I was wondering if it was
possible to use just one, with a parameter to indicate multiple layout
instances.

My design kit (IBM) has a parameter called Multiplicity that's attached
to many pcells as CDF data, so I tried adding this parameter to my
bypass component using the CDF editor with no luck. It's simply
ignored when I run LVS, so LVS reports that there is a differing number
of components between the extracted and schematic views.

Anyone have any ideas?

Regards,

Suzy

 

[Diva Physical Verificatio]

Not knowing what tool you are using, I will respond as if it is Diva, my
area of expertise.

Assuming these bypass cells are being extracted as capacitors, as in
bypass caps spread around to reduce power supply transients, yes there
is a way to deal with them simply, in the way you describe.

The LVS rule deck must have a permuteDevice(parallel) rule for the
device type the capacitor netlists as. Referenced by that rule is a
SKILL procedure that combines the values, either by adding them
together, or by counting how many there are with the same value. This
allows the comparison routine to effectively see one layout capacitor.
Your schematic capacitor would have the total capacitance, or the count,
as a property that gets netlisted. This lets the SKILL procedure in the
compareDeviceProperty rule validate the number of capacitors.

I would expect IBM to have supplied a LVS rule deck to handle the
parallel capacitors, since the extract deck is recognizing them. Perhaps
contacting the design kit group at IBM would be a good idea. I will be
happy to look at the rule deck and send you specific advice if you can
email it to me, along with small schematic and layout netlists. Extract
a small dummy design with the bypass capacitors, run LVS, then send me
the divaLVS.rul, layout/netlist and schematic/netlist from the run
directory. I do not need the layout and schematic cells for this.

An alternative approach is to not have a schematic capacitor and use the
removeDevice rule to have the layout instances ignored. This assumes you
do not have the need to check for the correct number of bypass
capacitors, and that it does not matter what they are connected to. I
find this a less than acceptable approach, since removeDevice cannot
check that the device is only connected to power and ground. An
improperly connected bypass capacitor is effectively a short between two
active signal nets.

On 16 Feb 2005 20:54:26 -0800, Suzy.Jackson@csiro.au wrote:

Hiya,

I'm doing an RF-CMOS design, and as part of the layout have filled
unused areas with a bypass cell. There are a many hundreds of these
cells on the layout. Rather than having to fill my schematic with a
corresponding number of bypass instances, I was wondering if it was
possible to use just one, with a parameter to indicate multiple layout
instances.

My design kit (IBM) has a parameter called Multiplicity that's attached
to many pcells as CDF data, so I tried adding this parameter to my
bypass component using the CDF editor with no luck. It's simply
ignored when I run LVS, so LVS reports that there is a differing number
of components between the extracted and schematic views.

Anyone have any ideas?

Regards,

Suzy

 

Diva Physical Verification wrote:

An alternative approach is to not have a schematic capacitor and use
the
removeDevice rule to have the layout instances ignored. This assumes
you
do not have the need to check for the correct number of bypass
capacitors, and that it does not matter what they are connected to. I
find this a less than acceptable approach, since removeDevice cannot
check that the device is only connected to power and ground. An
improperly connected bypass capacitor is effectively a short between
two
active signal nets.

Your guess is correct, I am using Diva for LVS. My knowledge of
Cadence is pretty rudimentary though, and I have no idea what an LVS
deck is. I just run the LVS and then try to interpret the error
messages in the output

The physical device that I'm using as a bypass capacitor is a pair of
fets connected back-to-back, such that their combined source gate
capacitance is across the power supply. The metal layers above the
fets have two stripes each, forst vertical, then horizontal, etc up
through the stack, with contacts through the stack connecting all the
stripes to power and ground. The idea is that by butting two or more
of the cells together, power and ground are distributed through the lot
with nice low impedance. They use up extra area on the chip, and
ensure the density rules are met.

The actual number isn't important, as they're just being used to bypass
power and DC control nets to ground. However I still want them to be
included in the DRC, as if I connect one up wrong it'll invariably
result in a vdd-gnd short, which would be frustrating.

David Cuthberts idea of using iterated instances in the schematic works
a treat. All I have to do is count the number of bypass instances in
the layout, and enter that in the schematic.

Thankyou all for your help.

Regards,

Suzy

 

[Andrew Beckett]

On Fri, 18 Feb 2005 10:20:24 +0100, fogh
<cad_support@skipthisandunderscores.catena.nl> wrote:

Suzy.Jackson@csiro.au wrote:
David Cuthberts idea of using iterated instances in the schematic works
a treat. All I have to do is count the number of bypass instances in
the layout, and enter that in the schematic.

That is a good solution for the problem you have. But when you use another tech,
you can better try multiplicity first. Multiplicity is passed to the pcell, so
you can have all subdevices placed and connected, whereas iterated instance
(vector of devices) is something you have to lay out yourself.

(although if you're using VXL, it may not make that much difference, if the
kit supports autoabutment of the devices).

Also, it's less efficient from a simulation point of view, because iterated
instances create more devices and a bigger matrix to solve, rather than being
taken account of as a separate multiplier in the model. There are cases where
you want them to be separate, but they are few.

I'd raise this with the PDK vendor.

Regards,

Andrew.

 

[fogh]

Andrew Beckett wrote:

On Fri, 18 Feb 2005 10:20:24 +0100, fogh
cad_support@skipthisandunderscores.catena.nl> wrote:
Suzy.Jackson@csiro.au wrote:
David Cuthberts idea of using iterated instances in the schematic works
a treat. All I have to do is count the number of bypass instances in
the layout, and enter that in the schematic.

That is a good solution for the problem you have. But when you use another tech,
you can better try multiplicity first. Multiplicity is passed to the pcell, so
you can have all subdevices placed and connected, whereas iterated instance
(vector of devices) is something you have to lay out yourself.


(although if you're using VXL, it may not make that much difference, if the
kit supports autoabutment of the devices).

Also, it's less efficient from a simulation point of view, because iterated
instances create more devices and a bigger matrix to solve, rather than being
taken account of as a separate multiplier in the model. There are cases where
you want them to be separate, but they are few.

I'd raise this with the PDK vendor.
Or recommend ultrasim again ?

So it is really never going to happen, this "virtual shorting" in spectre
(outside montecarlo and dcmatch) ?

I was wondering about another simulation efficiency question: not consider the
gnd! given in the netlist as the reference node, but pick instead that node that
has the most connectivity. That would improve sparsity. Then again, I suppose
that purely numerical techniques (preconditionning ) do a better job than those
half-hearted electrical considerations of mine.

 

[Andrew Beckett]

On Fri, 18 Feb 2005 16:07:51 +0100, fogh
<cad_support@skipthisandunderscores.catena.nl> wrote:

Also, it's less efficient from a simulation point of view, because iterated
instances create more devices and a bigger matrix to solve, rather than being
taken account of as a separate multiplier in the model. There are cases where
you want them to be separate, but they are few.

I'd raise this with the PDK vendor.
Or recommend ultrasim again ?

So it is really never going to happen, this "virtual shorting" in spectre
(outside montecarlo and dcmatch) ?

I didn't say that. That said, from a quick scan, I couldn't find a PCR for
this. I know Assura-RCX can do this combination of parallel devices leading
to an m-factor, though.

I do have a PCR for the other way:

PCR: 419311
Title: montecarlo and dcmatch need to allow mismatch with m factor

Which is to allow you to use m-factor, but still be able to use statistical
analyses on the individual subdevices.

I was wondering about another simulation efficiency question: not consider the
gnd! given in the netlist as the reference node, but pick instead that node that
has the most connectivity. That would improve sparsity. Then again, I suppose
that purely numerical techniques (preconditionning ) do a better job than those
half-hearted electrical considerations of mine.

I don't think it would help that much (if at all). You can always try it by
using spectre's global statement - the first node in the list of global nodes
is taken as the reference (see "spectre -h global" for more details).

Regards,

Andrew.