https://open-source-silicon.dev logo
#openlane
Title
# openlane
a

Anton Blanchard

03/24/2022, 7:30 AM
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
t

Tim Edwards

03/24/2022, 1:00 PM
@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?
Just looking at the numbers for resistance, the values would only be correct if they are in kohms, which is a very oddball choice for resistance units.
m

Matt Venn

03/24/2022, 4:15 PM
GLB_RESIZER_TIMING_OPTIMIZATIONS defaults to 0 now
could this also make a difference to the routing congestion issues we've seen?
a

Anton Blanchard

03/24/2022, 6:08 PM
@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:
Copy code
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
)
@Matt Liberty I've been meaning to look into why we disabled that timing fixup stage (or else why it was a bad idea in the first place). @donn might know
d

donn

03/24/2022, 6:37 PM
I disabled it based on instructions from the OpenROAD team.
👍 1
m

Matt Liberty

03/24/2022, 6:40 PM
@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.
@Anton Blanchard yes set_layer_rc overrides the LEF values. OpenRCX is only used for final signoff not optimization. Cherry has been tweaking the values to better correlate to the final routing values we see.
The post-groute repair was under development and is now pretty much done. We haven't yet turned it on in ORFS but if you want to use it you can go ahead.
If you do you should use a pretty current OR version
a

Anton Blanchard

03/24/2022, 6:55 PM
@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
m

Matt Liberty

03/24/2022, 6:56 PM
Is that right? That's a huge change
I've asked that he document the process so that anyone could run it. At that point he can be out of the loop on updates.
👍 1
a

Anton Blanchard

03/24/2022, 6:57 PM
@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?
d

donn

03/24/2022, 6:58 PM
there's a back and forth going on- there's a reason we haven't merged the latest open_pdks into openlane
we're tuning magic parasitics extraction
a

Anton Blanchard

03/24/2022, 6:59 PM
@donn Ahh good. I can wait for that to be resolved, and then we can get the set_layer_rc data updated to match
t

Tim Edwards

03/24/2022, 7:44 PM
@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?
@Matt Liberty: This is why there has been back-and-forth: I don't trust any of the values I see anywhere.
m

Matt Liberty

03/24/2022, 7:51 PM
@Tim Edwards We can agree on that 🙂
t

Tim Edwards

03/24/2022, 7:55 PM
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.
m

Matt Liberty

03/24/2022, 7:58 PM
Where are you taking your values from?
t

Tim Edwards

03/24/2022, 8:05 PM
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.
@Matt Liberty: Everything in the open_pdks repository under the
openlane
subdirectory was given to me by the Openlane developers (until my attempts to generate the openRCX calibration tables myself), so it does not necessarily match anything else in the repository unless I've made some effort to cross-check it.
m

Matt Liberty

03/24/2022, 8:11 PM
@Tim Edwards do you have some time to do a call and discuss this a bit further?
t

Tim Edwards

03/24/2022, 8:12 PM
Not today or tomorrow, but otherwise, sure.