@Tim Edwards A couple questions about cifout(gdsout) in magic. 1. My understanding is that if a `mag`/`maglev` file has a

GDS_FILE

property, then on gdsout, the referenced gds file will be incorporated into the output gds. Any other shapes or instances in the mag file will be ignored. Is that correct? 2. From the magic log, how can we tell which cells are output from gds and which are output from

mag

files? Looking at the log

Generating output for cell housekeeping
   Generating output for cell user_project_wrapper
Reading "gf180mcu_fd_sc_mcu7t5v0__filltie".
Reading "gf180mcu_fd_sc_mcu7t5v0__endcap".
Reading "gf180mcu_fd_sc_mcu7t5v0__fillcap_8".
...
Reading "user_proj_example".
Reading "user_project_wrapper".
   Generating output for cell simple_por

I’m thinking that a

Generating

line followed by a

Reading

line indicates that GDS is being input/output. Is that correct? 3. What happens if the subcells in the input gds are different than the subcells with the same name already output to GDS? 4. Are there any messages output for errors related to missing GDS files? It looks like the top sram’s for gf180 have

GDS_FILE

properties, but the

mag

representation of the subcells is output instead (There are no

Reading

messages after the

Generating

message for sram in the log). Could this be related to the order (alphabetical) of the properties in the mag files?

string GDS_END 2348274
string GDS_FILE $PDKPATH/libs.ref/gf180mcu_fd_ip_sram/gds/gf180mcu_fd_ip_sram__sram128x8m8wm1.gds
string GDS_START 2298700

(1) Yes, that's correct. The presence of

GDS_FILE

makes the view in magic effectively "abstract", although if the cell is not specifically marked as abstract with the

LEFview

property, then the view in magic will be used for DRC and extraction. (2) Yes, the "Reading" statement during GDS write means that it is pulling a cell directly from GDS. (3) This is not supposed to happen because the

GDS_FILE

is set when the magic view is read from the GDS file as a "read-only" cell. But of course the read-only status could be overridden and the file could be manipulated in any way and yes, that could result in a view that is completely different from the one in the target GDS file. I don't like this method particularly, but it's the only way to ensure that vendor-supplied layout data can be read into magic and written back out again without any changes, since magic's database format is so different from other tools'. The other choice would be to read in the vendor GDS and keep it, encoded, in the cell database, verbatim, but I don't like that solution any better. There is one other choice which I actually have in the code but have not used, which is to run an XOR between magic's result and the original GDS data and retain the differences (much like the previous option I mentioned, but with only a small amount of data needing to be retained). I have been thinking recently about a "band-aid" solution of marking the cell visibly in some way to indicate that it is tied to a GDS file and should be treated as abstract. (4) There is no order to the properties; they are in a hash table and read by key reference. Yes, there is an error message generated if a GDS file is referenced and cannot be found, and another error message generated if the GDS file is found but there is no cell at the indicated position.

@Tim Edwards Thanks for the detailed explanation. The scenario I’m thinking about with (3) is when a user integrates an older version of

user_project_wrapper

into a newer version of

caravel_core

. Both use cells from the same

sky130_fd_sc_hd

library, but there’s no guarantee that the data from the old PDK is the same as the current pdk. One solution might be to prefix all the cells from a specific gds file with a unique id and replace the references in the parent cell. Any idea why the gds file for the the gf180 sram is not being read even though there’s a

GDS_FILE

property?

@Mitch Bailey: For the scenario you mention: The standard cells in

.mag

form with the

GDS_FILE

should always be in the same PDK as the GDS file. . . One should be in

libs.ref/<library>/mag/

and the other should be in

libs.ref/<library>/gds/

. The

GDS_FILE

property should never be used outside of a single PDK, otherwise everything would be chaos because there's no version tracking going on. And no, I don't have any idea why the GF SRAM would not be reading verbatim from the GDS.

@Tim Edwards as always, thanks for the detailed explanations. > One should be in

libs.ref/<library>/mag/

and the other should be in

libs.ref/<library>/gds/

. The

GDS_FILE

property should never be used outside of a single PDK, otherwise everything would be chaos because there’s no version tracking going on. Requiring that the PDK of the GDS_FILE matches the current PDK sounds like a solution. Is there any way to implement that? Maybe add a

GDS_PDK_COMMIT

property?

(1) Well, magic starts up and sets PDKPATH as an internal Tcl variable based on the technology file that was specified on the command line or in the .magicrc file, and from the .magicrc file, that PDKPATH will be used to find all the .mag files in the PDK, and those .mag files will have a GDS_FILE with a PDKPATH entry that then will be set to match the Tcl variable. . . So I feel like you would have to work pretty hard to force them to get mismatched. (2) Yes, I mean that I wrote out the GDS and it output

Reading

statements indicating that it was pulling cells from the referenced GDS file.

(1) For a recently created GDS file, there should be no problem. I was imagining the case where someone was using a gds file created years ago with a different pdk that might not include recent patches. (2) Hmm. Maybe it works with direct references, but not relative? The instantiation of the sram is in the mgmt_core_wrapper repo. I’ll see if I can pin down a cause.

@Mitch Bailey: I will investigate. That is not the way it is supposed to work. Clearly abstract views (

LEFview

) are not supposed to be written out to GDS from the abstract view. However, any view with a

GDS_FILE

property should pull data from the file, not the magic database.