https://open-source-silicon.dev
Join Slack
<@U016EM8L91B> As seen in below video sometimes not able to expand cell layout instantiated in anoth...
# magic
v
@Tim Edwards As seen in below video sometimes not able to expand cell layout instantiated in another layout. And what I found is that 
#0
gets added to cell names in the layout .mag file. If i remove this extra term 
#0
manually in .mag file then cell layout can be expanded. Any suggestions why it occurs and how to handle it ?
20240409-0958-05.0112718.mp4
m
@vks The 
#0
might be caused by reading a cell that is already in memory when the location of the cell is different from the location of the cell in memory. The location is generally stored on the first 
use
statement of an instance. Standard cells from the pdk most likely have gds pointers (
gds readonly
) so be careful when mixing with analog circuits.
v
@Mitch Bailey Can you suggest what steps ideally should be followed to avoid this issue ?
m
What are you trying to do?
v
I was opening a GDS of .mag file from same location. I think something happened during this step.
m
@vks You can 
.mag
-> 
.gds
but don’t save/edit anything in magic that you get from 
.gds
-> 
.mag
. Those are not reversible operations. If you have drc errors in the original 
.mag
file, it’s probably best to fix them there. If you’re never going to edit in magic ever again, you should be ok with editing the gds in klayout.
v
@Mitch Bailey Is there anyway to correct 
nsd
psd
related 
FEOL
errors or 
OFFGRID
error in original 
.mag
layout inside magic ? Currently I do these error rectification directly on 
gds
by opening in klayout and overlapping errors on it from XML file generated during precheck.
m
@vks not sure how you’re getting offgrid errors from magic data. I thought magic was immune to those. Are you using angled shapes? For 
nsd
and 
psd
errors that may be due to standard cell placement, you can forcibly add gds layers by using 
property MASKHINT_<layer> "llx lly urx ury" …
where 
<layer>
is a cif layer. Valid cif layers can be seen in magic with 
cif see unknown
which is an error, but lists the valid values. See here for details. To see the resultant layers, use 
cif see <layer>
. This will show the actual pattern that will be output for that gds layer. Use 
feedback clear
to unsee.
v
@Mitch Bailey Sorry but I could not get these steps. Can you please simplify these steps to follow in magic. Otherwise correcting precheck errors in Klayout directly on GDS is fine but there is scope of introducing error while directly tinkering with GDS and also it is bit time consuming process.
m
First, make sure you understand the difference between paint (magic database) layers and cif (calculated gds) layers. cif display layers show what will actually be output in gds, but are normally not displayed in magic. To see cif layers, use the 
cif see <layer>
Copy code
% cif see *
CIF name "*" doesn't exist in style "gdsii".
The valid CIF layer names are: CELLBOUND, BOUND, DNWELL, PWRES, SUBCUT, ndrainarea, pdrainarea, extnwell, extpwell, NWELL, WELLTXT, WELLPIN, SUBTXT, SUBPIN, ldbreak, DIFF, DIFFTXT, DIFFPIN, TAP, TAPTXT, FOMFILL, basePSDM, baseNSDM, extendPSDM, PSDM, extendNSDM, NSDM, EDID, LVID, LVTN, HVTR, HVTP, SONOS, COREID, STDCELL, ESDID, NPNID, pnparea, PNPID, PHOTO, RPM, URPM, LDNTM, hvntm_block, HVNTM, POLY, POLYTXT, POLYPIN, POLYFILL, thkox_area, large_ptap_mv, small_ptap_mv, HVI, CONT, xpc_horiz, CONT, CONT, diffcutarea, NPC, NPC, DIFFRES, POLYRES, POLYSHORT, POLYRES, DIODE, LI, LITXT, LIPIN, LIRES, LIFILL, MCON, MET1, MET1TXT, MET1PIN, MET1RES, MET1FILL, VIA1, MET2, MET2TXT, MET2PIN, MET2RES, MET2FILL, VIA2, MET3, MET3TXT, MET3PIN, MET3RES, MET3FILL, VIA3, MET4, MET4TXT, MET4PIN, MET4RES, MET4FILL, VIA4, MET5, MET5TXT, MET5PIN, MET5RES, MET5FILL, RDL, RDLTXT, RDLPIN, PI1, UBM, PI2, GLASS, CAPM, CAPM2, LOWTAPDENSITY, FILLOBSFOM, FILLOBSM1, FILLOBSM2, FILLOBSM3, FILLOBSM4, FILLOBSM5.
for example, 
cif see NSDM
will show the actual implant data that will be output to gds. If you are getting errors in klayout between implant layers, you can use 
cif see NSDM
to see the actual pattern in magic. To add layers to gds output that are not generated, you’ll need to use properties. 
property MASKHIINT_NSDM 10um 10um 12um 12um
 
property MASKHINT_NSDM "20000 20000 24000 24000"
would add a region of 
nsdm
at (10,10)-(12,12). In magic, you can set the box to the region you want to add, and use the 
box values
command to get the coordinates.
t
@Mitch Bailey: You cannot specify a maskhint property like that (even if you correct the spelling). The property has to have coordinates in magic's internal units. They must be four integer numbers, no ASCII text. The property value is a string, so because there are spaces between the values, it must be in quotes.
👍 2
v
@Mitch Bailey Understood it now. Couple of queries: 1. 
cif see NSDM
command to be run on 
.mag
or 
.gds
database of particular layout to rectify implant layer errors ? 2. How can I get to know the location of implant errors (NSDM , PSDM) in magic layout since they are available in feol.xml file generated from klayout during precheck ?
m
You can run into problems editing gds -> mag data, so I recommend you do not do that. Edit the original mag data. I don’t know how to show xml data in magic. I suggest you view the errors in klayout, and fix them in magic.
15 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by