Hi @User, I tested the latest updates to open_pdks and magic (with the fix for the inverted fringe capacitance calculation). It reduced the fmax of my design quite a lot vs a PDK from a month ago, but I guess that is to be expected since the reported capacitance along those paths are also much higher. What is a bit surprising is that the resizer didn't make an effort to fix it up. Makes me wonder if the RC estimates we use are reasonable. Do you know where these came from and if they look ok? https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/openlane/config.tcl#L143

@Anton Blanchard: That opens up a lot of questions. My first one would be: Why are there technology-specific values in the OpenROAD sources? The second would be, what are the units on those values? The third would be, because there are now resistance and capacitance values in OpenROAD, the Openlane config, the standard cell technology LEF file, and the OpenRCX calibration tables, what is the order of precedence? And fourth, why do the values for capacitance in the config.tcl files match nothing that I ever recall seeing before?

one thing we noticed between the tools: https://github.com/The-OpenROAD-Project/OpenLane/commit/569e10c86826864d2f01927a883ef4a0da3aaf74

@Tim Edwards Good questions 🙂 Let me answer what I can. I'll copy in @Matt Liberty so he can keep me honest. Firstly there are technology specific files in OpenROAD just for the purposes of testing, so don't pay too much attention to that. As for the units, I'm somewhat confused. I thought they might be dimensionless (per square) but they appear to be per length of wire. This from the OpenROAD documentation:

The resistance and capacitance values are per length of wire, not per square or per square micron. The units for `-resistance` and `-capacitance` are from the first Liberty file read, resistance_unit/distance_unit (typically kohms/micron) and Liberty capacitance_unit/distance_unit (typically pf/micron or ff/micron). If distance units are not specified in the Liberty file, microns are used.

My understanding is the

set_layer_rc

estimates take precedence over the TLEF data, and the OpenRCX tables aren't used at all for timing repair. As for where these values came from, I'm not sure. It does look like jjcherry has a script that generates the capacitance values from looking at taped out designs (guessing because I see this reference in the data:

# correlateRC.py gcd,ibex,aes,jpeg,chameleon,riscv32i,chameleon_hier

)

I disabled it based on instructions from the OpenROAD team.

@Tim Edwards the technology dependent values are in a test directory not in the OR source code. The units match the liberty which is standard practice in timing tools: pulling_resistance_unit : "1kohm"; so you can blame Skywater if you find it odd.

@Matt Liberty FYI there's been updates to the sky130 OpenRCX data recently. Would it be possible to get Cherry to use those updates to recalculate the RC esimates? In some of my designs my fmax went down by 80% and capacitances went up by ~2x

Is that right? That's a huge change

@Matt Liberty I thought it was a bit steep, but I haven't dug into it. @Tim Edwards were we expecting such large changes with the new OpenRCX data?

there's a back and forth going on- there's a reason we haven't merged the latest open_pdks into openlane

@donn Ahh good. I can wait for that to be resolved, and then we can get the set_layer_rc data updated to match

@Matt Liberty: I'd blame Synopsys for the weird use of kohms/micron as a base unit. I assume that means per micron at the wire minimum width? So:

via3

is wrong; it has

0.3766E-3

when it should be equal to the value for

via2

, or

3.368786E-3

.

via4

value should be

0.376635E-3

(what

via3

is now), and the value for

via4

is an old value for a redistribution layer contact which does not actually exist in this process. The resistance values are correct (assuming that the chosen name "LAYERS_RC" is misleading because it looks like the values are given in order C, then R). The capacitance values, I have no idea where they come from. For local interconnect, for example, the area cap is pretty straightforward at 6.29aF/um for a minimum wire width of 0.17um. For fringe cap, it is not clear to me what conditions that should be specified at (single-sided? Total? Assuming nearby wires at minimum distance? Track distance?). But the liberty file for the standard cell library says that load capacitance is given in pF, so the value in LAYERS_RC of 1.5e-4 is 150aF/micron, which seems quite high to me. Certainly much higher than anything I've seen coming out of Calibre extractions. So where does that number come from?

@Tim Edwards We can agree on that 🙂

Anyone who tells me that my numbers are all wrong, I'm not going to disagree with them, but I need some half-decent analytical justification for why I'm sticking those numbers into the PDK.

Where are you taking your values from?

I have essentially two sources: One is a test layout I put through Calibre and got all sorts of values for inter-layer area, fringe, and sidewall capacitance for that (under a limited set of geometries). I was able to go back and verify the numbers I got against the equations in the PEX deck for Calibre from skywater-src-nda (disregarding various nth-order effects). The second is a huge set of parameter values found in the SPICE models in the skywater-pdk repository. These have the benefit of being specified at all process corners. They have the drawback that I have no information on how to interpret the numbers, although I think I understand all the two-layer interactions for area, fringe, and sidewall. They have the clear benefit that all the numbers are in the open-source repository.

@Tim Edwards do you have some time to do a call and discuss this a bit further?

Not today or tomorrow, but otherwise, sure.