It looks like you're new here. If you want to get involved, click one of these buttons!
Hello,
I've been trying to set up a script or workflow that would allow me to extract the netlist of a big (2GB layout) and check for shorts or opens.
"Trace All Nets → Flat" + "netlist browser" works wonderfully, but as mentioned in other places I read, it doesn't allow for filtering of cells to hide dummys.
Ideally, this process would also be nice to have it programatically, hence the use of DRC or using the "pya" API.
I found that any method I used it had some drawback that other ways don't, and viceversa:
UI | DRC | pya | |
---|---|---|---|
Programmatic | No | Yes (limited) | Yes |
Cell selection | No wildcard support | Yes | Yes |
Flat netlist | Yes | Yes | Can't find a way to do it/unclear for me in docs |
Convenience | Fastest | Slow, bottleneck when executing "input()" | Fast, but requires manual opening in correct layout |
"pya" I think would be best as it can import other functionalities seamlessly, and I'm most familiar with python syntax.
Btw:
execute_netlist
so no manual opening is needed, like netlist
does in "DRC"?pya.Technology().technology_by_name("technology_name").component("connectivity")
directly, and I'm currently forced to hardcode it or perform an inconvenient "for loop" for each connect()
Thanks!
Gerard
Comments
Hi @Tabra,
first of all, DRC is build upon Ruby, which is essentially pya, but in Ruby binding. There is no disadvantage of Ruby vs. Python. All DRC features are routed to corresponding API calls, so simply translating them to pya would give you the implementation. Specifically, I don't understand, why "input" should be slow compared to loading a layout into the UI.
The DRC implementation is here: https://github.com/KLayout/klayout/tree/master/src/drc/drc/built-in-macros.
Regarding your questions:
1.) For a flat netlist extraction, instantiate the
LayoutToNetlist
with cell name and DBU value (https://www.klayout.de/doc-qt5/code/class_LayoutToNetlist.html#method87).2.)
LayoutToNetlist
is much different from the net tracer feature, which is kind of legacy. So the interfaces won't fit. There is no direct bridge. The net tracer UI emulates the old net tracers connectivity and configuresLayoutToNetlist
correspondingly in 'trace all nets' mode. But that code is not available to pya.Matthias
Hi @Matthias,
Thank you for addressing my request.
And after looking through the DRC code, I found out that the netlist browser opening is performed when finishing the DRC script, and not with an explicit command. Using the following code works:
Btw I wrote a pya implementation to load the technology connectivity into l2n. Feel free to take it if you'd like:
Funny enough, using the function you mentioned gives the error:
RuntimeError: Internal error: deep shape store isn't singular. This may happen if you try to mix hierarchical layers from different sources our you use clipping. in LayoutToNetlist.make_polygon_layer
But it works by using the usual
RecursiveShapeIterator
Thank you very much again Matthias.
Gerard
Non-ideal at all and slow, but here's a working solution:
Hi @Tabra,
Thanks for the connectivity tracer tech stack conversion. This code is pretty much the same thing that the net tracer does internally. I still don't think that the net tracer stack description is a good one given the much more evolved capabilities of LayoutToNetlist, but if you're happy with that - it's your choice.
You should be able to do cell selection by manipulating the
RecursiveShapeIterator
you feed the shapes with. It has 'select_cells' and 'unselect_cells' to make it not deliver subtrees. See here for details: https://www.klayout.de/doc-qt5/code/class_RecursiveShapeIterator.htmlBut when do you get the internal error you mentioned?
Matthias
Hi @Matthias,
My take on using Technologies is that these are a convenient way to set up and select rules/connectivities all from the UI without the need of handling code. And more importantly, this kind of details makes the software more self-integrated and powerful, even if only apparent from the surface as there are still 2 netlist systems (maybe to be united in the future?).
Anyways, I found the ultimate solution. Turns out you CAN flatten the circuits post extraction with
l2n.netlist().flatten()
, and that's the best way I found WHILE allowing for filtering. Time-wise it's as fast as using UI'sTrace All Nets
, so it doesn't get any better than that.Although I'll modify it a bit to name the nets after the parent subcircuit + text points found over the net. I'm aware that running an LVS does kind of that, but I can't get it to work and maybe more control over the code solves it (not blackboxing my way)
Thank you for forcing me to look for the answer myself haha.
Bests,
Gerard