UPF support for `report_power`

[akashlevy]

Are there any near-term plans to add support for UPF during power analysis?

I could potentially contribute this if there is interest.

[QuantamHD]

UPF is being implemented in OpenROAD. Were you planning on using the interface there, and propagating it to OpenSTA?

I think it would be unfortunate if we ended up with two implementations with slightly different capabilities.

[QuantamHD]

https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/upf

[akashlevy]

I think implementing UPF mainly on the OpenROAD side makes sense. Many of the UPF commands don't even make much sense in OpenSTA, like the retention cell specs, etc...

But probably a few of the commands should be implemented in OpenSTA to enable domain-aware power analysis. Specifically, I'm thinking about the commands that define power domains, power nets, power switches, and power state tables. I'd like to see it possible to do domain-aware + state-aware power analysis in OpenSTA without having to use OpenROAD. And it would be great if OpenROAD relied on OpenSTA's ability to handle power domains/switches/tables during power analysis

[akashlevy]

Does it make sense to upstream some of the UPF functions that don't have strong dependences on odb? Or is it somewhat difficult to extricate that in the OR UPF implementation?

[QuantamHD]

I think this might be a case where it needs to implemented similarly to the network interface, where a downstream user can provide their own storage object/implementation which in the case of OpenROAD would be backed by ODB and in OpenSTA you can provide a "ConcreteImplementation".

I think a nice property of the OpenROAD UPF implementation is that the UPF data is persisted in its database, and if you move some of the implementation over to OpenSTA we will lose that property and worse it'll be mixed.

If it were up to me (it's not) I would suggest making the abstract network like UPF that OpenROAD can integrate with, and then you provide your own ConcreteImplementation and provide a TCL layer in OpenSTA that can be turned off for OpenROAD that implements the commands you want.

[QuantamHD]

Also @jjcherry56 should weigh in since ultimately he decides what goes into OpenSTA

[akashlevy]

I think this might be a case where it needs to implemented similarly to the network interface, where a downstream user can provide their own storage object/implementation which in the case of OpenROAD would be backed by ODB and in OpenSTA you can provide a "ConcreteImplementation".

That sounds like a nice solution to me, personally... curious to hear Cherry's thoughts

[jjcherry56]

The OpenSTA Network interface implements what is known as an "adapter" pattern (see Design Patterns: Elements of Reusable Object-Oriented Software). I agree that this is the right way to handle this.

[maliberty]

It would be helpful if you defined what specific commands you intend to implement and how they would be exposed to OR in the Network API.

[akashlevy]

Hi Matt, I'll have to dive deeper into how the network API works first, as I haven't used it myself yet. I'd like to have "full" support for 1801-2018 UPF 2.1 commands. Only some of these make sense to have concrete implementations for in OpenSTA:

(Implemented in OR: highest priority)

• read_upf (should be aliased as load_upf)
• write_upf (should be aliased as save_upf)
• create­_po­wer­_domain
• create_logic_port
• create_power_switch
• set_domain_voltage
• map_power_switch

(Implemented in OR, but doesn't need a concrete implementation in OpenSTA: low priority)

• set_isolation
• set_level_shifter
• use_interface_cell

(Not implemented in OR yet: medium priority)

• Parameter/attribute/object get and set:
  • add_parameter
  • find_objects
  • set_design_attributes
  • set_port_attributes
• Nets and connections:
  • associate_supply_set
  • connect_logic_net
  • connect_supply_net
  • connect_supply_set
  • create_logic_net
  • create_supply_net
  • set_domain_supply_net (legacy)
  • set_correlated
  • set_equivalent
• Power/port states+transitions:
  • add_port_state
  • add_power_state
  • add_pst_state (legacy)
  • add_state_transition
  • add_supply_state
  • create_pst (legacy)
  • create_power_state_group
• Power model definition:
  • define_power_model
  • apply_power_model
  • begin_power_model (legacy)
  • end_power_model (legacy)
  • set_design_top
  • set_scope
  • upf_version

(Not implemented in OR and don't affect power much: low priority)

• Composite domains:
  • create_composite_domain
• Retention cells:
  • map_retention_cell
  • set_retention
  • set_retention_elements
• Repeaters:
  • map_repeater_cell
  • set_repeater
• Variation:
  • set_variation

(Pretty much irrelevant: very low priority)

• Simulation:
  • load_simstate_behavior
  • set_simstate_behavior
  • sim_assertion_control
  • sim_corruption_control
  • sim_replay_control
• Other:
  • bind_checker
  • create_upf2hdl_vct
  • name_format
  • set_partial_on_translation

[maliberty]

Why would set_isolation or create_power_switch make sense to sta?

[akashlevy]

If you're using a VCD for power analysis, the power switches would be very important for setting whether a domain is powered on/off, right? Isolation is not that important for power analysis, though, I think.

[maliberty]

The power switches defined in UPF are only logical and not physical instances. From the spec:

The create_power_switch command defines an abstract model of a power switch. An implementation may 
use detailed power-switching structures that involve multiple, distributed power switches in place of a 
single abstract power switch, and/or re-order the specified embedded power switch chain. 

Perhaps the difference doesn't matter to sta but it does matter to OR. Since sta uses a network adapter I don't think it can see a divergent view.

[akashlevy]

Yeah, I mean any command that affects the power netlist will need to have a concrete implementation in whichever tool is hosting the netlist. So if OR is hosting, it should use create_power_switch as power intent. And if OpenSTA is hosting, sta should use the command to infer switching behavior for power analysis; I'm thinking this could either be by using the edit API to add an inferred power switching Liberty cell into the STA network or something simpler like storing information about the switch's control port in a data structure for power analysis.

I guess we may end up with a lot of places where the implementations diverge, but that's to be expected... UPF has different interpretations when analyzing power vs. using it as power intent for physical design.

[akashlevy]

I'll come up with some ideas on how to reuse as much as possible though. I need to study the OR UPF implementation and the network API in a bit more detail before I can do so in an intelligent way

[akashlevy]

I did a bit more thinking/research and I think I've come to agree with @QuantamHD that it makes most sense to have UPF processed prior to OpenSTA power analysis. Basically use UPF to construct a power netlist (or pseudo power netlist) and have OpenSTA handle the power analysis as usual once that's done. So I'm going to close this issue for now. If there's interest in native UPF support + power netlist construction in OpenSTA, we can potentially re-open this issue in the future