Hai all, For our design, I am facing an issue in the xor check using Open Lane. Kindly share with me your ideas. Herewith, I have attached the file for your kind reference. Advance thanks.

@Gavaskar K Sounds like a #shuttle-precheck problem. Posting on multiple channels is discouraged but maybe tolerated if the original question is not answered in a reasonable amount of time. Here’s your problem. Layer 236/0 is the OUTLINE layer in the magic tech file.

--- Running XOR for layer 236/0 ---
"input" in: xor.drc:94
    Polygons (raw): 915278 (flat)  213 (hierarchical)
    Elapsed: 0.000s  Memory: 1893.00M
"input" in: xor.drc:94
    Polygons (raw): 11542671 (flat)  985 (hierarchical)
    Elapsed: 0.000s  Memory: 1893.00M
"^" in: xor.drc:94
    Polygons (raw): 432 (flat)  432 (hierarchical)
    Elapsed: 83.750s  Memory: 5855.00M
XOR differences: 432 
"output" in: xor.drc:69
    Polygons (raw): 432 (flat)  432 (hierarchical)
    Elapsed: 0.000s  Memory: 5855.00M

There should be a drc marker output file that you can load into klayout to see where the actual errors occur and maybe get a clue as to why.

For a bit more context (I am working with Gavaskar on this project), I don't think this is the XOR check in precheck but the one that openlane runs (I believe between magic and klayout's GDS output?) Nonetheless the marker file is definitely needed to debug this one too.

Thanks for the clarification @gatecat. That makes a lot more sense. Maybe #openlane would be the appropriate channel. It’s my understanding that the openlane XOR check is comparing gds created from magic to gds created from klayout. Having errors on the OUTLINE layer may be indicative of the layer being offgrid, but that’s just a guess. magic’s sky130 dbu is 5nm, I think.

something being off-grid for magic is a good place to looks, thanks! @Gavaskar K are all your macro placements aligned on a 5nm grid?

Attched the macro_placement.cfg for your kind reference.

I think those should all be okay

No. I am trying to do the same.

What about

signoff/<topcell>/openlane-signoff/*-xor.xml

Specifically, the XOR check is supposed to make sure that the geometry in the user area does not extend out into areas where the Caravel core routes to the wrapper pins. Occasionally there are stupid things that crop up that break the XOR check, but generally, it is supposed to catch instances where the router got too congested around the edge of the design and went out of bounds of the standard cell area, which could potentially short with something in the chip top level after integration.

@Tim Edwards I think you’re referring to the precheck xor, which is what I’d also originally assumed. I think the problem is occurring in

run_klayout_gds_xor

which is called from

$OPENLANE_ROOT/flow.tcl

and defined in

$OPENLANE_ROOT/scripts/tcl_commands/klayout.tcl

. It is not comparing a halo region of

user_project_wrapper

. but is comparing the gds created from def/lef to gds in klayout to the def/lef to gds in magic for any arbitrary cell synthesized in openlane, I think.

@Mitch Bailey: Oh. I have never understood why two GDS files are being generated in the first place. Only one of them can ever be used. I guess if there is an XOR check between them then it's because the openlane team doesn't trust that they understand what either tool is doing and are looking for discrepancies between the two. If that XOR check is failing, then that's something to investigate why klayout and magic produced different layouts, and what should be done about it. The immediate action would be to figure out which one of them is "more" correct and make that one the only GDS file in the project submission.