Quite often I am seeing, different switch cells are used in parallel(controlled turn-on) to shut-down

power to a block. If someone need to write an UPF, it would  look something like this

create_power_switch gprs_sw_0 \
  -domain GPRs/GPRS \
  -input_supply_port {in GPRs/VDDG} \
  -output_supply_port {out GPRs/VDDGS} \
  -control_port {gprs_sd PwrCtrl/gprs_sd} \
  -on_state {sw_0_on_state in {!gprs_sd}}

create_power_switch gprs_sw_1 \
  -domain GPRs/GPRS \
  -input_supply_port {in GPRs/VDDG} \
  -output_supply_port {out GPRs/VDDGS} \
  -control_port {gprs_sd PwrCtrl/gprs_sd} \
  -on_state {sw_1_on_state in {!gprs_sd}}

If you look at the above there are multiple drivers for the supply net “GPRs/VDDGS”, this would result

in an error if the supply net is not created using the UPF command

create_supply_net  VDDGS  -domain GPRs/GPRS -resolve parallel

Syntax of the above command is

create_supply_net net_name
[-domain domain_name][-reuse]
[-resolve <unresolved | one_hot | parallel | parallel_one_hot>]

Working on hierarchical UPF flows these days, its quite interesting to observe how tools optimize PST hierarchically and also on how to constrain/write UPF for lower level blocks.

There are quite a few challenges in terms of UPF with respect to

(a) Location of special cells such as LS/ISO/ELS…etc

(b) Depending on whether location is parent/self, physical implementation is going to be different for each of these strategies

(c) How to assemble blocks at the top level and finally analyze the power intent.