Noticing some strange behaviour from Openlane regarding Klayout FEOL layers. We hardened a digital-only macro (

TOP_digital

), then instantiated this into a mixed signal design which gets incorporated into the user_project_wrapper. The strange behaviours are these: 1. Openlane appears to have generated FEOL DRCs during the hardening process of

TOP_digital

. All of the FEOL DRCs are associated with this macro which Openlane previously made. 2. Whats more bizzare, is that the precheck for user_project_wrapper, sometimes it flags up these DRCs, and sometimes it doesn't. Because

TOP_digital

doesn't get re-hardened or regenerated during the user_project_wrapper build, I don't understand where this inconsistency is coming from.

@Ellen Wood you may be aware and this may not be related to the problem, if you reharded a macro, you must reintegrate (run openlane) with all the parent hierarchies in order. There have been issues where users have added unnecessary

GRT_OBS

in their

config.json

files. Do you have

GRT_OBS

in your

config.json

?

@Mitch Bailey I'm a bit confused as to whether our digital macro gets re-hardened or not. Be interested to know your thoughts on this! We are sort of experimenting with a mixed signal approach. First, we harden a digital only macro in Openlane, using this config.json:

Maybe you want to set the

GDS_FILE

property of

TOP_digital

. You can do this by editing the

TOP_digital.mag

file. I think when you originally create the file in openlane, it has the

GDS_FILE

property, but when you edit it, the property disappears. @Tim Edwards Is my understanding correct? So the first time, after you place

TOP_digital

in

TOP_mixed

and then write the gds, the

TOP_digital

gds created from openlane is used. However, if you edit

TOP_digital

in magic and then write the data as gds, the openlane gds data is ignored and the magic data is converted to gds. This might cause some differences. Do you need to make changes to

TOP_digital

?

Thanks for your insight! I've spent a little time this evening looking into what might be happening. Openlane might not be the problem. It appears that whenever we make a change to the

TOP_mixed.mag

and write out the GDS, FEOL errors are generated in

TOP_digital

and they change slightly each time. We've made no changes to

TOP_digital

lately (and nor do we need to going forward) - but other small changes elsewhere in the design, then re-harden

user_project_wrapper

. Perhaps some sort of rounding error is happening in the

gds write

process in Magic, to explain the slight differences in errors each time?

I’ll let @Tim Edwards comment on the magic details. Another user posted this https://open-source-silicon.slack.com/archives/C02096M650E/p1699254340663029

@Ellen Wood: Here's what I think is going on: If you get FEOL DRC errors that move around every time you re-harden a digital block, then the problem is in the way the digital block is being written out. Especially given that you're seeing errors in basic

nsdm

and

psdm

width and spacing. There are two settings involved; one is the

GDS_FILE

in the standard cells. You want the standard cells to be written exactly as-is. I expect it's the other problem, though, which is that openlane writes out GDS of digital blocks using

cif *hier write disable

. What that does is it prevents magic from checking whether neighboring or overlapping cells are causing DRC violations from interacting layers. Then it goes and adds extra layers to fix up those errors. The standard cells are designed specifically so that they can fill a tiled area of standard cell sites without causing any interactions and without needing any repairs. So the hierarchical checks and repair are just wasted time for standard cells (and it can be a lot of time for a large digital block). But if you have a mixed-signal design with analog blocks being written from .mag files and you use

cif *hier write disable

then you are very likely going to end up with FEOL errors. I think the best thing to do is to make sure that all large blocks being assembled on the top level (1) have complete and DRC clean generated layout, are abstracted, and have a GDS_FILE pointer pointing to the known-good GDS, and (2) blocks are assembled in the top level with enough space in between so that they will not have any interactions that would cause DRC errors (a few microns distance is probably sufficient unless they have deep nwell structures close to the edges, in which case probably about 10 micron spacing is sufficient).

Thank you both! I will try these suggestions out.

Magic only reads

.mag

files. However, you can do this:

gds readonly true
gds read <filename>
writeall

The "readonly" option means that you will get a

.mag

version of what's in the GDS but when magic writes out GDS it will include the cell directly from the original GDS file it came from, which I think is what you are looking for.

@Tim Edwards can I get a slight clarification on this. The

TOP_mixed.mag

file already contains

TOP_digital

and

TOP_analog

. Will this overwrite the

TOP_digital

cell in memory?

gds readonly true
gds read TOP_digital.gds

@Mitch Bailey: You would do the

gds readonly true; gds read TOP_digital.gds; writeall force TOP_digital

separately from everything else, and with a fresh run of magic; that's a standalone operation that is meant to generate a

TOP_digital.mag

file that has a GDS pointer to

TOP_digital.gds

. You would not do that while something is already loaded in memory.

Ok! Awesome - thanks for that clarification too. Hopefully that will get my

TOP_digital.mag

pointing to a clean GDS for TOP_digital. Will try tomorrow.