DRC guide for XFAB EFXH018D_HD


#1

Hi
Is there any guidelines or small tutorial on how to inspect and correct DRCs with Qflow?
We’ve already installed and run the whole Qflow on our server with the provided tutorial at OpenCircuit and some simple Verilog modules, using the OSU TSMC018 cells.
We now would like to start porting our RISC-V micro design to efabless. But when running the same map9v3 tutorial on the EFXH018D_HD process, we are getting 267 DRC messages that we think are related to something the tool reports as timestamp mismatches from the std cells.
Maybe I’m just being a bit lazy, but would really appreciate if someone can point me to some manual, readme or guide on how to handle DRCs and fixing them (manually via Magic or via Qflow)?
We’re using this process as we’ve done some designs with XFAB in he past, and already have a version of our RISC-V ported through the Synopsys flow, sent to fab last April, which we’d like now to replicate with open tools.

Regards


#2

The “HD” standard cell set is particularly difficult for qrouter to route without DRC errors. I have not yet had the time to look into what are the reasons for the DRC errors. The “timestamp mismatch” is unrelated—it it not an error, just a notification that cells read from LEF have no timestamp. The DRC errors are presumably all real errors.

There are no specific guidelines to solving DRC errors, but the tutorials on magic layout give instructions on how to read DRC errors in magic and how to do basic layout manipulations to remove them. Most of the process will be selection and stretching. Key “a” is for “select all” (actually “select visible”), and the keypad arrow keys move (or with the Shift key) stretch the selection. Use the right mouse button on the layer icons on the right to show or hide layers.


#3

Thanks, Tim
We’ll go deeper then into Magic and let you know. Just in case it helps, Synopsys ICC also had trouble with DRCs with this std cells, particularly when placing fillers that usually conflicted with the straps’ and power rings’ connecting vias (errors were not reported by ICC, but were found later when doing the sign-off DRC on the GDS). We ended up forbidding the placement of fillers under the power straps and rings, and problem solved. We also had problems with the thinner fillers (1um I think) which would always cause distance and minimum implant width violations (we also prevented ICC from using this filler). We reported the issue to XFAB and they’ve just announced a newer LL_HD cells version that’s supposed to have this fixed. We’ll let you know about whatever we find.

Regards


#4

Hi
I checked that most of the 267 DRCs are related to metal spacing, area rules. Seems that the router is overextending some metal (M1 and/or M2) around vias when connecting inputs/outputs in the std_cells (probably for reliability issues), that violates minimum spacing (S1M1 for instance is the most common), minimum overlap ( E2M1V1-E1M1V1) and minimum area (A1M2). I checked the rules and this extra covering is not mandatory (though recommended if possible). I still have not figure out how to deactivate this action in qrouter. Fixing this by hand is possible (I corrected just a few to check) but unfeasible (if we’re getting 267 errors for the small map9v3, I imagine that for the core the number would be way higher).

Regards


#5

No problem at all with the EFXX018D stdcells, so we’ll keep using this lib for now. Also, I stand corrected, what XFAB just upgraded was the compact pad io cells.

Regards


#6

There should be no reason to disable the extra overlap in qrouter. If it is not needed, then qrouter should not be generating it. In other words, I consider it a bug in qrouter, not an option.

I have an example of routing done with the HD rules by a commercial tool; I’m going to use that to figure out what it is that qrouter is not doing right. Previously I had just concentrated on the non-HD rules and standard cell set. I can confirm that I was also getting on the order of 200 to 300 errors on small designs like map9v3. I put a limit of acceptability at about 200 errors for a microprocessor-sized design.