magic
magic copied to clipboard
Bulk connection from subcells extracted wrongly
When extracting the spice file from the attached layout, the bulk in the subcell isource_diffamp is extracted wrongly. The spice file looks as follows:
X0 D2 G2 S2 B2 sky130_fd_pr__nfet_01v8 [..]
X1 D G S B sky130_fd_pr__nfet_01v8 [..]
X2 s3 g3 d3 b3 sky130_fd_pr__nfet_01v8_lvt [..]
X3 d3 g3 s3 b3 sky130_fd_pr__nfet_01v8_lvt [..]
X4 isource_diffamp_0/S isource_diffamp_0/G isource_diffamp_0/D B2 sky130_fd_pr__nfet_01v8_lvt [..] ...
You can see that for X4 the bulk connection in the spice file is B2, while it should be isource_diffamp_0/B
A workaround is to flatten the affected subcells. However, this only works for one hierarchy level. The procedure is the follows:
- Ensure each net has one unique label after flattening
- Save your design
- Select the affected subcells
select flat ; select keep- Do NOT save your design anymore. Instead extract your netlist, close magic and reopen the previously saved design.
For reference, this issue was also discussed in the skywater Slack channel.
All right, something broke dreadfully badly in the substrate handling that was supposed to fix such problems, as the .ext file shows that magic has identified the area inside the diffamp as the substrate, and not as an isolated pwell region, which is not supposed to be possible. I am looking into it now.
I just pushed version 8.3.272 which fixes the problem(s) above.
I have found an additional problem, which is, I think, a known existing problem, and your example is a conveniently small layout that exhibits it. If an additional circuit or layout is placed at just the right distance to the left of the layout, then one of the tiled areas that the extraction splits up the layout into cuts through the middle of the cell in deep nwell. That seems to cause magic to extract the isolated pwell by name on one side and by number on the other side, then it creates a extra pin for the 2nd net name. This is (at least in that case) transparent to simulation but probably an issue for LVS. I also need to see if I can make a version of that layout that could cause an incorrect extraction of the isolated pwell. This only happens if you try to label the substrate inside the subcell. But the substrate is labeled inside the SkyWater standard cells, so that has implications for standard cell layouts dropped into a deep nwell region.
Thanks, I now pulled the new version and tested it on my real design. While yesterday after flattening it was LVS clean, now at least one transistor seems to fall apart. I've attached the layout and schematic. Specifically, M11 seems to be falling apart.
From the file isource_flat.spice:
M11 should look like this:
X88 VM12D VM2D VM11D VN sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=4e+06u l=6e+06u
But there are now areas that get disconnected:
X98 VM12D VM2D VM11D dw_12120_8840# sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=4e+06u l=6e+06u
Here the bulk for a part of the transistor now gets connected to dw_12120_8840# which is floating. This is unexpected.
The top of the layout is isource.mag
Maybe magic would profit from taking such examples as unit tests to prevent regressions in the future.
Testing the current version of magic with another layout I have another observation.
In the layout there are from top to bottom:
- Resistors
- A differential pair made out of n-channel LVT transistors with a deep n-well around them
- Cascoded n-channel transistors.
The bulk of the differential pair is labeled B. The Bulk of the Cascode as well as the n-well under the resistors is connected to VN. When extracting the circuit, all bulks seem connected to B. Now delete the out_mirror_64t cell and undo the action. All of a sudden, the extraction is correct.
Sorry I did not see or respond to the post two spots above. The issue with that layout appears to be a wayward piece of "isosub" layer that was put at position (60.6um, 44.2um) to (61.8um, 44.7um) in the layout. I am not sure why it appears in the flattened netlist but not in the hierarchical netlist, but since it is located under a transistor but does not cover the entire transistor, its effect on the extraction is probably not well defined.
For bug2.zip---That should have been a straightforward extraction, and I will investigate.
I retried to extract the circuit and now it seems to be extracted correctly. Therefore closing this issue.