<@U016EM8L91B> what's the best way to place a GDS ...
# magic
h
@User what's the best way to place a GDS into a .mag layout? when I use "read GDS" I end up with DRC errors where the contacts aren't converted properly
t
If you have something that is a GDS file created by a 3rd party but it doesn't read into magic cleanly like that, then it's best to create an abstract view of it to substitute. This is what we do with the SRAM macros. You would want to first read the GDS ("gds read") and then write a LEF file ("lef write"). Then exit and restart magic, read the LEF file ("lef read"), followed by reading the GDS file ("gds read"). The LEF file read will generate a .mag view of the abstract view, and the "gds read" will then annotate that view with a pointer to the GDS file and the position of the cell within that file. After that, you can use the .mag view in the layout, but because it has the pointers to the GDS file, if you write GDS of a file containing that abstract view, the cell will be replaced by the contents of the cell's GDS file that it got annotated with.
There is also a "save" command needed there to actually write the .mag file, or when you exit magic it will prompt you to save the file.
h
Awesome I'll have a go at that, thank you
I tried the above, but when I do the second gds read it appears to just do the same thing as reading it in the first place rather than annotating the .mag file with a pointer to the gds (when I try and save the mag file, it asks to save the entire subtree of other cells which is definitely not what I want)
t
@User: Oh, whoops, I forgot to mention a critical command, which is that you need to run "gds noduplicates true" before the second "gds read" or else yes, it will just overwrite the existing abstract view. Sorry about that.
h
Ahh right thank you
hmm -it looks like it's still having the abstract view but it still wants me to save .mag files for all the subcells
also, the abstract view is showing contacts which are too close (because Magic doesn't show "real" contacts)