Hello, we're having trouble with extracting a layo...
# sky130
f
Hello, we're having trouble with extracting a layout and then running ext2spice for an LVS. This seems to be due to Magic reading two relative paths and interpreting them as different, despite them pointing to the same place. Our project structure has two subcells in two separate folders, and both of them instance a subcell which is contai ned in one of the two folders. When Magic runs into this, it outputs the following error:
Duplicate cell in parent2:  Instance of cell pmos_waffle_48x48 is from path cell2/../cell1 but cell was previously
read from cell1.
Cell name conflict:  Renaming original cell to pmos_waffle_48x48#0.
I've included a reproducible version with the problematic subcell pmos_waffle_48x48, two parent subcells, and a top cell. The error comes up upon expanding the cells in top.mag, and after extraction, ext2spice fails as it cannot find pmos_wa ffle_48x48#0.ext. I've tried adding the paths via addpath and dereferencing the parent cells, but it doesn't seem to help. Does anyone know how to deal with these kind of path conflicts, or how to get ext2spice to ignore the #0 when looking for ext files?
m
@Francisco Aguirre Thanks for the detailed test case! What version of magic are you using?
I’m able to duplicate with the latest version of magic. @Tim Edwards would it be possible to keep in memory the stated path of instances in the mag file and the real path with links and
..
resolved? When a new instance reference is read, the real path is compared to the current real path and the cell would be renamed only if the real path was different.
@Francisco Aguirre This is what I did to extract with no duplicate cells
Copy code
cp $PDK_ROOT/$PDK/libs.tech/magic/$PDK.magicrc .magicrc
cat >> .magicrc <<EOF
addpath \$env(PWD)/waffle
EOF
mkdir waffle
mv cell1/pmos_waffle_48x48.mag waffle
mv cell1/waffle_cells waffle
sed -i.bak 's,../cell1,,' cell2/parent2.mag
f
I'm using magic version 8.3 revision 416. I can confirm your solution of moving the waffles to a higher level in the project structure worked (and adjusting the relative paths), both in the test case and in the real project. Thank you! One thing I'm concerned about is whether automated prechecks (e.g the one efabless runs in their platform) will actually look at .magicrc or resolve the paths some other way, do you know if that will be a problem?