Net Tracing - Skill

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

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