@Tim Edwards: I'm using Klayout as the main layout editor for gf180, but I always double-check the DRC on magic. Everything was fine until I started using MIM CAP. After some problems, I noticed that there was an update on xschem capacitor models so I got the updates and changed all(only four) of the already placed capacitors for the new ones. I'm using the

cap_mim_2f0_m5m6_noshield

(or m4m5). I always check the models that the layout tools are using to mitigate LVS problems in the future. I noted some differences between the devices generated using Magic and Klayout and I have some questions on how to proceed. (1): Magic generates the cap_mim with M4-M5, whereas klayout gives us the option to choose between MIM-A (only M2-M3) or MIM-B (M3-M4/M4-M5/M5-M6). To the best of my knowledge, this choice depends on the structure that the foundry will use (1PM5... 1PM6), I know that gf180mcuD is 11K and I suppose that we should use MIM-B. My question is, should I move to m4m5 or there is a way to include the m5m6 option on magic, magic do not have the m6 or mTop layer? The inclusion of m5m6 is not mandatory and does not impact my project, so perhaps switching to m4m5 is a viable option...(see figures

mimCap_draw_magic.png

mimCap_draw_klayout.png mim_cap_layers.png

mim_cap_layers_magic.png

) (2) The cap_mim generation on Magic shows us the capacitance value (see figure

100x100_20p_magic.png

), I believe this is the expected value or some form of approximation. The thing is, these values are ~10-15 times higher than simulation results, see figure

100x100_20p.png

. A 100u X 100u on ngspice gives us a 20pF capacitor while magic informs that it gives a 258pF capacitor. Currently, I am relying on the simulation results. (3) KLayout generates cap_mim with one additional layer that Magic lacks, namely

MIM_L_MK 117/0

. Do you know if this layer holds any significance? (3.1) Also magic generates the cap_mim with a sidebar, on the right, with M4 and M5, what are their purpose? Klayout only generates the square/rectangle.

Yes, there are a number of errors in magic's DRC for gf180mcu. I have somebody actively working on checking them, and I'll get out an update, hopefully early next week.

@Tim Edwards: Do you know if gf180mcuD uses 1PM5 or 1PM6 (metal structure) ? I think it is 1PM5, but I'm not sure.

Yes, 1PM5.

Variant D on klayout drc file (

gf180mcu_drc.lydrc

) is wrong. Also the lvs one. cc @Amro Tork

The metal thickness is wrong, too; it should be 11K for variant D (the only difference between C and D should be the metal thickness; that's because I had originally defined A, B, and C as useful variants corresponding to the sets of I/O IP we have, which exist only in 3-, 4-, and 5 metal layer versions. But GF had previously identified the 9K top metal thickness as causing problems with pad delamination and increased it to 11K; however, none of the documentation indicated this, so I was blindly led into defining what was effectively a discontinued variant. So I created variant D, increasing the top metal thickness to 11K to comply with GF's recommendation. There is no defined variant "E" defined in open_pdks, although there is no harm in defining one.

Thanks @Gabriel Maranhão But it seems that you are using an older version.

@Amro Tork: It's in the current

gf180mcu_fd_pr

repository under

rules/klayout/macros/gf180mcu_drc.lydrc

. Currently, the installed DRC rules for klayout are taken from the

gf180mcu_fd_pv

repository. I think this is a matter of having moved the physical verification files to a new repository and not removing the outdated ones from the old repository.

@Gabriel Maranhão From which file did you get the screenshot above?

We need to identify which files in the repository are no longer being used and issue a pull request to remove them.

@Tim Edwards You always take the main from here: https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pv/tree/main

I already use this version, but where is the rules/macros directory, they are needed to run the DRC inside klayout. This repo does not contain the .lydrc and .lylvs files. They are located only on the _pr repo. I'm runing DRC and LVS directly on klayout, not on terminal. But I'm using the /drc and /lvs from efabless pv repo, runing the run_drc file

@Gabriel Maranhão I got it

You're welcome. Both the DRC and LVS files have this typo. I changed it locally and now I have clean DRC using mim_cap m4m5, the right one for 5LM. The only thing now is that the netlist extraction using klayout inserts on the .cir file the capacitor differently than xschem/ngspice, and that cause LVS errors, a palliative fix is to edit the .spice file generated by xschem.