Hi all, I'm constantly having problems when doing ...
# analog-design
a
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
t
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.
m
@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.
a
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
).
Copy code
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
The use of
gds noduplictes yes
doesn't avoid generation of duplicated stdcells. Maybe because those cells where instanciated and routed manually. Should we add intermediate routing/spacing cells between stdcells? In this case, inv1 and inv2.
And still, reading the pre-flattened gds generates 240 extraction errors, lots of
Copy code
- feedback add "device missing 1 terminal; connecting remainder to node vdd" pale
- feedback add "device missing 1 terminal; connecting remainder to node vss" pale
What does that mean?
m
@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*
a
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.
I think that cell duplication on the analog design happen because we import the bottom level gds into top level ones using
Import > Other files into current > Extra cells
, and maybe pcell information is not found/ignored and the cell is converted into shapes. I'm not sure if this is the case, or how to avoid this to happen. This explains also why there are too many vias cells, when they should be pcells. I don't know how magic resolves gds with pcell information. Should I store the gds without context info before passing it to magic? @Amro Tork I think your team has struggled more with this kind of problems, do you have some kind of documentation on how to interoperate klayout with magic?
m
@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?
If you’re importing a digitally created gds layout into klayout where the klayout already has a manual layout created with digital cells, you need to be careful when importing the gds. I’m thinking that the
Merge hierarchy
option might work.