Writing Reusable UPF For RTL And Gate-Level Low Power Verification

By Durgesh Prasad, Jitesh Bansal and Madhur Bhargava

The Unified Power Format (UPF) is used to specify the power intent of a design. Once written, the UPF file is applied at every stage of the design cycle — starting with the RTL, then the gate-level, and finally during place and route.

A major problem is that the UPF needs to be refined or modified at every stage to keep it compatible with the netlist. For example, the UPF at the RTL level must be modified to be used for gate-level simulation due to design-hierarchy changes, cell placements, and cell connections. This creates different flavors of UPF which lack consistency and create maintenance problems.

This article shares a new methodology that allows you to write better UPF files at the RTL so that minimal or zero changes are required when it is reused during gate-level power verification. In order to better understand and implement these techniques, we also highlight all the differences between an RTL UPF and gate-level UPF.

Migration from RTL to gate-level low-power verification requires three conditions:

1. The UPF should be written so that it remains usable and valid for gate-level simulation.
2. Simulation tools must do some processing of the RTL UPF to make it work in gate-level simulation.
3. The UPF needs some enhancement to make the transition from RTL to gate-level simulation seamless and easy.

UPF verification at the RTL versus the Gate-Level Netlist
UPF-based verification at the RTL consists of creating power domains, inserting power aware cells — such as isolation, level-shifter, and retention cells — and defining a supply network to propagate power. Please note that the power aware cells placed in the design by application of UPF at the RTL stage are mostly simulation models, and they work as a placeholders for actual cells that will be created later during gate-level simulation. RTL power-aware verification ensures that power-aware cells are placed at all the required ports/state elements and the power distribution network is valid.

In the gate-level netlist, power-aware cells are already part of the design and UPF only complements them. There are two gate-level netlist flavors.

Pg-connected netlist: The pg-pins of the power-aware cells are present in the cell, and they are connected in the netlist itself. The use of UPF is to validate that pa-cells are placed at all possible locations as specified in the RTL UPF and that the supply network is properly embedded in the netlist as per the UPF.

Non-pg netlist: The pg-pins of the cell are not connected via HDL hierarchy, rather it is expected that the simulation tools will connect the pg-pin. At this stage the pg-pins provide Liberty information about the cells. This helps verification tools perform automatic connection of these cells and handle their corruption. Sometimes these connections are provided explicitly in the gate-level UPF via connect_supply_net UPF commands. In contrast to RTL, now the netlist has the actual implementation model for simulation.

Designers use various methodologies to perform gate-level power aware simulation. One way is to spit out a new UPF for the gate-level netlist after low-power RTL verification, but this method is not very reliable because gate-level UPF might not be equivalent to RTL UPF, due to synthesis tool issues and UPF interpretation. Also, the designer needs to do equivalence checking of the two UPF.

Another way some implementation tools propose is to take the golden RTL UPF and generate additional information (in terms of configuration file or a new UPF file) for gate-level simulation. This approach minimizes the synthesis tool’s bug risk but still doesn’t give designers much confidence. The most sought after approach is to reuse the RTL UPF for gate-level simulation too.

Benefits of reusable UPF
There are lots of benefits of reusing the UPF written for RTL simulation at the gate level. The important benefits are as follows:

Concise and easy: RTL UPF is very concise and simple to read. The main reason for writing a design in RTL itself is that it is concise compared to its gate-level netlist. Another reason is that when inserting power-aware cells, users don’t need to instantiate them one by one, they can simply write a single policy to instantiate multiple cells. Users can put their comments in the UPF file for better readability and maintenance. All of these benefits are lost if UPF is generated by a tool.

Tool-specific changes are preserved: Users might have done tool specific changes for various vendors. This is required because UPF is still evolving and hence, in spite of the IEEE standard, the interpretation of various UPF commands/concepts differ across vendors. Also users might have done tool-specific changes because they want to use the same UPF for structural checking tools as well as simulation tools.

Requirement of logical equivalence is eliminated: If a user is dealing with a single UPF at the gate level as well as at the RTL, then there is no requirement of doing logical equivalence for UPF; but if this is not the case, then they need to do equivalence checking to ascertain that their gate-level UPF is actually the same implementation of their RTL UPF.

Coverage of UPF remains intact: Today designers do the coverage of UPF objects and save it to achieve coverage closure. If the complete UPF is going to change in the gate-level netlist, then they have to repeat this step on the new UPF and merge the results back to achieve coverage closure.

Relevant differences in power aware RTL and gate-level simulation netlist
RTL and gate-level simulation are two very different types of netlist. RTL is more abstract in nature and consists mainly of always and assign blocks. Gate-level simulation is closer to silicon and consists mainly of cells and gates. Though logical intent is the same in both, the language style is different. In gate-level simulation, there are no generates or vectors, everything is flattened out.

In RTL low power simulation, logical intent is specified by the RTL netlist and power intent is specified by the UPF. Simulation tools do the low-power verification by superimposing power intent specified by the UPF file on the logical intent of the RTL netlist. All the power aware activities — corruption, isolation, retention — are done using the virtual low-power cells. The RTL netlist is not modified in any way. This enables users to reuse the same logical design with different power intent. In the synthesis phase, the UPF file is also passed along with the RTL netlist. The synthesis tool infers the low-power behavior specified in the UPF and adds the following low-power cells to the design:

• Isolation cells to signals crossing power domains
• Level shifters to signals crossing voltage domains
• Replacement of all flops with retention flops where specified

The gate-level simulation netlist not only has logical content but also some power intent. In gate-level simulation low-power verification there is no need to add virtual cells for power activities. They are already present in the design and just need power up and down behavior for low power verification.

The gate-level simulation netlist consists of cells which have their own power/timing specifications. These specifications are provided by liberty files and they should be followed thoroughly for the correct behavior of cells. For low power gate-level simulation verification these liberty specifications along with UPF are superimposed on the gate-level simulation netlist.

Challenges when reusing UPF
Briefly, the various problems when reusing RTL at the gate-level are:

Design elements are flattened in the gate-level simulation netlist. So, the signals and instances referred to in the RTL UPF might require changes when being applied to gate-level simulation netlist.

The state elements which were signals reg/logic/std_logic at the RTL have now changed to instances that implement retention/state behavior. So references to them in the UPF might need to be changed.

Isolation/level-shifter/repeater cells are now actually part of the netlist and hence their corresponding strategy is not very meaningful. Also, the synthesis tool might do the optimization of clubbing isolation and level-shifter cell to create an ELS cell.

Additional buffers/always-on cells/feedthrough cells are inserted in the design and they might be on the path of an isolation cell. This potentially changes the source/sink behavior of that isolation cell.

Simulation tools need to infer these existing low power cells and use them for simulation instead of inserting their own cells. Cell inferencing requires intelligence and may require extra information through liberty files or from HDL attributes.

Power specifications present in liberty files may be different from UPF specifications. Corruption semantics are defined by power_down_functions which do not exist at the RTL stage.

Due to these differences, writing a reusable UPF requires the deep understanding of UPF and various differences in the two netlist.

Writing reusable UPF
Specifying any vector signal in UPF: A vector signal “A” can be referred in UPF by a single occurrence as ‘A’ or multiple occurrences as A[0],A[1],A[2]. It is always a better choice to list down every bit in UPF, although it makes the UPF cumbersome, but it will help in gate-level simulation verification. Remember that in gate-level simulation, the signal will get flattened to \A[0] ,\A[1]…. So writing it in a bit-wise manner will keep the UPF consistent with gate-level simulation.

Hier-path scope difference: Sometimes the scope of the signal gets changed when translated to the gate level. For example, in the code below, the scope of the flop srpg_flp1 changes from dft_inst to its generate scope. We couldn’t find any simple or LRM compliant way to solve this inconsistency. Our recommendation is to write the elements in the gate-level UPF form. Some of the EDA vendors support the UPF written in gate-level form to be applied in RTL via more intelligent processing.

Hier-path separator “.” for generate hierarchy: A hier-path containing generate needs to be written using the “/” hier-path separator as per the UPF LRM, but when the RTL is flattened into the netlist, the generate names are collapsed into the child instance names. So the hier-path of instance in RTL “/tb/top/gen[0]/mid_inst” would be “/tb/top/\gen[0].mid_inst “ in gate-level simulation. So it is always a better choice to separate the generate hierarchies with “.” Instead of “/” , although it is not the LRM compliant way. We would like to see “.” allowed in the UPF LRM, just like “/”.

Use find_object command wherever possible, since the find_object command supports wildcard-based searching, also so a small name change in the gate-level simulation would not be a problem for the RTL UPF.

In the RTL stage, all of the PA cells are not present in the design. Only strategies are defined in the UPF and the tool inserts and powers them automatically. But in the gate-level netlist, cells are already present in the netlist and the tool needs to connect it’s supply pins properly. For the cases of retention, the retention flops which were represented as a signal in the RTL becomes an instance name in at the gate level. For proper pg-pin connections of these cells the tool needs to associate them with the correct strategy.

To ease the tool’s job, we recommend one of the following:

If the designer already knows the name of the actual implementation cell to be used during gate-level simulation, but doesn’t have the actual cell, then they should specify the additional UPF command map_*/use_interface_cell to specify the “-lib_cells” option. This will help the gate-level simulation tool to identify and associate the cells correctly.

If the actual implementation model is available during the RTL simulation itself, then use the “-lib_model_name” option of these map_* command to simulate the implementation model at the RTL itself.

You also need to specify the signal/ports on which the strategy is going to be applied. For isolation and level shifters, it is not possible at the first go to list out these signals individually because writing these strategies as -source/-sink is easier, concise, and more relevant. The same -source/-sink tends to break in the gate-level netlist because of additional buffers, AON and other elements in the actual source/sink path. So we recommend that once the RTL UPF with –source/-sink is verified, change the UPF strategies to be per signal basis assisted by the tool’s internal report or by using save_upf approach. Specifying the retention elements in a per signal basis helps a lot for the set_retention strategy because the sequential elements which are represented as signals during RTL would get converted to retention cell instances.

Supply connections to isolation/level_shifter/ELS cells
In a gate-level simulation netlist, an isolation/level-shifter/ELS cell could be dual rail or single rail. In case of dual rail, the cell has a primary as well as a backup power connection; however this is not possible at the RTL stage because it is the tool inserted cell that uses isolation strategy power as its single power source. This disparity can cause a mismatch in gate-level versus RTL simulation because corruption of these cells are being driven by different power source in the two stages.

Unfortunately UPF doesn’t provide any way to specify the dual connection, neither has it specified the way to define ELS cells, which are mostly multi-rail cells. The dual rail for these cells are mainly their source and sink power rails. So getting the information at the RTL stage about the source/sink power domains would help mitigate the issues arising due to multiple rails. UPF does provide the concept of UPF GENERICS to access this kind of information. Some vendors have gone further to enhance these GENERICS to access the isolation/level-shifter source and sink supplies. These GENERICS can further be used with a bind_checker to write relevant checks to catch the gate-level scenarios in the RTL UPF itself.

Here is an example of how to write an RTL UPF to catch a gate-level isolation cell issue arising due to isolation enable not being active while the source domain was off.

foreach ISO_STTG [query_isolation * -domain PD]
set query_output [ query_isolation $ISO_STTG –domain PD –details]. array set isolation_detail [join $query_output]
set src_pwr_port [list src_pwr $isolation_detail(upf_source_domain_pwr)] set src_gnd_port [list sink_pwr $isolation_details(upf_source_domain_gnd)]
…
set ports_list { … $src_pwr_port $src_gnd_port }

bind_checker $instance_name \
-module checker_isolation \
-elements $elements
-ports $port_list
…

In this example, the upf_generics “upf_source_domain_pwr”/”upf_sink_domain_pwr” are used to extract the source power and ground rail for every isolation cell. Finally these rails are passed as a port via the bind_checker command to be used in the checker module “checker_isolation”.

Conclusion
Migration from RTL to gate-level low-power verification requires the following:

1. UPF should be written in such a way that it remains usable and valid for gate-level simulation
2. Simulation tools need to do some additional as well as relaxed processing of the same UPF to make it work in gate-level simulation

• Lenient in UPF semantics checking
• Use liberty files for missing power specifications
• Enhance the search criteria of design elements to search flattened paths
• Automatic cell inferencing to avoid duplicate insertion of low power cells and proper connections of existing cells

3. UPF needs some enhancement to make the process of transition from RTL to gate-level simulation seamless and easy

• Flexibility to choose path separator. Currently it is “/”, but due to synthesis requirements it should also allow “.”
• Construct to specify ELS cells
• UPF generics to specify isolation/level-shifter source power and sink power
• Rules to clearly define the connection of power aware cells for non-pg connected netlist

This new methodology makes it easier for engineers to write RTL UPF so that minimal changes are required during gate-level power verification.

For more information, download our whitepaper, Low Power Apps: Shaping the Future of Low Power Verification.

Durgesh Prasad is a Low Power UPF Expert for Mentor, A Siemens Business with more than 11 years of experience. He holds a bachelor’s degree in Computer Science and Engineering from IIT, BHU. He is also a member of IEEE Low Power Working Group.

Jitesh Bansal is a Lead Member Consulting Staff with Mentor, A Siemens Business and has more than 7 years of experience in power-aware verification. He leads the development of low power verification solutions for Questa. He holds a bachelor’s degree in Electronics and Electrical Engineering from the Punjab Engineering College, Chandigarh.

Madhur Bhargava is a member of the consulting staff with Mentor, A Siemens Business and has more than 8 years of experience in low power verification and technology. He holds a bachelor’s degree in Electronics and communication engineering from Delhi College of Engineering, India. He is also an active member in UPF working group.