Hi everyone, the RING PAD

RING_PAD.gds

given to us does not pass all DRC rules (V3.2b and V4.2b). The corner cells

gf180mcu_fd_io__cor

have some problems (see images attached). I'm creating the PAD RING for our LTC3 (BRACOLIN) chip, editing the Michigan frame. Also, the cell

gf180mcu_fd_io__bi_t

does not pass all DRC rules (NW.2b_MV), my team are not using it. But probably our friends from Colombia will use it on their pads.

Thanks for reporting, i Will add this to the issue list tomorrow CC @mehdi

@Gabriel Maranhão: Since on these pads you can only have one voltage domain, I would assume that the two nwells in your DRC example are at the same potential, so that the "different potential" rule does not apply. I do not know how klayout understands the connectivity for determining same/different potential, though, and it is likely that it requires a setup specifying what external nets are at what potential. This is a general requirement for any DRC engine trying to apply rules involving net connectivity and same/different potentials.

@Tim Edwards: Thank you for the information, they are indeed on the same potential, so that's probably a problem with how Klayout interprets the well that is on the same potential. So the only problem is with the 3 and 4 Via. Since you responded here I have a question about the PEX extraction (with Magic) for gf180 layouts made using Klayout. All my .gds files were created using the Klayout and I can not open it on Magic, because of that I can not proceed on PEX. For SkyWater .gds files the extraction on magic goes ok, the problem is with GF180 .gds files created using Klayout. I'm running the following script

run_ex.sh

on a simple inverter layout

inverter.gds

(clean DRC and LVS)

Hello @mehdi, I was trying to add a new field in [https://github.com/orgs/idea-fasoc/projects/1] for tracking this issue, but I can't do I need a special access? If that's the case, my github username is JorgeMarinN

@Gabriel Maranhão: The problem here is that GDS has the form of a library, with no top level cell implied; you can put as many different top level cells into a GDS library as you want. Magic relies on a method where if the GDS library name is the same as one of the cells, then that cell is assumed to be the top level cell. Klayout doesn't use that method, so after reading GDS written by klayout into magic, you will have to tell it what cell to load. Attached is a modified/corrected/extended version of your "run_ex.sh" script. This adds several features to the script: (1) Corrects the shebang line ("#!", not "!#"). (2) Looks for the magicrc file according to the usual PDK_ROOT and PDK. (3) Sets default values for PDK_ROOT and PDK if not set in the environment. (4) Checks the number of arguments passed to the script. (5) Loads the cell after reading the GDS (assumes that the top level cell name is the same as the GDS file root name). (6) Uses the recently-implemented "extract path" command option to keep all the .ext files in a subdirectory.

Hello, @Gabriel Maranhão @Tim Edwards, here is what I have found in the Klayout tech file and inside DRC rules for gf180mcuC:

7 </src>                                                                                                                       
  218  </d25>                                                                                                                      
  219  <connectivity>                                                                                                              
  220   <connection>30/0,33/0,Metal1</connection>                                                                                  
  221   <connection>Metal1,35/0,Metal2</connection>                                                                                
  222   <connection>Metal2,38/0,Metal3</connection>                                                                                
  223   <connection>Metal3,40/0,Metal4</connection>                                                                                
  224   <connection>Metal4,41/0,Metal5</connection>                                                                                
  225   <connection>Metal5,82/0,53/0</connection>                                                                                  
  226                                                                                                                              
  227   <symbols>Metal1='34/0+34/10'</symbols>                                                                                     
  228   <symbols>Metal2='36/0+36/10'</symbols>                                                                                     
  229   <symbols>Metal3='42/0+42/10'</symbols>                                                                                     
  230   <symbols>Metal4='46/0+46/10'</symbols>                                                                                     
  231   <symbols>Metal5='81/0+81/10'</symbols>                                                                                     
  232  </connectivity>

The DRC associated with different potential is related to nwell.drc I hope this information will help to solve the issue.

@Tim Edwards: Thank you very much, with the script and using the same file name as the top cell the extraction worked. Thank you again!

@Gabriel Maranhão You have to enable

--connectivity

switch to be able to check rules with that condition. It is disabled by default as klayout consumes a lot of resources for checking these rules.

@Gabriel Maranhão: The rule violations in the corner cell are false, as suggested by Farag; the wells are at the same potential, so the different-potential rule does not apply. The errors in

gf180mcu_fd_io__bi_t

are known to us; we have reviewed them and decided that they are both obscure and probably not an issue (might affect yield slightly at production volumes, which is not an issue here). GF waived the errors when we did the open MPWs 1 and 2, and the pads worked fine in silicon validation tests.

@Tim Edwards if i want to use this .gds file how can i convert it to magic file so that i can do connection to other modules.

@Atif Khan: Which GDS file?

@Tim Edwards here ring_pads.gds , and overall i am asking as a general can we convert gds to mag file

Sure, you just start magic, read in the GDS (

gds read ring_pads.gds

) and write out magic files (

writeall

). There are varying degrees of complexity to this. I recommend keeping the GDS file in a known place and running

gds readonly true

before

gds read ...

. That will create a layout view in magic which points to the original GDS data, so that you know that magic doesn't change the GDS contents when it writes out the file. That's my usual approach with known-good layout from a vendor such as the foundry (don't mess with silicon-proven layout). But in this case you're probably fine letting magic just read the GDS and write back out its own version of the GDS.