More importantly, how can I see/edit Dualgate in m...
# gf180mcu
u
More importantly, how can I see/edit Dualgate in magic? I can only see it in Klayout
t
Magic uses many more derived layers than Klayout, which just displays the GDS layers directly. High voltage implants are one of a number of layers that magic auto-generates. You can see auto-generated layers (or any GDS layer) using the
cif see
command and giving the CIF equivalent name of the GDS layer. For dual-gate (which most people, including me, would normally call "thick oxide" or "thickox"), use
cif see DUALGATE
. You cannot edit the layer directly, but the "DUALGATE" layer is inferred from high-voltage transistors. So if you have a device
mvnfet
or
mvpfet
, then DUALGATE will be in the GDS output surrounding those transistors.
๐ŸŒ 1
u
Thanks for the detailed explanation! This is what I'm seeing with magic,
cif see DUALGATE
, when opening a standard cell library inverter:
๐ŸŒ 1
DUALGATE is the white hatched area
However, when opening the same cell in klayout, I'm seeing something else:
all layers -
Dualgate 55/0 specifically:
image.png
How can I explain this discrepancy?
t
Standard cells are done a bit differently, mainly due to the size and complexity of digital synthesized layouts. Magic would normally draw the DUALGATE layer as you see it in the top picture. Then, to make sure there are no violations between cells, it will do a hierarchical check and resolve spacing issues between cells. This takes a long time on large layouts, and the standard cells are designed by the foundry to abut cleanly. So standard cells in magic are given a property
GDS_FILE
that is a pointer to the foundry GDS file, so that when the layout is written, the foundry data is inserted instead of being generated from Magic (and also means that the hierarchical processing can be skipped, so generating GDS is faster). Unfortunately, though, that means that in the case of any cell with the
GDS_FILE
property, Magic is not WYSIWYG. I started coding a method for correcting that problem, but left it unfinished (too many other priorities in the way). Eventually I will get around to finishing it. Meanwhile, just be cognizant that cells in the PDK that come from the foundry all have the
GDS_FILE
property and the view in magic may not correspond exactly to the foundry data.
โœ… 1
๐ŸŒ 1
u
Thanks for explaining!
So just like with the COMP issue, I ended up with a klayout script that reads the magic output and fixes the DUALGATE layer