Missing Resistance for vias in tech lef about globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0 HOT 14 OPEN

@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

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

@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.

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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.

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

@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.

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

@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.

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

@maliberty @tspyrou looking at the tech lef:

It seems that there are some RESISTANCE value for the fixed VIA definitions:

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

• VIA Via4_HH DEFAULT
  

  globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef

  Line 1064 in 1ebee70

  RECT -0.130 -0.130 0.130 0.130 ;

• VIARULE Via4_GEN_HH GENERATE
  

  globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/tech/gf180mcu_5LM_1TM_9K_7t_tech.lef

  Line 1216 in 1ebee70

  RECT -0.130 -0.130 0.130 0.130 ;

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?

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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).

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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

@RTimothyEdwards is RTimothyEdwards/open_pdks#281 the right issue to follow to track the OpenRCX refinements?

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

@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

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

I believe so

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.

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).

from globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0.