The Cadence Academic Network helps build strong relationships between academia and industry, and promotes the proliferation of leading-edge technologies and methodologies at universities renowned for their engineering and design excellence.

A huge knowledge exchange platform for academia to network with industry. We are looking for academic speakers to talk about their research to the industry attendees at the Academic Track at CDNLive EMEA and Silicon Valley.

Custom IC SKILL Forums

Net Tracing - Skill

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.

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.

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.

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.

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.

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.

I am also working in net tracing functionality, but facing problem with the command dbGetTrueOverlap..I need to find the resistance of net once u probe it. For this concern i need to trace the net so that i can extract all the metal layers and vias to get the total resistance.

I don't see why you can't use dbGetTrueOverlaps - this should work fine. Maybe if you explained what your actual problem is (i.e. what you're doing, what your code looks like, what the error was, what is going wrong), then somebody might be able to spot what you're doing wrong? At the moment there really isn't enough to go on.

Currently (in IC61X) you can use Mark Net and then save the resulting shapes to another cellView, but there isn't currently a non-UI version of this (so you'd have to call the leHiMarkNet() and leHiSaveAllHighLightMarkNet() functions to save the shapes to another cellView). There's an enhancement request for a non "Hi" version of these functions.

I am working on a similar script to extract a complete net through a hierarchy and dump all these nets into a new cellview. Function dbGetTrueOverlaps returns the overlapping shapes present in a mosaic in the form list("mosaic_dbid" "row no" "column no").

Is it possible to get the xy of the extracted net figures present inside these mosaics(with the transformation information if this mosaic is present in some below hierarchy)?

Also, what can I do to filter these shapes present in the mosaics so that recursive procedure having dbGetTrueOverlaps function work efficiently?

leMarkNet and leSaveMarkNet are both in IC616. Rather than going to an awful lot of effort writing your own shape tracer, it would be far simpler to switch to using IC616 rather than IC615 (which should be a straightforward move). IC615 is not supported any more anyway.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.