We are so much used to having explicit supply nets and ports in the design as well as in UPF,  its hard to visualize how a hardware logic designer would code the UPF using supply sets.   For those of you who are not familiar with supply sets, here is a quick preview of the same

Supply sets refers to collection of supply nets which substitutes a complete supply source, and can be used to power up an element of a design. Each of these supply nets provide a function such as power/ground/different well supplies….etc

There are predefined supply sets, which can be referred to by any supply set through a specific supply set handle such as primary/default_retention….etc.

Also any supply net explicitly created can be referred in any supply set and function of this supply net could be totally different in each supply sets where its referred. These supply sets can be referred easily by specifying chip_top/module_a/PD1.my_supply_set, which refers to supply set that’s available under the scope chip_top/module_a, belonging to power domain PD1.

One of the main advantage of supply set is that , initially it can be a place holder with just a function attribute ,which can be later modified/updated as and when more information is available.

for example:

Initially we can start with

create_supply_set my_supply_set –function {power} –function {ground}

later it can be updated to

create_supply_set my_supply_set –function {power VDD} –function {ground VSS} –update

Being involved with every phase of design cycle, I can imagine, how this can be mis-coded/mis-interpreted at different phase of design cycle. This could be a real nightmare to debug, if anything is either misinterpreted by the tool or mis-coded by designer.

will cover more on this topic later with examples.