Customizing Low-Power Platforms Using UPF Dynamic Properties

Low power design and verification engineers need a way to continuously probe various dynamic properties of UPF objects in order to monitor the current state of a verification strategy and utilize that information to develop custom low-power verification environments. Unfortunately, there hasn’t been a reliable, formalized way to do this.

Since availability of the dynamic properties of unified power format (UPF) objects to design and verification tools (i.e., simulators) are strictly governed by the UPF LRM processing phases, we propose a methodology that orchestrates the processing of UPF phases with simulator steps.

Based on UPF information model concepts, this new methodology allows engineers to query any dynamic properties of UPF objects through a Tcl API and pass object information on to appropriately instantiated SystemVerilog API-based design code. For example, Tcl API can be used during simulation execution on the fly to populate any attributes for low-power SystemVerilog checker modules that are already queried and bound (during elaboration steps) into a RTL design through the UPF bind_checker.

Specifically, this methodology utilizes the foundations of UPF information models (UPFIM) in accordance to UPF processing phases. This ultimately accommodates custom low-power checker query processing in a consolidated manner. The Tcl API query to a UPFIM database is used with the bind_checker command to bind the checker whose interface uses the corresponding SystemVerilog HDL native representation types. The automatically creates objects of the correct type during the design and UPF elaboration steps in a three step simulation flow and allows continuous access to reflect it on the port or ports of the SystemVerilog checker module.

The following retention checker examples illustrate this methodology. The checker will fire a “success” assertion when save and restore operations are performed in the correct manner. Alternatively it flags violations when save and/or restore operations fail.

Code 1: Custom Retention (Save-Restore Correct Operation) Checker Example

## Custom SV Checker ‘ret_checker.sv’
import UPF::*;
module checker_retention(sav_sig, res_sig, sav_cond, res_cond, ret_clk);
    input sav_sig, res_sig;
    input upfExpressionT sav_cond;
    input upfExpressionT res_cond;
    input ret_clk;
    wire clk;
    assign #1step clk = ret_clk;

    property p1;
        @(posedge clk) (sav_sig |-> sav_cond.current_value);
    endproperty

    property p2;
        @(posedge clk) (!res_sig |-> res_cond.current_value);
    endproperty

    assert property (p1) $display(">>>%t ----- Save success", $time());
        else $display(">>>%t ----- Save not executed", $time());

Code 2: Regular UPF Bind and Query Functions for Custom Retention Checker Example

## Regular Power Management UPF ‘dut_top.upf’
create_power domaon PD –elements { top_vl top_vl1}
... ... ...
## Retention Strategy
46 set_retention pd_retention \
47        -domain pd \
48        -retention_supply ss \
49        -elements { top_vl1/q top_vh1/q } \
50        -save_signal { ret1 posedge } \
51        -restore_signal { ret1 negedge } \
52        -save_condition  {!UPF_GENERIC_CLOCK && sc} \
53        -restore_condition {UPF_GENERIC_CLOCK && !UPF_GENERIC_ASYNC_LOAD && rc}
## Regular UPF Commands/Options 
## For e.g. defining other PD, PD’s supply set, association, 
## Power state etc.

## Binding design module, Regular UPF and Custom Retention Checker through UPF bind_checker
bind_checker $instance_name -module checker_retention -bind_to tb -ports $ports_list

## Utilization of UPF Tcl Query Functions in Consolidated UPF flow 
foreach RET_STRATEGY [upf_query_object_properties $PD -property upf_retention_strategies] 
 {set ret_save_signal [upf_query_object_properties $RET_STRATEGY -property upf_save_signal]
  set ret_sav_sig_port [list sav_sig [upf_query_object_properties \
      $ret_save_signal -property upf_control_signal]]
  set ret_restore_signal [upf_query_object_properties $RET_STRATEGY -property upf_restore_signal]
  set ret_res_sig_port [list res_sig [upf_query_object_properties \
      $ret_restore_signal -property upf_control_signal]]
  set ret_save_condition [upf_query_object_properties $RET_STRATEGY -property upf_save_condition]
  set ret_sav_cond_port [list sav_cond $ret_save_condition]
  set ret_restore_condition [upf_query_object_properties $RET_STRATEGY -property upf_restore_condition]
  set ret_res_cond_port [list res_cond $ret_restore_condition]
  set RET_STRATEGY_NAME [upf_query_object_properties $RET_STRATEGY -property upf_name]
  set RET_QUERY [query_retention $RET_STRATEGY_NAME -domain $PD -detailed]
        array set RET_DETAILS [join $RET_QUERY]
        set RET_CLK $RET_DETAILS(upf_generic_clock)
        set ret_clk_port [list ret_clk $RET_CLK]
        set ports_list {} lappend ports_list $ret_sav_sig_port $ret_res_sig_port $ret_sav_cond_port  
        $ret_res_cond_port $ret_clk_port
        set ret_path [upf_query_object_pathname $RET_STRATEGY]
        set is_ret [upf_object_in_class $RET_STRATEGY -class upfRetentionStrategyT]
        set cell_type [upf_query_object_type $RET_STRATEGY]
## Printing Useful Information for the Retention Strategy 
puts "RET INFO STRATEGY: $RET_STRATEGY\n PATH: $ret_path\n type: $cell_type\n"}

Code 3: Transcript Results for Custom Retention Checker Example

## Useful Information for the Retention Strategy 
-- Loading module checker_retention
STRATEGY: /tb/pd.pd_retention1
PATH: /tb/pd.pd_retention1
type: upfRetentionStrategyT
... ... ...
## Assert Property p1 and p2
# ** Error: (vsim-8906) QPA_RET_SEQ_ACT: Time: 36 ns,  clock toggled  during retention period for retention element(s) in scope '/tb/top_vl': q 
# File: ~/test.upf, Line:46, Power Domain:/tb/pd
#                   37 pwr= 1, ret= 1, ret1= 0, clk= 1, rst= 0, d=1, q_vl= 01 01, q_vl1= 01
# 
# >>>                  37 ----- Save not executed
# >>>                  37 ----- Restore success

The use model shows the ultimate objective of consolidating phases 1~5, in such a way that it allows a single UPF flow containing both UPF (Tcl) and UPFIM Tcl API integrated with bind_checker commands during the elaboration steps. As a consequence, the execution in the simulation steps will reveal the final results in its entirety at once. Please note that the object passing between the Tcl query and checker port may or may not contain UPF native HDL representation types; hence upfExpressionT appears only in the checker but not in the UPF Tcl query. This is because, when ports of native HDL representation types are defined in the checker model, the elaboration step will automatically create a connection of continuous access using a continuous mirroring API defined in the UPFIM. Figure 1 shows the implemented results of the proposed methodology in the third step of design and UPF execution. The current value of the restore condition property “p2 pass/fail” status, etc. can be evaluated through the verification platform captured below.

Fig. 1: Custom Checker Verification Platform

This methodology allows designers to create checker modules in such a way that they can readily utilize object passing by query function and hierarchical references, as well as with or without native SystemVerilog HDL representations. Thus this novel methodology enables designers to continuously probe UPF dynamic objects and build custom low-power verification portfolios on existing low-power simulation platforms. If carefully designed, these custom checkers can be reused across many low-power projects.

To learn more about how to increase your low power design verification platforms, check out the new whitepaper Probing UPF Dynamic Objects: Methodologies to Build Your Custom Low-Power Verification Platform.