Tracing of large power nets

Hi Matthias-

The tracing of a net like VSS/VCC/VDD can take some time because these are pretty large and contain many shapes/paths etc.
After starting the trace of such power net, the 'cancel' button in Klayout is very handy since I don't have to wait minutes or hours for it to finish, as it happens on other design tools.

I'm trying now to use the NetTracer to get the multiple traces of every contact in a certain selected area. Of course some of the contacts in this area are tied to power net. So the program gets 'stuck' waiting for the tracing of the large nets to finish.

My question: is it possible to limit the amount of shapes being traced by NetTracer? if not, can I put a timeout on the NetTracer?

Thanks, Itamar

Comments

  • Hi Itamar,

    That's possible of course, but the feature simply isn't there yet. I have created a ticket with this request: https://github.com/KLayout/klayout/issues/500

    There may be another option: have you tried tracing all nets (Tools/Trace all nets/Hierarchical)? This feature will collect all nets at once making use of hierarchy if possible. This can be fairly fast even with power nets. Having invested this time, probing is instantly. You can save the collected net geometries into a "layout-to-netlist database" and load it back later. However, there currently is performance issue in some cases (https://github.com/KLayout/klayout/issues/491). Still it may be worth trying. I have some examples myself, but I don't have sufficient experience with other kinds of hierarchy. Feedback is welcome.

    Kind regards,

    Matthias

  • Hi Matthias-

    I do not see the "Trace All Nets" option in the menu of Klayout 0.25 or 0.26.

    Thanks, Itamar

  • 0.25 does not have it, but 0.26 should. I'd recommend 0.26.3 as this is the latest and best one.

    Matthias

  • Matthias - I found this option in 0.26.3.
    I let it run overnight but got error message of 'std::bad_alloc'

  • Matthias-

    What are my options if i want to avoid tracing of large power nets?
    I was thinking of a few options, pls let know if you think one of those is feasible:

    1. Limit the amount of shapes for the NetTracer: as suggested above, but current version of Klayout will not support it.
    2. Timeout of NetTracer: is it possible to kill the tracing operation after some time and the program will resume the main code?
    3. Pre-mapping of all elements in a certain layer (eg contacts) that belong to large power nets: this mapping data will be saved and the main program will avoid tracing these specific contacts in the list. But not sure if such mapping is feasible. Maybe the Search and Replace can help?
    4. Send a 'cancel' command when netTracing takes too long: invoke OS to simulate the pressing of cancel button on the window popping due to a long netTrace. Again, not sure if feasible.

    Thanks, Itamar

  • Hi mikamar,

    std::bad_alloc, you'd need more memory. Do you use 64bit already? I'd say a decent PC with 16G of memory and a 64bit OS (preferably Linux) should be sufficient even for bigger cases. An option which isn't uncommon is to book cloud resources for such a task.

    The shape count limit is one of the tickets I'm going to do next, but my time is limited.

    Option 2 also requires a code change.

    Option 3 might be feasible, but I mapping the power nets to a new layer requires some tagging. Maybe it's sufficient to delete certain cells or wires with a specific width. But I can't say without knowing your layout.

    Option 4 is difficult in general without a code change. Simulating "Cancel" isn't much different from stopping the job.

    As KLayout is open source you're free to modify the sources yourself. Or you hire a student who does it for you.

    Matthias

  • Thanks for your time and patience. I have implemented a check that does a gradual bottom->tracing and based on layer\shape statistics determine if this is a power net or regular net.

  • edited February 27

    Hi,

    I'm about to release a new version (tomorrow I think) with an option to limit the number of shapes.

    If you want to try: https://www.klayout.org/downloads/master/ contains preliminary (unsigned) builds for Windows (look for 0.26.4 versions).

    Matthias

  • I tried it and it works fine. I'm sure it's going to help anyone tracing nets in heavy designs with massive power nets. I also have a guess that these heavy power nets are the cause for the memory issues related to all nets tracing (BTW, my PC has 8 cores + 64bit + 32Gb memory)

    I was wondering if the net depth tracing can be a part of the config names so it can be toggled by the code.

    Thanks for implementing it, it's a great support.

  • Hi mikamar,

    thanks for reporting this back. Of course, heavy designs take more memory for storing the results.

    The current implementation is not optimized for small memory footprint - there is probably room for improvement. A netlist data structure is somewhat more complex than geometry because of the many links between pins and nets and subcircuits etc.

    Best regards,

    Matthias

  • Hi Matthias-

    One more observation regarding large power nets tracing:
    I found out that if I start tracing by clicking on a gate tied eventually to huge top metal strip (sometimes this layer is called RDL re-distribution layer), Klayout will hang for ~1 minute but afterwards will show me the traced net (with the trace shape limit).
    If I trace the same net but this time from the top RDL layer, it will finish the trace in less than a second (and again with the trace shape limit)

    Maybe it can help understanding the performance issue.

    Best Regards, Itamar

  • edited May 6

    Hi Itamar,

    it's difficult to debug without an actual testcase. The (single net) tracer works incrementally, adding new additional shapes at each time. There may be cases in which this is not efficient and only a few shapes are added in each iteration. In this case, the algorithm might revisit shapes already seen many times over and over again. A test case would help.

    Regards,

    Matthias

Sign In or Register to comment.