skill code to find floating vias in layout

Are you using Virtuoso Layout XL? Without that, this is going to be pretty difficult - otherwise you're going to have to extract the connectivity somehow. With Layout XL this would be pretty trivial.

That said, I suspect you're not, because otherwise you probably wouldn't have the LVS problems...

I'm not entirely sure what you mean though - maybe a picture of an example would help? (use the Options tab to upload a picture when replying).

Regards,

Andrew.

Hi Andrew,

I am using Virtuoso XL, and I don't know the easy way to find floating vias in layout as you said. Let me explain the problem:

the sub block A is done by someone else, it is drc/lvs cleaned but it has some floating vias sitting alone somewhere in the block.

I am doing lvs on the top level which has A and B sub blocks( B also drc/lvs cleaned). Somehow, The floating vias in A short out two nets in B, and it took me a while to find out.

Another similar problem, both A and B are drc/lvs cleaned  and they have psub2 layer cover it. But psub2 layer not 100% fully cover the block A ( it intersect one nmos transistor for example), as a result when I run lvs on the top level, I have ground lvs error.

It would be helpful if I have a skill code to find

1) Floating vias in layout

2) The intersection between two layer shape in layout, for example psub2 and pplus

regards,

ha

Both of these checks would be better done by a DRC but here is how you would do it in SKILL:

1. Floating vias

In your cellView you would find all the via placements.
For each placement use dbGetTrueOverlaps on each routing in the via using the via bounding box. You would search 32 levels.
If the only shape returned by dbGetTrueOverlaps is in the via, you have a via that is floating on that layer. If running dbGetTrueOverlaps on both layers results only in the shapes in the via, you have a floating via.

 2. Layer Intersection

On the whole cellView use dbGetTrueOverlaps to find all the shapes on each of your layers.
The dbLayer functions only work with shapes in the current cellView. The dbGetTrueOverlaps return value include hierarchical shapes which you have to copy into the current cellView while transforming the points based on the origin/rotation of the hierarchical instances. I would use a scratch cell so I am not messing with the data in my design. You have to copy all the shapes, not just the hierarchical ones. dbCopyFig supports copying to a different cellView while applyinig a transform (origin/orientation).
Use dbLayerAnd on the shapes, ANDing between the two layers.
Generate markers based on the results of the AND in your design cellView to show the error.

dbGetTrueOverlaps is very powerful and you should get familiar with that function.

Ted

Hi Ted,

If floating vias are just big enough, drc can not catch them. DRC also don't do anything with PSUB2 layer

I am a layout guy, don't know much about writing SKILL. Could you be more specific about using dbGetTrueOverlaps in a procedure

format.

Thanks a lot,

ha

You would have to have someone write a specific DRC deck to find the floating vias and look for the PSUB2 layer problem. These are checks that you should request from your CAD support.

Sorry, I don't have access to write and test SKILL for outside customers, everything I write is owned by my clients. There are some other discussions on using dbGetTrueOverlaps with examples on this forum. You might also contact Cadence support because they have examples. You could also ask your CAD support to create the procedure.

Ted