Hi all, I'm constantly having problems when doing netlist extraction with magic on gds files created with klayout. The

.zip

file contains the temperature sensor developed on Chipalooza, and it compares the extraction of the gds and a flattened version generated with a python script. To flatten the gds, I'm using a klayout python script that removes the labels on the child cells (labels and pins), and then both gds are compared with netgen. Most of the results are written on

extract.sh

. Please read that file. After the analysis I have some questions: About the problem - Is the separation of the vias on different cells (

vias_gen*

,

via_dev*

) the cause of the problems? - A lot of duplicated stdcells are generated. Is this a problem? How can I avoid this? About tool usage and capabilities - How to properly extract layouts made with klayout? It's seems to be required to flatten the design before loading it on magic. - PEX netlists only match after removing parasitics. Is possible that magic gives different parasitics for the same design? - There's a way to "merge" an instance of a cell with it's parent when when reading a gds on magic? Avoiding the flattening of the parent - Removing the labels from child cells before flatten the

TOP

cell could cause an error? About debugging - How can we debug extraction inconsistencies on magic? I'm aware of the

feedback

command. That's the only alternative? - Can we get

feedback

extraction information per cell? - Is there a way to store in a gds an

error layer

with a message? I want to turn feedback report into a gds. @Tim Edwards @Mitch Bailey @Amro Tork

If layers required for the generated layers that magic likes to use are separated across cell hierarchies, then magic will not be able to create its generated layers. This most often happens with vias, but can happen with FETs and other devices as well. Usually it's best not to resort to flattening everything. If you know that vias are always in subcells with a specific name, as you indicated, then what you need to do is run the command

gds flatglob vias_gen*

and

gds flatglob via_dev*

before reading GDS to make sure that those cells get flattened on input. That will probably take care of most of the issues.

@aquiles viza that’s a lot of questions. My first gut feeling is to not flatten anything in klayout. You can use

gds flatten yes

to flatten cells with few (default is 10) layers (like via cells). You can also use

gds flatglob <pattern>

multiple times to flatten any cells (like pcells) to make the extracted layout more readable. You’ll want to flatten any cells that have cross hierarchy devices, eg, the poly and diffusion overlapping, but in different cells. Not sure why your getting duplicated standard cells. Maybe reading multiple gds files multiple times? You might try

gds noduplicates yes

. This will just keep the first one. When you flatten the cell for parasitic extraction, try using

flatten -dotoplabels <new-flat-cell>

. This should ignore the labels from subcells. After extracting, you can use

feedback save <filename>

to save the feedback to a file. Let me know if there are any unresolved problems.

On the

extract.sh

script, the

magic-extraction

command already uses

gds flatglob vias_gen\[$\0-9\]*

. I've retried using

vias_gen*

but the number of errors is the same (see

extract.sh

).

SDC_DIGITAL_clean: 3100 errors
Total of 3100 errors (check feedback entries).
Total of 21 warnings.

I'm not sure about that's the effect of

flatglob

, I think that it just flattens the matched cells, nothing like "replace on parents the instance of matched cells with the content of it". Flattening the parent because of the

vias_gen

is the same as flattening the hole circuit in most of the cases

@aquiles viza These are the warnings generated when a 4 terminal transistor has the source and drain tied together, i.e., to magic, it’s missing a terminal and connects the remaining source to the specified node which was the drain connection.

flatglob

flattens the specified cells when reading gds. The flattened data is copied to each instance in the parent cells. The attached gds includes duplicate cells. Can you remove the duplicate cells from the original klayout data? Opening the gds data in klayout shows cells “named”

<defunct>skywater130.vias_gen

. You might be able to flatten all

vias_gen

cells with

gds globflat *vias_gen*

I didn't notice that the cells were duplicated on the gds, Most of the duplication subckt problems were solved with that. Still, the digital flow added extra layers to some of the cells, and it makes inv2 - inv2$2 and tapvpwrvgnd_1 - tapvpwrvgnd_1$3 different in terms of layers used. • manually instanciated has: prBoundary.boundary (235/4) • digital generated has: hvtp.drawing (78/44) areaid.standardc (81/4) unnamed layer with cell name (83/44) unnamed box (236/0) After extracting the gds with some of the duplicated stdcells filtered out: • run logs are the same (still 3100 errors and 21 warnings) • subckt only has

inv_2$2

as duplicated cell I think one solution could be to remove all digital flow added layers with a script, but I'm not sure if that could generate problems later. Will removing the layers added with openlane change some property of the digital block? @Tim Edwards @Mitch Bailey Thanks a lot for your help.

@aquiles viza The digital flow uses magic, but I don’t think it should be modifying the gds input. You may need to be careful if you’re using magic to manually integrate klayout gds with magic data. You probably want the gds read as readonly. There may be some discrepancies at the macro border if the data interacts with magic data. Adding

hvtp

to a cell will change the extracted device type. So if you have cells that use

hvtp

and those that don’t, they will need to be named differently.

83/44

is

LVSTEXT

and can probably be ignored.

236/0

is

OUTLINE

and can probably also be ignored. The

81/4

indicates a standard cell region and may change the drc rules applied. Magic can give a lot of false warnings during extraction. You can probably ignore the

device missing 1 terminal

messages. These are generated when a mosfet has source and drain shorted. How many other errors are there?