<@U016EM8L91B> Here is a tough one, I think there ...
# magich
Harald Pretl
11/13/2023, 4:47 PM@Tim Edwards Here is a tough one, I think there should be a solution for cases like this: We assembled the PEX netlist (created by Magic) of two blocks manually into one (PEX) SPICE netlist, each one containing standard cells. Strangely, simulation delivered weird results, while individual blocks were OK. @Patrick Fath debugged this over the weekend, and turns out: Port order on standard cells can change?!?
Q1: Is that even possible?
Q2: How can we make sure that cells (standard cells and otherwise) have a consistent pin order on extraction? Maybe the PEX should give cells a (random) name extension (like top cell name of extraction, or date/time code), so when adding two PEX netlists together, cells are kept unique, if there is no “guaranteed” port order on extraction.
e
Erik DeBenedictis
11/13/2023, 4:55 PMInteresting; this issue came up before in slack. Substrate connections got thrown to the end due to a bug (note the misplaced ports are VPB and VNB. The bug has been fixed, but there could be files created during the time of the bug that are still around. (I actually made a tool to detect extractor problems; it is called ext3spice because it runs on the output of ext2spice.)
🌍 1
h
Harald Pretl
11/13/2023, 5:24 PMInteresting. We are using a relatively new version of Magic, do you know when this should have been fixed? Please note that in the above example, more is mixed up than just the substrate connections.
e
Erik DeBenedictis
11/13/2023, 5:49 PMTim fixed the bug in May or so. I've been downloading your docker images and it has been fixed for months. I had a test case that is in the slack. The test case had just one transistor and a substrate connection. If you look back in the slack, you can use the .mag file to verify easily to verify presence/absence of this bug. I've found other bugs.
The nature of the bug Tim fixed is that the port numbers for nodes connected to the substrate were ignored. The result is that (a) the remaining numbered ports appeared in order, followed by (b) the ports tied to a substrate, the latter appearing in an arbitrary order. (I note that CLK D RESET_B Q would be the non-substrate ports in your example; all the others start with V and might touch a substrate somewhere.)
On the other topic, I made a program called ext3spice that you run on the output of ext2spice. Ext3spice puts the circuit into a consistent form that can be checked into version control (github, maybe). If you run a later version of extractor, you should get exactly the same output from ext3spice. Yet, if the new extractor introduces a bug, a vcs diff will show you what changed.
🌍 1
t
Tim Edwards
11/14/2023, 12:57 AM@Erik DeBenedictis: There have been multiple independent issues with port order. This is a different one.
Tim Edwards
11/14/2023, 1:01 AM@Harald Pretl: The netlist on the left has ports in alphabetical order which is how they are in the PDK (and the port order should be the same for all views in the PDK where port order matters). My hunch is that the netlist on the right was made after reading GDS. There is no standard for marking port order in GDS. Magic just makes sure that it always writes labels out in the GDS in monotonically increasing port order, so if it reads its own GDS back, the port order remains the same (at least, I think that's true). If you wrote GDS from, say, klayout, and read it back, then port order could be anything. That's my guess about how the port order got scrambled (openlane may use klayout to write GDS). Normally, this doesn't matter, because normally, one doesn't mix and match different netlists.
🌍 1
3 Views