GDS read-in very slow compared to MAG read-in, results differing from input GDS

[chaufe]

I am trying to speed-up GDS stream out, therefore I'm comparing two merge attempts:

1. merge using addpath, thereby using .mag files

   lef read $::env(CONDA_PREFIX)/share/pdk/gf180mcuC/libs.ref/gf180mcu_fd_sc_mcu7t5v0/techlef/gf180mcu_fd_sc_mcu7t5v0__nom.tlef
   addpath $::env(CONDA_PREFIX)/share/pdk/gf180mcuC/libs.ref/gf180mcu_fd_sc_mcu7t5v0/mag/
   addpath $::env(CONDA_PREFIX)/share/pdk/gf180mcuC/libs.ref/gf180mcu_fd_io/mag/
   def read $::env(IN_DEF)
   gds write $::env(IN_DEF).io_as_mag.gds

2. merge using gds read for the IO cells only

   lef read $::env(CONDA_PREFIX)/share/pdk/gf180mcuC/libs.ref/gf180mcu_fd_sc_mcu7t5v0/techlef/gf180mcu_fd_sc_mcu7t5v0__nom.tlef
   addpath $::env(CONDA_PREFIX)/share/pdk/gf180mcuC/libs.ref/gf180mcu_fd_sc_mcu7t5v0/mag/
   def read $::env(IN_DEF)
   gds read $::env(CONDA_PREFIX)/share/pdk/gf180mcuC/libs.ref/gf180mcu_fd_io/gds/gf180mcu_fd_io.gds
   gds write $::env(IN_DEF).io_as_gds.gds

   When merging the design in colab, I got ~2min run time for merge and stream-out, the GDS-based version took ~108min, which is an increase of more than 50X. I would have assumed the output GDS files to be identical, but they are not.

Let's focus on cell M3_M2_CDNS_4066195314587: In the IP GDS file $PDKPATH/libs.ref/gf180mcu_fd_io/gds/gf180mcu_fd_io.gds, this is a vertical V2 array, containing one column of 13 V2 cuts, each having a size of .260um x .260um, and an edge-to-edge spacing of .280um. In merge attempt 1 (.mag-based), this via array is identical to the IP GDS, same via size and via spacing. This is not of surprise, as the .mag file just points to the GDS content:

magic
tech gf180mcuC
timestamp 1688417580
<< properties >>
string GDS_END 905390
string GDS_FILE $PDKPATH/libs.ref/gf180mcu_fd_io/gds/gf180mcu_fd_io.gds
string GDS_START 904426
<< end >>

Now, when directly using the IP GDS rather than the .mag files for merging (attempt 2), merge is not only way slower, also the output GDS does differ. Via array M3_M2_CDNS_4066195314587 still is 1x13 vertical V2 array, but the edge-to-edge spacing has decreased from .280um to .260um.

Am I just using the wrong options / commands to magic?

Please use this link to directly run the testcase in Google Colab: https://colab.research.google.com/github/chaufe/testcases/blob/main/magic___run_time_comparison__merge__gds_vs_mag.ipynb

I've also attached zip files containing relevant input and output files. gf180mcu_fd_io.zip magic_gds_merge_slow.zip

/cc @proppy /cc @dhaentz1

[RTimothyEdwards]

The GDS read-in of the GF180MCU I/O cells is extremely slow due to some layout which is pathologically bad for magic's database. To work around that issue, use the following in your read-in script:

gds ordering on
gds flatten true
gds polygon subcells true
gds flatglob *_CDNS_*

Many of magic's layers are "derived layers", not GDS layers, so (1) you may see differences in sizes for things like contacts, which are derived layers that represent contact areas, not contact cuts, and so do not have the same dimensions as contact cuts; and (2) it takes some processing work to create the derived layers, so the GDS read-in will always be slower than the .mag file read-in (although the 100+ minutes is, as I said, a pathologically bad case).

[RTimothyEdwards]

@chaufe : Just FYI, the "C" variant of the process (gf180mcuC) is one that GF told us is not good to use. We used it for the first GF tapeout because the "not good to use" part was not documented, so we didn't know that until GF told us at the time of tape-in. Apparently the top metal layer in the "C" variant is not thick enough and can cause the bond pads to peel when used with a wire bonder. As a consequence, we switched to the "D" variant (gf180mcuD), which uses the top metal thickness recommended by GF.

[RTimothyEdwards]

Also, it is important to know that you should never do a GDS read of a vendor layout (i.e., foundry layout from the PDK) followed by a GDS write without first doing gds readonly true. That command reads the GDS input, but it keeps a pointer to the data positions in the source GDS file, so that the view in magic becomes effectively "abstract". When writing out a GDS file containing those cells, the GDS will be pulled from the original source file, not from magic's database. Otherwise, there is a strong likelihood that magic will screw up the layout if the layout was originally created using a layout tool other than magic. All of the .mag files in the PDK were read with gds readonly true and are abstract views that contain pointers to the GDS source files.

[RTimothyEdwards]

Also, for standard cell designs, or at least designs that are only constructed from macros in the PDK, writing the output GDS can be sped up by doing

cif *hier write disable

before you write GDS. The PDK cells are all designed so that they don't interact with each other in ways that might produce DRC errors, so it is a waste of time for magic to do an exhaustive search for DRC interactions between subcells that need to be fixed, since there won't be any. For large standard cell layouts, the DRC interaction search can add a lot of time to the GDS generation.

[chaufe]

@RTimothyEdwards Thanks a lot for your detailed answer on usage of magic and the proposed switch to GF180MCUD. Mainly, adding gds polygon subcells true as you proposed solved both the runtime issue, and gds readonly yes the differences in the generated GDS files. I will close this issue now as all problems have been solved.