How to make buses in layout

Hi,
I made a bus in schematic such as A<0:30>.
And I gave each line a seperate label such as A<0>.
Does any one know how to do it in layout?

I found Cadence is sometimes quite stupid. It sometimes
can't recognize symmetrical layouts. So my layouts always have
troubles in LVS although I did nothing wrong in the layout.
Does any one know how to avoid that?

Thank you very much!



sincerely

 

It sometimes

what do you mean? the problem is either in your layout
or in your design kit's LVS rules. probably not in the
software.

 

Hi,

I don't know which LVS program you are using, but...

In Diva LVS there is a "Correspondence File" function in LVS form. Add some
(or all) mismatching bus nets/devices in schematic and layout as correspondence
points. This helps.


Regards

Sepe

 

In many years of use of Diva LVS software I have never found the
software to be wrong
once it declares the circuit to be clean, but ...

Often symetrical circuits will cause it to report errors that are false.
It often gets confused
when the nodecounts on nets are identical. (i.e. if two nets in the
layout AND two nets in the
schematic both connect to the same kind of device terminals) then Diva
LVS will get lost.
It just picks one and may mess it up.

The solution we would employ would be to break the symmetry by placing a
benign device
into the LAYOUT and Schematic. This could be a Pin (causing the user to
add a pin to his
layout, schematic, symbol. simulation view, cdf ... ) or to create a
non-parasitic Metal resistor
that is placed in both schematic & layout of one of the nets.

I found that Cadence Diva LVS is always quite stupid about certian
things. But once you learn why it gets
something wrong, the methods for coaxing it in the right direction are
simple.

 

There has been some recent work in handling what Diva LVS sees as
ambiguous circuits. These are the ones Gerry is talking about where
there are multiple nets that look the same and LVS is not able to
determine which is the correct pair to match.

The parameterMatchDegree rule provides a mechanism for using the
parameter values of devices to resolve ambiguity by selecting the
devices with the best parameter match. The user supplied SKILL routine
determines which parameters to compare and how well they match. Of
course, this will only help if your circuit has devices with different
parameter values.

In and of itself, parameterMatchDegree is not a complete solution to the
problem of ambiguous circuits, but when used with the "terminals as
correspondence points" option it goes a long way toward getting past the
ambiguity in many cases.

Use of a correspondence point file will always resolve the problem, but
the file content tends to become invalid after a new extraction run
since extraction tends to change the instance and net names in the
extracted view. This is another area being addressed by R&D in the very
near future through a mechanism that will allow you to specify fixed
instance names for drawn devices during extraction.


On the topic of busses, you cannot create a buss in a layout. In a
schematic, a buss is a logical construct representing multiple conductor
paths. Layout is entirely physical. A buss in the schematic has to be
drawn as separate conductors in the layout, just like an iterated
inverter instance in the schematic has to be drawn as the correct number
of inverters in the layout.

 

In the same way as for schematic, you have the possibility
to create the pins on a layout bus, by splitting the name
to A<0> A<1> .... A<30>

Virtuoso -> Create -> Pin ...
You enter in the menu :
Terminal Names = A<0:30>

If your bus is horizontal, you have to specify "Y Pitch"
otherwise you have to enter the pitch value for "X Pitch"

If you specify "X Pitch" and "Y Pitch", then the placement
of your pins will be non orthogonal ...

Of course if your bus has irregular pitch between the individual
wires, you may create first the pins and move them afterward.
This is the main difference with Composer which align
automatically the bus-splitted labels to be on the wires.

================================================================
Kholdoun TORKI
http://cmp.imag.fr
================================================================

 

When the layout has been generated under layoutXL/DLE, it would be a
rather easy job for diva extraction to reuse the device names and derive
netnames rather than use arbitrary ones. A shame it doesn t.

I have never tried to use lvsbx on a non-matching (partially matching)
LVS. If you have experience with this, could you tell if it interesting,
what pitfalls, et coetera ?

 

Actually, it is not possible to use the instance names assigned by
layoutXL/DLE since Diva flattens the layout to the shapes that will be
fabbed instead of believing whatever the cell says it is. You can easily
create a cell that claims to be a MOS device with a variety of
parameters, yet has no shapes that will actually create a MOS device on
the wafer. Perhaps macrocell mode can be enhanced to use the
hierarchical instance path name for macrocell instances.

There is a request for a rule to allow a text label to be used to assign
the instance name for a drawn device. The text of the label would be
prefixed with the hierarchical instance path name to the cell which
contains the label. It would not be hard for a cell placed by
layoutXL/DLE to contain such a text label over the recognition region of
the devices within the cell. Then extracted view would always have
predetermined instance names.

This same technique could even be applied to net labeling. Assuming
someone were to remember to file a PCR for it. Of course, care would
have to be taken to always place the net name labels over contacts or
pins so they are not lost when measureResistance is used since the
cutting of shapes into parasitic resistor bodies prevents geomConnect
from seeing a "connected" shape anywhere but at pins, contacts, and
slivers from the distribute option. And there would have to be a
protocol for name conflicts across hierarchy, or only local nets could
be named this way.


As for lvsbx, I cannot say much about it. I've never had a use for it.
Maybe someone else in the newsgroup has used it and can advise you about
ways it can be useful.

I do know there is a flow issue when you use lvsbx since the process of
changing net names in DFII changes the database ID of the net, causing
the cross-probe map files to become corrupt. After running lvsbx, you
have to rerun LVS (including a new extracted view netlist) so the maps
are rebuilt. There is a PCR for this so R&D will someday change lvsbx to
rebuild the maps so cross-probing continues to work correctly.

 

Indeed, the data from DLE should not be trusted as such, but simply
used to derive the name of an instance that has been properly
recognised. I assume here that we are talking about a flat extraction.
To achieve this, a way would be:
- block boundary geometries are saved in a special LPP like (block
drawing) during flatenning with the blockname property (strcat prefix
"," libname "," cellname "," viewname "," instancename) attached to it.
- where prefix is made up of all descended blocks, so that if you have a
hierarchy: nmos inside ringosc inside toplevel , the prefix will look
like "mylib,toplevel,layout,I0.mylib,ringosc,layout,I0."
- if it is not possible to use a property, one can use instead a label
writeen in our special layer with identical origin.

In fact, I wonder if placing a copy of the boundary and a label in a
special layer isn t something that could be done already by the pcell.
In which case there is no need for extra feature in
diva/assura/virtuoso: all the support for this would be in the pcells,
in the techfile (the extra layer) and in the divaEXT.rul

Thanks for the tip on lvsbx with Xprobe.