When executing "writeall force" on a layout with unexpanded subcells (This sometimes happens with more complicated gds writes as well), Magic forces a just in time read of those cells. However, this pipeline passes ignoreTech = True, causing the cells to be read into memory while bypassing PDK rules, especially scaling. In PDKs like sky130A that rely on a grid scale of 2, this results in integer truncation/rounding errors that permanently corrupt the subcell geometry upon writing.
A common issue is that in sky130, which uses a scale of 2, a standard transistor has a channel width of 150nm, so at 10nm, the width is 15 units, and at a scale of 2, the width is 30 units. Assuming the channel goes from -15 to 15, loading then saving without scaling leads to the new width being rounded to -7 to 7, or 140nm (at no scaling), causing drc issues. It is quite complicated to explain, but I hope I got the point across.
Steps to reproduce:
- Load a transistor PCELL into a new magic layout
- Save and close
- Open again, do not expand subcells
- Run "writeall force"
- Close and reopen, expand, run DRC
Result:
DRC shows errors in the subcell.
The root cause is the following call stack:
DBCellWrite->DBCellWriteFile->DBCellFindScale->DBCellEnum->DBCellRead (ignoreTech = True)
I have not attempted to do a fix myself since this is a deep architectural bug and I am not sure how to tackle it.
Environment:
Magic 8.3.638, MX Linux, Sky130A
When executing "writeall force" on a layout with unexpanded subcells (This sometimes happens with more complicated gds writes as well), Magic forces a just in time read of those cells. However, this pipeline passes ignoreTech = True, causing the cells to be read into memory while bypassing PDK rules, especially scaling. In PDKs like sky130A that rely on a grid scale of 2, this results in integer truncation/rounding errors that permanently corrupt the subcell geometry upon writing.
A common issue is that in sky130, which uses a scale of 2, a standard transistor has a channel width of 150nm, so at 10nm, the width is 15 units, and at a scale of 2, the width is 30 units. Assuming the channel goes from -15 to 15, loading then saving without scaling leads to the new width being rounded to -7 to 7, or 140nm (at no scaling), causing drc issues. It is quite complicated to explain, but I hope I got the point across.
Steps to reproduce:
Result:
DRC shows errors in the subcell.
The root cause is the following call stack:
DBCellWrite->DBCellWriteFile->DBCellFindScale->DBCellEnum->DBCellRead (ignoreTech = True)
I have not attempted to do a fix myself since this is a deep architectural bug and I am not sure how to tackle it.
Environment:
Magic 8.3.638, MX Linux, Sky130A