Missing Resistance for vias in tech lef

[kareefardi]

Expected Behavior

No Via resistance in tech lef

Actual Behavior

Via resistance in tech lef

Steps to Reproduce the Problem

1. 1. 1.

Specifications

• Version:
• Platform:

[proppy]

@kareefardi looks that there are some RESISTANCE specified for the non-default VIA wiring: https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/blob/main/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef#L322

is this issue about also having value in the via LAYER definitions? https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/blob/main/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef#L95

[kareefardi]

Yes exactly. The resistance information is lost through VIARULE for instance.

[proppy]

@RTimothyEdwards @tspyrou @donn is that a hard blocker for the PDK to be usable with OpenLane?

[atorkmabrains]

@mohanad0mohamed Please take a look at this. We will discuss on Sunday. @proppy We will get back to you soon. I believe this is really important.

[maliberty]

VIARULE GENERATE statements have an optional RESISTANCE field but it defaults per the manual: Default: The resistance value in the LAYER (Cut) statement

So either the VIARULE needs a resistance or the cut layer does. It appears that neither has it here which isn't good.
@proppy @tspyrou

As for importance, this will only affect vias in the power grid as the detailed router doesn't use generated vias. So IR drop analysis would be somewhat off but timing would be unaffected.

[tspyrou]

@RTimothyEdwards @proppy In looking in the PDK I don't see any openrcx setup. The LEF rules are very rough estimates only. We have found that normally the rules in LEF are optimistic and in most pdks we have a setRC.tcl For example these values override the LEF and are much more accurate. https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/platforms/sky130hs/setRC.tcl I think we will likely need a setRC.tcl file for this PDK as well as the OpenRCX setup for final timing.

[RTimothyEdwards]

@tspyrou : The rules file for OpenRCX is maintained in open_pdks. It is derived from the capacitance modeling in magic, which currently is about as good as it is in SkyWater (that is, needs a bit of refinement in the modeling plus scripts to run a complete set of curve fits on the existing GF data, and/or data from running FasterCap. All that is in the works). The current rules file for OpenRCX for GF180MCU is a rough estimate, much better than the LEF rules, although like the SkyWater rules file is tending toward pessimistic calculations of delay. If the tendency toward pessimism is in the modeling, I should be able to figure that out and get rid of it.

[proppy]

@maliberty @tspyrou looking at the tech lef:

It seems that there are some RESISTANCE value for the fixed VIA definitions: https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/blob/1ebee70d934f91f6b289419a2c724d91e0d04895/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef#L1069

Given that that dimentions seem to correspond to the VIARULE definitions:

• VIA Via4_HH DEFAULT https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/blob/1ebee70d934f91f6b289419a2c724d91e0d04895/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef#L1064
• VIARULE Via4_GEN_HH GENERATE https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/blob/1ebee70d934f91f6b289419a2c724d91e0d04895/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef#L1216

And that according to http://coriolis.lip6.fr/doc/lefdef/lefdefref/LEFSyntax.html#918957

Note: A RESISTANCE value attached to an individual via is no longer recommended.

Would it be "correct" to move the RESISTANCE value from the individual VIA to the corresponding VIARULE definition?

[maliberty]

No it would be better to have a per cut value on the LAYER definition assuming only simple cuts are used (which is likely but I haven't verified).

[proppy]

@tspyrou is there a setRC.tcl equivalent for OpenLane?

@RTimothyEdwards is https://github.com/RTimothyEdwards/open_pdks/issues/281 the right issue to follow to track the OpenRCX refinements?

[maliberty]

@proppy https://github.com/The-OpenROAD-Project/OpenLane/blob/master/scripts/openroad/set_rc.tcl

[proppy]

@maliberty oh I see, so this would eventually come up from the gf180mcu open_pdks openlane config: https://github.com/RTimothyEdwards/open_pdks/blob/cc0029b45c68137aa21323912f50d2fc17eeea13/gf180mcu/openlane/config.tcl#L114

[maliberty]

I believe so

[antonblanchard]

Note that ORFS has a set of scripts from @jjcherry56 to create RC layer estimates based on real designs. We really need to do this vs using the LEF data as @tspyrou mentions.

It would be useful to integrate this functionality into Openlane (I haven't had the time myself yet). The script to create the data is at:

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/util/write_net_rc_script.tcl

It creates the data in a separate pass, but we could just dump the data during the openlane flow based on a variable. The script to create the RC layer estimates is at:

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/util/correlateRC.py

Which not only creates more accurate estimates for each layer, but creates better RC values used before global routing (set_wire_rc).