Net Tracing - Skill > Forums > www.cdnusers.org

Unanswered

Active Topics

Forums

Forums > Custom IC > Shared code - SKILL

Subject: Net Tracing - Skill

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

rimser9
Posts: 0
Online: User is Offline

7/30/2007 11:43 PM
Hello All , I have a script which I use to calculate a particular net's Net Length, total net resistance, Capacitance (w.r.t ground). But the drawback is that I have to select the entire Net before invoking the "NetLength" Function. So I want a script which can trace the entire net and give a list of metals, vias, instances that belong to this net. i.e I will select any one metal/instance/via of a net and the code should trace the entire net and give me the desired o/p. NOTE: Instances here refer to instances/mosaics of vias. Thanks, Sathya

adbeckett
Posts: 248
Online: User is Offline

7/31/2007 12:45 AM
Well, if the layout was created using Virtuoso XL, then this is easy - since all shapes on the net will be associated with the net in the database. Other than that, you could use Diva to extract a net - or you'd have to write something which traced the net - not that straightforward. Regards, Andrew.

rimser9
Posts: 0
Online: User is Offline

7/31/2007 1:21 AM
Thanks Andrew. Thats what I was asking for. A skill code which can trace the net in Virtuoso Layout Editor. Regards, Sathya

dmay
Posts: 29
Online: User is Offline

7/31/2007 8:39 AM
I wrote some skill code to do this and presented it at the 2002 Cadence Users Group. It was no small program, but basically used dbGetTrueOverlaps on shapes decomposed into rectangles. If your nets are not traversing the hierarchy, then using VXL connectivity information is the easiest way to go. DIVA also provides a quick extraction, but custom Skill was the only way we found that we could extract the shapes from any level of hierarchy by clicking on a shape. I can't give you the code, but I have attached my paper and presentation from the 2002 conference. The effort to write the code has paid off many times over. We can click on a net and hilight it, but we then have all the shapes and can do whatever we want with them. -Derek
Attachment: ICU2002_77.doc

dmay
Posts: 29
Online: User is Offline

7/31/2007 9:23 AM
I reread the first post and you mention that you "select" every shape on the net first. If this is the case, then VXL is your best bet. VXL adds connectivity to the shapes on the same net. You can then select all shapes on a net with something as simple as this: shapes = setof(x geGetEditCellView()~>shapes x~>net~>name == "mynet") You can get every instance (including vias) connected to the net using: insts = setof(x cv~>conns x~>net~>name=="mynet") The paper I attached describes how to get all shapes in the hierarchy of the design on a net, all the way down to the gate without needing VXL. -Derek

rimser9
Posts: 0
Online: User is Offline

7/31/2007 8:59 PM
Hi , Im using only VLE not VXL so I think I will just read ur paper and try to write my code myself. Meanwhile if there are nayone out there who can give the code are welcome. Thanks,

m27315
Posts: 24
Online: User is Offline

8/10/2007 10:08 AM
Derek, I have written a similar tracing function, but I find the "Mark Net" function to be dramatically faster. dbGetTrueOverlaps has to be one of the most powerful functions in SKILL, but at the same time, it has to be the slowest. I'm curious if you can share any tips or thoughts on the performance aspects of this problem. For me, "Mark Net" is too fast to compete with it in SKILL for displaying purposes (compare tracing VSS! in a real chip). But, if you want the list of shapes for post-processing, like in Sathya's case, I think you need a SKILL function, like the one you have written. Therefore, the problem cannot be entirely bypassed by using "Mark Net", unless you only need to display the shapes. Thanks!

dmay
Posts: 29
Online: User is Offline

8/10/2007 12:27 PM
m27315, I put a lot of work into improving the performance and tracing supplies is definitely slow. However, my routine actually traces supplies faster than markNet. The main thing I did was limit dbGetTrueOverlaps to only check one layerName across all levels of hierarchy. It was only ever checking for overlaps on one metal layer at a time. I had a table of via names used in the design and the names of the layers that were connected by each via. Every via in our design contains the cut layer and the connecting metals. example: Via name Connecting metals "VIA1" list("metal1" "metal2") "VIA2" list("metal2" "metal3") "CON" list("poly" "metal1") Every overlapping metal shape was checked to see if it was inside one of the vias. If it was, then that shape was used to look for overlaps on both connecting metals. I never looked for overaps on the cut layers, otherwise things would be very slow. If someone accidentally flattens a via or contact, my routine will not trace connectivity through it. The trade off basically came down to speed or ability to handle flat data. I have considered adding an option to trace the flat data, but no one has ever needed it. They usually fix the flat vias instead. Basically, I start with a metal shape, break it into rectangles and run dbGetTrueOverlaps on each rectangle, only looking for shapes on the same layer. I have a filtering routine that ensures I throw out items I have already visited. When the overlaps routine returns a shape in a via cell, I then run a second dbGetTrueOverlaps on the connecting layer. My benchmarks on a supply signal in a medium sized block showed the following: Mark Net: 446 seconds My trace: 335 seconds (55 seconds in dbGetTrueOverlaps) My routine still has room for improvement. -Derek

Posting to forums is available to community members only.
Login or Register

Forums > Custom IC > Shared code - SKILL > Net Tracing - Skill

ActiveForums 3.6