SKILL - Net cross-probing in Virtuoso Layout Editor

[Katie]

Please give me some general ideas on how to write a SKILL code with
these funtionality:
When user selects net in schematic and then calls skill function
(should be invoked by bindkey ) then
- the net in schematic is highlighted and all instances that are
connected to the net are selected.
- all corresponding instances in layout are selected ( even if user
doesn't use Virtuoso XL )
- all layout geometries ( paths, polygons, vias etc. that are
associated with the net are selected )

Thanks,

 

[Gerry Vandevalk]

Unless there are corresponding pins in the layout, then you have no
connectivity (yet) in the layout.

Once LVS is performed, then there is a crossmapping method you can perform.

When I did this ( several years ago ... ) I had to specify a text
crossmapping output be dumped.
With this ( and a health dose of experimentation ) I was able to write a
cross mapping function from the
schematic to the extracted reap and then Highlight the results over-top of
the layout!

Selecting the layout devices below the highlight (only ) is a bit tricky but
can be done.

YMMV

-- Gerry



"Katie" <hoa19ngo@gmail.com> wrote in message
news:1129065910.275721.165180@g14g2000cwa.googlegroups.com...

Please give me some general ideas on how to write a SKILL code with
these funtionality:
When user selects net in schematic and then calls skill function
(should be invoked by bindkey ) then
- the net in schematic is highlighted and all instances that are
connected to the net are selected.
- all corresponding instances in layout are selected ( even if user
doesn't use Virtuoso XL )
- all layout geometries ( paths, polygons, vias etc. that are
associated with the net are selected )

Thanks,

 

[tattvamasi@gmail.com]

There are several ways I am documenting below very briefly one such
way,

When user selects net in schematic and then calls skill function
(should be invoked by bindkey ) then
- the net in schematic is highlighted and all instances that are
connected to the net are selected.

## Use
dbFindNetByName( cvs nname)~>figs to get the nets and then you can get
the instances connected in the schematic for that net.

Where cvs is deGetCellView() and nname = netname in schematic

- all corresponding instances in layout are selected ( even if user
doesn't use Virtuoso XL )

## The devices in the layout should have connectivity in them. The
instance terminals of the pcells in the layout should have connectivity
information in the instTerms.
to check do css()~>instTerms, while in the layout.
If they do,
then you may use
dbFindSigByName(cvl nname)~>memInstTerms
to get all the instTerms,
Looping on which you can find all the instFigures,
~>term~>pins~>fig
and finally use
dbTransformBBox,
to transform the pin bbox to the cellview and draw gemetries around it
to highlight that net.

- all layout geometries ( paths, polygons, vias etc. that are
associated with the net are selected )

## You can do this only if there are connectivity information stored in
the layout geometries.

Looks like you are basically asking for V-XL functionality without that
actual tool..

 

[Edward J Kalenda]

On 11 Oct 2005 14:25:10 -0700, "Katie" <hoa19ngo@gmail.com> wrote:

Please give me some general ideas on how to write a SKILL code with
these funtionality:
When user selects net in schematic and then calls skill function
(should be invoked by bindkey ) then
- the net in schematic is highlighted and all instances that are
connected to the net are selected.
- all corresponding instances in layout are selected ( even if user
doesn't use Virtuoso XL )
- all layout geometries ( paths, polygons, vias etc. that are
associated with the net are selected )

Thanks,

This sounds very much like what Diva LVS cross-probing does. It requires
Diva LVS to have been run, with a good match result, to create the cross
reference data. The probes are between the schematic and the extracted
view, not the layout, which is not quite what you were asking for.
Mapping from the extracted view to the layout is manual and works best
when the divaEXT.rul file is written so the extracted view shapes are
fairly close to the layout view shapes.

 

[Fergus_S]

It is possible to do what you want even without connectivity info in
the layout, but you'll need to write some heavy-duty code to figure
that out on the fly.

Briefly:

- get the schematic net and highlight all the shapes
- go through the net~>instTerms to get instances to select

- using the schematic net name, find the corresponding pins and/or
labels in the layout.
- find shapes connected to the pins/labels using dbGetTrueOverlaps on
the current/above/below layers (e.g. m1, via1 and cont). Iterate
until you find all connected shapes ... this is the hard part

- Selecting layout instances is trivial if you use the same instance
names as in the schematic (highly recommended) - if not, you'll need
to use dbGetTrueOverlaps again to find where your net shapes connect
to shapes inside an instance.

fergus

Katie wrote:

Please give me some general ideas on how to write a SKILL code with
these funtionality:
When user selects net in schematic and then calls skill function
(should be invoked by bindkey ) then
- the net in schematic is highlighted and all instances that are
connected to the net are selected.
- all corresponding instances in layout are selected ( even if user
doesn't use Virtuoso XL )
- all layout geometries ( paths, polygons, vias etc. that are
associated with the net are selected )

Thanks,

 

[Katie]

Thanks so much for the document. Yes, I am trying to create the
probing V-XL functionality on Vituoso Layout Editor. Thanks again for
your help.

Katie


tattvamasi@gmail.com wrote:

There are several ways I am documenting below very briefly one such
way,

When user selects net in schematic and then calls skill function
(should be invoked by bindkey ) then
- the net in schematic is highlighted and all instances that are
connected to the net are selected.

## Use
dbFindNetByName( cvs nname)~>figs to get the nets and then you can get
the instances connected in the schematic for that net.

Where cvs is deGetCellView() and nname = netname in schematic

- all corresponding instances in layout are selected ( even if user
doesn't use Virtuoso XL )

## The devices in the layout should have connectivity in them. The
instance terminals of the pcells in the layout should have connectivity
information in the instTerms.
to check do css()~>instTerms, while in the layout.
If they do,
then you may use
dbFindSigByName(cvl nname)~>memInstTerms
to get all the instTerms,
Looping on which you can find all the instFigures,
~>term~>pins~>fig
and finally use
dbTransformBBox,
to transform the pin bbox to the cellview and draw gemetries around it
to highlight that net.

- all layout geometries ( paths, polygons, vias etc. that are
associated with the net are selected )

## You can do this only if there are connectivity information stored in
the layout geometries.

Looks like you are basically asking for V-XL functionality without that
actual tool..

 

[Katie]

No, I don't want to do the probe through Diva. I want to do it on
Virtuoso Layout Editor.

Thanks,

 

[DReynolds]

Katie, as another person who has written this kind of code before
(with limited success) here are some of the issues I expect you will
run across:

If you do geometry based processing based on overlaps and such...
beware of vdd and gnd nets... these tend to have large via arrays
that tend to drive geometry based code crazy! If you have some way of
treating via arrays as a single object it will help.

Do any of your users have busses in the schematic? If so then any net
based code will have to be expanded to handle busses (in all the
various formats that they can be written)

Do any of your users have iterated instances of transistors or cells?
If so any instance name based code will have to be expanded to cover
it.

Are you layout hierarchies EXACTLY the same as the schematic? If not,
it gets very complicated to do name based code...

Do your users do any many to 1 or 1 to many mappings? If so, it is
harder on the code to track

are you going to replace vituoso simple paths with rod paths and give
them net info... if so it can help when you run the code a second
time.

these are the issues I remember from my attempts... as long as the
users do simple one to one nets and instances, it is not too bad, but
he exceptions kill!


hope this helps

David

 

[Andrew Beckett]

On Fri, 14 Oct 2005 11:10:12 -0500, david.reynolds@ieee-dot-org.no-spam.invalid
(DReynolds) wrote:

Katie, as another person who has written this kind of code before
(with limited success) here are some of the issues I expect you will
run across:

If you do geometry based processing based on overlaps and such...
beware of vdd and gnd nets... these tend to have large via arrays
that tend to drive geometry based code crazy! If you have some way of
treating via arrays as a single object it will help.

Do any of your users have busses in the schematic? If so then any net
based code will have to be expanded to handle busses (in all the
various formats that they can be written)

Do any of your users have iterated instances of transistors or cells?
If so any instance name based code will have to be expanded to cover
it.

Are you layout hierarchies EXACTLY the same as the schematic? If not,
it gets very complicated to do name based code...

Do your users do any many to 1 or 1 to many mappings? If so, it is
harder on the code to track

are you going to replace vituoso simple paths with rod paths and give
them net info... if so it can help when you run the code a second
time.

these are the issues I remember from my attempts... as long as the
users do simple one to one nets and instances, it is not too bad, but
he exceptions kill!


hope this helps

David

Exactly. What Katie is trying to do is much of what Virtuoso XL has to do in its
extractor, or what a physical verification tool would do to extract the layout
(that has to worry about device identification too).

Doing all this is far from trivial, for the reasons (amongst many others) that
David points out.

Regards,

Andrew.

 

[Gerry Vandevalk]

I would suggest that simply running layout extract would simplify this and
then back annotating this to the layout somehow.
( Of course the backannotating is not trivial, but then you only need an
extract license to solve all sorts of problems that
this thread has discussed! )


"Andrew Beckett" <andrewb@DcEaLdEeTnEcTe.HcIoSm> wrote in message
news:7ni7l1tlimk878rmr1qo5efdfm7oskmt5t@4ax.com...

On Fri, 14 Oct 2005 11:10:12 -0500,
david.reynolds@ieee-dot-org.no-spam.invalid
(DReynolds) wrote:

Katie, as another person who has written this kind of code before
(with limited success) here are some of the issues I expect you will
run across:

If you do geometry based processing based on overlaps and such...
beware of vdd and gnd nets... these tend to have large via arrays
that tend to drive geometry based code crazy! If you have some way of
treating via arrays as a single object it will help.

Do any of your users have busses in the schematic? If so then any net
based code will have to be expanded to handle busses (in all the
various formats that they can be written)

Do any of your users have iterated instances of transistors or cells?
If so any instance name based code will have to be expanded to cover
it.

Are you layout hierarchies EXACTLY the same as the schematic? If not,
it gets very complicated to do name based code...

Do your users do any many to 1 or 1 to many mappings? If so, it is
harder on the code to track

are you going to replace vituoso simple paths with rod paths and give
them net info... if so it can help when you run the code a second
time.

these are the issues I remember from my attempts... as long as the
users do simple one to one nets and instances, it is not too bad, but
he exceptions kill!


hope this helps

David

Exactly. What Katie is trying to do is much of what Virtuoso XL has to do
in its
extractor, or what a physical verification tool would do to extract the
layout
(that has to worry about device identification too).

Doing all this is far from trivial, for the reasons (amongst many others)
that
David points out.

Regards,

Andrew.

 

[Gerry Vandevalk]

I would suggest that simply running layout extract would simplify this and
then back annotating this to the layout somehow.
( Of course the backannotating is not trivial, but then you only need an
extract license to solve all sorts of problems that
this thread has discussed! )


"Andrew Beckett" <andrewb@DcEaLdEeTnEcTe.HcIoSm> wrote in message
news:7ni7l1tlimk878rmr1qo5efdfm7oskmt5t@4ax.com...

On Fri, 14 Oct 2005 11:10:12 -0500,
david.reynolds@ieee-dot-org.no-spam.invalid
(DReynolds) wrote:

Katie, as another person who has written this kind of code before
(with limited success) here are some of the issues I expect you will
run across:

If you do geometry based processing based on overlaps and such...
beware of vdd and gnd nets... these tend to have large via arrays
that tend to drive geometry based code crazy! If you have some way of
treating via arrays as a single object it will help.

Do any of your users have busses in the schematic? If so then any net
based code will have to be expanded to handle busses (in all the
various formats that they can be written)

Do any of your users have iterated instances of transistors or cells?
If so any instance name based code will have to be expanded to cover
it.

Are you layout hierarchies EXACTLY the same as the schematic? If not,
it gets very complicated to do name based code...

Do your users do any many to 1 or 1 to many mappings? If so, it is
harder on the code to track

are you going to replace vituoso simple paths with rod paths and give
them net info... if so it can help when you run the code a second
time.

these are the issues I remember from my attempts... as long as the
users do simple one to one nets and instances, it is not too bad, but
he exceptions kill!


hope this helps

David

Exactly. What Katie is trying to do is much of what Virtuoso XL has to do
in its
extractor, or what a physical verification tool would do to extract the
layout
(that has to worry about device identification too).

Doing all this is far from trivial, for the reasons (amongst many others)
that
David points out.

Regards,

Andrew.