UPF support tested with openroad-2024-06-11

[titan73]

I have problems reading the upf (2.1) for my design which is an hard IP.

I have read #3531. Since it's mark as answered, I open a new one.

Some command are missing:

• upf_version
• create_supply_port
• create_supply_net
• connect_supply_net
• create_supply_set
• set_port_attributes
• add_port_state
• create_pst
• add_pst_state

And some commands have missing options:

• -include_scope and -supply missing from create_power_domain
• -isolation_supply, -sink and -source missing from set_isolation (set_level_shifter has sink and -source)

I have also several questions.

1. What upf version openroad is supposed to support?

2. Same question for all examples in git?

• ./test/upf/mpd_top.upf
• ./test/upf/mpd_aes.upf
• ./src/upf/test/data/mpd_top/mpd_top_ls.upf
• ./src/upf/test/data/mpd_top/mpd_top.upf
• ./src/upf/test/data/mpd_top/mpd_top_combined.upf
• ./src/ifp/test/upf/mpd_top.upf
• ./src/ifp/test/upf/mpd_shifter.upf

3. Are there reporting command related to upf (power domains, supply ports, ...)? I searched but didn't find any.

4. set_level_shifter has 2 options -input_supply and -output_supply that take supply net. Where these nets are supposed to be defined?
   Morover where do these options comes from? UPF 2.0 and 2.1 do no have them. They have -input_supply_set and -output_supply_set that take supply sets (and not nets).

5. How supply ports are supposed to be created in openroad since there are no command create_supply_port.

Thanks in advance

[maliberty]

I'm glad to have someone trying to use this functionality as we have developed it but need people to test and give feedback.

UPF is a large standard (> 500 pages) and OR supports only a core set of functionality. OR is only concerned with the design creation aspects of UPF and not the functional behavior which it doesn't control. We are open to enhancing the set we support as the community needs but don't expect to reach 100% coverage anytime soon. We have worked off the 1801-2018 standard.

Reporting commands are a hole. What would you like to see in this area? It shouldn't be hard to add some. You can query odb directly or use write_upf today.

set_level_shifter takes -input_port -output_port. It looks like those should have been -input_supply/-output_supply. I'll fix that.

Power nets either come in explicitly in the netlist or are created by pdn. You can look at set_voltage_domain in https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/pdn/test/power_switch_upf_regions.tcl as an example. We could add commands to create them from UPF though you will still need to configure pdn for an actual implementation as UPF is quite logical and not physical in its description.

[maliberty]

I have to correct my answer - set_level_shifter already takes -input_supply / -output_supply. It is set_level_shifter_cell that uses -input_port / -output_port. That is a non-UPF command for implementation.

[maliberty]

Those options do exist in the standard:

[titan73]

Great! I'm happy to help.

I'll prepare a simplified upf of our design.
Note that we've just converted the power state table from 1.0 (using add_port_state, create_pst and add_pst_state which are deprecated) to 2.1 with add_power_state. This was planned for later but if something is done in openroad, it's better to implement something which is not deprecated.

I'll think about with my colleage about what could be added for reporting. In the meantime, I'll try querying odb. How can I do that? I don't see any command that accesses the database.

The input netlist from synthesis does not have any power information in our flow & tools although the level shifters are inserted. And Yosys does not support upf anyway. We'd like to create power ports in upf to kept compatibility with other flows & tools so we use the same upf everywhere.

Thanks!

[titan73]

Here is the simplified version with add_power_state:

upf_version 2.1

create_supply_port VDDD1V2
create_supply_port -direction inout VDDD

create_supply_net VDDD
create_supply_net VDDD1V2
create_supply_net GNDD

connect_supply_net -ports VDDD VDDD
connect_supply_net -ports VDDD1V2 VDDD1V2
connect_supply_net -ports GNDD GNDD

create_supply_set ss_GNDD_VDDD1V2 -function {ground GNDD} -function {power VDDD1V2}
create_supply_set ss_GNDD_VDDD -function {ground GNDD} -function {power VDDD}

create_power_domain PD1 -include_scope -supply {primary ss_GNDD_VDDD}
create_power_domain PD2 -elements pd1v2 -supply {primary ss_GNDD_VDDD1V2}

One signal does not have the default power of its power domain

set_port_attributes -ports out_signal_1v2 -receiver_supply ss_GNDD_VDDD1V2

add_power_state ss_GNDD_VDDD1V2
-state {on_1v2 -supply_expr {(power == {FULL_ON 1.08}) && (ground == {FULL_ON 0})}}
-state {off_1v2 -supply_expr {(power == {OFF})}}

add_power_state ss_GNDD_VDDD
-state {on_std -supply_expr {(power == {FULL_ON 2.25}) && (ground == {FULL_ON 0})}}

add_power_state PD1
-state {dig_on -logic_expr {
(ss_GNDD_VDDD1V2 == on_1v2) &&
(ss_GNDD_VDDD == on_std)}}
-state {dig_off -logic_expr {
(ss_GNDD_VDDD1V2 == off_1v2) &&
(ss_GNDD_VDDD == on_std)}}

set_isolation iso_PD2_from_ss_GNDD_VDDD1V2_to_ss_GNDD_VDDD
-clamp_value 0
-domain PD2
-isolation_sense low
-isolation_signal pd1v2/i_isolation
-isolation_supply ss_GNDD_VDDD
-sink ss_GNDD_VDDD
-source ss_GNDD_VDDD1V2

set_level_shifter ls_PD2_ss_GNDD_VDDD1V2_to_ss_GNDD_VDDD
-domain PD2
-sink ss_GNDD_VDDD
-source ss_GNDD_VDDD1V2

set_level_shifter ls_PD2_ss_GNDD_VDDD_to_ss_GNDD_VDDD1V2
-domain PD2
-sink ss_GNDD_VDDD1V2
-source ss_GNDD_VDDD

[titan73]

I tested and checked our upf with add_power_state with our design in our flow & tools and everything is fine.
So I can test openroad when it's available and check against our flow.

[titan73]

Not sure it worth it to implement legacy 1.0 support but in case you implement it in a row, as it does the same thing, here is the old code:

add_port_state VDDD
-state [list VDDD_nom 2.25]

add_port_state VDDD1V2
-state [list VDDD1V2_nom 1.08]
-state [list VDDD1V2_off off]

add_port_state GNDD
-state [list gnd_on 0]

create_pst USB_pst -supplies {VDDD VDDD1V2 GNDD}
add_pst_state pd1v2_on -pst USB_pst -state {VDDD_nom VDDD1V2_nom gnd_on}
add_pst_state pd1v2_off -pst USB_pst -state {VDDD_nom VDDD1V2_off gnd_on}

[titan73]

Any news on this topic?

[titan73]

Note that if power ports are not created in upf, the associated pins cannot be imported from floorplan .def file with read_def.
Since pdn is run after the .def import, we can't rely on pdn for power ports creation.

[WARNING ODB-0247] skipping undefined pin VDDD1V2 encountered in FLOORPLAN DEF
[WARNING ODB-0247] skipping undefined pin GNDD encountered in FLOORPLAN DEF
[WARNING ODB-0247] skipping undefined pin VDDD_FTP encountered in FLOORPLAN DEF
[WARNING ODB-0247] skipping undefined pin GNDSUB encountered in FLOORPLAN DEF
[WARNING ODB-0247] skipping undefined pin GNDA_FTP encountered in FLOORPLAN DEF
[WARNING ODB-0247] skipping undefined pin VDDD encountered in FLOORPLAN DEF
[WARNING ODB-0247] skipping undefined pin VDDA_FTP encountered in FLOORPLAN DEF

[titan73]

I found a workaround to get the power pins imported:
- Use odb::dbNet_create to create all power nets
- Read .def
- Read .def a second time

I have not been able to create ports. I tried create_logic_port to fake them with no success. Anyway reading the .def a second time magically work!

[maliberty]

We could allow floorplan mode to create power pins/nets as they are often not in Verilog. However it sounds like you prefer to create them from UPF so I'll focus on that.

[titan73]

Yes I prefer through UPF. Great. Thanks.
I'm just trying to advance further in the flow in the meantime.

[titan73]

Any news of UPF support?
Should I create an issue to track progress? It seems we can use check boxes that can be updated.

[maliberty]

Sorry but I haven't been able to give this priority at the moment. Feel free to make a tracking issue.

[titan73]

I entered #5617.