@User How should I interpret the unknown layer/datatype error I had in my SRAM gds?

You can ignore those messages.

@User: Magic does not implement all GDS layers (on purpose). Files like the SRAM layout .mag contain a reference to the source GDS file, so when magic writes out GDS, it will pull the GDS from the source so that the GDS data is unaltered.

Does this mean that when we copy a GDS, we need to copy all the dependency it refers to?

@User: That depends. Magic purposefully simplifies a lot of layout on input, showing a view without implants, ID markers, contact cuts, etc.; it will regenerate those layers on output. So magic does not necessarily read and write GDS on a 1:1 basis. If there is any cell for which the exact placement of implant layers is a concern, then it should be read with the option "gds readonly true". That makes the cell view in magic a sort of "abstract" view. You see magic's simplified view, but magic has saved a pointer to the GDS file and the byte start and end locations of the data for that cell. So when GDS is written for any design containing that cell, the GDS for that cell will be taken from the original GDS source file, not from magic's view of the cell, and all of the original GDS data will be untouched. The view is not "abstract" like a LEF view, because you can still, say, extract a valid netlist from magic's view of the cell. But if you tried to edit it, then those changes wouldn't appear in the output because they're not part of the original GDS data. All of the library cells that come from 3rd party sources are handled this way to prevent magic from altering the GDS data of the original source, so that includes the standard cells, the I/O pads, and the SRAM. You can tell if a cell in magic is read-only by using the command

property

(prints contents of a key:value dictionary belonging to a cell). Cells which reference a vendor source file will have the property

GDS_FILE

with a value pointing to a GDS file.

@User: Thanks for the detailed explanations!