An RTL Power Optimization Technique Based on
SystemVerilog Assertions
Khaled Khalifa
Alexandria University
Alexandria, Egypt
khaled.khalifa.eg@ieee.org
Abstract‫ ـــــ‬This paper presents a novel technique based on
System Verilog assertions to optimize the consumed power of
RTL designs. The proposed technique helps the designer to
enhance his RTL code towards achieving low power design.
The designer codes the proposed technique according to the
design specifications and integrates the coded technique into
his test bench. The coded technique generates directive
massages which will be followed to modify and enhance the
design code to reduce the consumed power of the design. The
idea behind this technique is to monitor the whole design
signals. Thus, this technique is a design-dependent technique as
it depends on the design specifications. The coded technique
determines the targeted signals of the specific input then it
displays the mistakenly setting signals which may consume
additional wasted power. This technique can be applied and
included in any verification framework like the Universal
Verification Methodology (UVM) to integrate the power
optimization feature of this technique with the features of the
used framework. Through applying this technique, the
consumed power of the design is significantly reduced as it
catches each unused design signal that consumes additional
wasted power. This paper explains how to apply the proposed
technique with respect to any design specifications and also
provides the technique code itself of a simple RTL case study.
Moreover, it also attaches the resultant directive massages and
presents a comparison between the consumed power before
and after the modification of the RTL code according to the
directive massages of the coded technique.
Index Terms— Design Power Optimization, System Verilog
Assertions, Verification Environment, HDL, RTL, Test Cases,
Power Extraction.
I. INTRODUCTION
With the explosive growth in laptops, portable personal
communication systems, and the evolution of the shrinking
technology, the research efforts in low power design
techniques have been intensified. Today, there are
increasing numbers of portable applications requiring low
power architectures than ever before. Therefore,
architectures with low power consumption become the
major candidates for design of microprocessors and system
components [1].
The VLSI low power design problems can be broadly
classified into two categories: analysis and optimization.
Optimization is the process of generating the best design
with the lowest power consumption. The task of the design
engineer is to carefully weigh each design code line with the
specification constraints to generate the lowest design
978-1-5090-1496-5/16/$31.00 © 2016 IEEE
Khaled Salah
Mentor Graphics
Cairo, Egypt
Khaled_Mohamed@mentor.com
consumed power. Performing accurate and efficient power
enhancement as early as possible in the flow of creating any
design is important in creating a power optimized designs
and essential for the successful low power designs. Our
technique is concerned of performing accurate and efficient
design power enhancement through being part of the design
verification environment in the flow of creating RTL
designs.
Our key contributions of this paper are as follows:
I. Proposing a power optimization technique utilizing
System Verilog assertions.
II. A detailed discussion of our power optimization
technique through a simple case study to compare
the power results of the original code with the
optimized code after applying the proposed
technique.
III. An overview on how assertions are written to
generate directed test cases.
IV. Providing a method of how to extract the consumed
power of any synthesizable code with respect to the
dissipated power in signals activities.
The rest of paper is organized as follows. In section II,
The proposed power optimization technique is presented. In
Section III. A simple case study is explained. Conclusions
are given in section IV.
II. THE PROPOSED POWER OPTIMIZATION
TECHNIQUE
Design verification is considered to be the most important
process in the SoC design flow as more than 70 percent of
the time is spent on design verification. Since the
verification process verifies the correctness of the design, it
may doesn’t concern of any other additional design code
that doesn’t affect the design correctness. This additional
design code may cause consuming more additional wasted
power as this code isn’t in the design specifications but it
doesn’t affect the design correctness.
For example, if the specifications of a certain design tell
that when the input is high, the output signal (A) only must
be high. But in the real implementation code, the designer
wrote that when the input is high, both output signals (A)
and (B) are high. In the implementation code, setting signal
(A) is considered to be a specification code but setting
signal (B) is considered to be an additional code which
doesn’t affect the design correctness, but consumes
additional wasted power. So, the verification environment
must integrate a power specific verification code which is
responsible for catching the resources of the design code
which consume additional wasted power and then displays
directive massages to help the designer to improve his
design code and optimize the design consumed power. This
can help any design and verification engineer to catch the
power wasting resources in the design code and accurately
determine the correction of the code with respect to the
design specifications.
One of the main power consumption resources in any
design is pulling up the design signals to keep them in high
state. Thus, this paper concerned of optimizing the
consumed power of setting the design signals by
determining the unused signals which consume additional
wasted power. In this paper, we propose a novel technique
for any RTL design code to catch the coding mistakes in
setting the design signals and generate directive massages to
help the designer to enhance the design code and optimize
the design consumed power. Such a technique can be
applied on any RTL design code makes it a generic
methodology.
The technique concerned of the design signals only which
are the design output signals and the design internal signals
as the design input signals can’t be controlled by the design
code itself. This makes us know for a fact that as the number
of these design signals increase, the consumed power of the
design subsequently increases. This proposed technique
employs System Verilog assertions based verification to
continuously monitor the whole design signals and verify
the functionality of each design signal with respect to the
design specifications. So, this technique is a design
dependent technique. Thus in this paper, we are going to
explain the creation criteria of the technique and how to
apply it on any design specifications.
This section explains the proposed power optimization
technique which utilizes System Verilog assertions. This
technique proposes two different types of assertions to
perform two different types of checks which are warning
assertions and fault assertions by following certain creation
steps which are shown in Fig.1.
Create Sequence Expressions
(Specifying design specifications of setting the design signals
state)
Create Property
(Specifying input combinations with respect to the design
specifications)
Assert Property
(Specifying the content of the displayed directive massages
whatever warning massages or fault massages)
Fig.1 The assertions creation flow.
A. Create Sequence Expressions
In any design model, the functionality is represented by
the combination of multiple logical events. These events
could be simple Boolean expressions that get evaluated on
the same clock edge or could be events that evaluate over a
period of time involving multiple clock cycles.
SystemVerilog assertion provides a key word to represent
these events called "sequence" [2].
In sequence step, the designer specifies the state of the
design signals at every single input combination according
to the design specifications where every input combination
sets some specific design signals to high state and the others
to low state. Every single input combination has to be
described by two different types of sequences which are
state sequences and operating sequence.
State Sequences
The state sequences specify the signals state of a single
input combination in different expressions using different
SVA keywords and relationships to cover every single test
scenario to specify these signals setting state. To create the
state sequences, the designer will use SVA logical
relationships to accurately specify the setting states of the
design signals. These SVA logical relationships are used to
describe the relationships between different design signals
of a certain input combination which can be used to AND
signals (&&), OR signals (||) or NOT signals (!).
The state sequences are divided into two categories which
are continuous state sequence and change state sequences.
1) Continuous State Sequence
The continuous state sequence specifies the continuity of
setting the state of certain design signals as a specific input
combination continues to be applied on the design input
signals for a period of time. Thus, the continuous state
sequence is always only one sequence as it describes the
state of each design signal with respect to a specific input
combination according to the design specifications.
2) Change State Sequences
The change state sequences specify the change of the
design signals state while a new input combination is
applied on the design input signals. So the number of
change state sequences is more than one as any design
signal can be in any state before getting set to the targeted
state of the new input combination. Even it can be more than
the number of the design signals themselves as there are
multi combinations of these states with respect to the design
specifications. Change state sequences will be created with
edge definitions as SVA has built in edge expressions that
let the designer monitor the transition of signal value from
one clock cycle to the next. This allows the designer to
check for the edge sensitivity of signals. These built-in
functions are:
$rose (signal name): This returns true if LSB of the signal
changed to 1.
$fell (signal name): This returns true if LSB of the signal
changed to 0.
$stable (signal name): This returns true if the value of the
signal did not change.
 Operating Sequence
After specifying every setting state of the whole design
signals of every single input combination in the state
sequences, the designer has to integrate these state
sequences into only one operating sequence which will be
verified during simulation. The binary operator (or) is used
to logically combine all of the different state sequences of a
certain single input combination to cover all test scenarios
described in every state sequence. The operating sequence
will succeed when any of the state sequences succeed and
will fail when all of the state sequences fail.
After explaining the creation of sequences, the sequence
expressions must be coded as shown in Listing.1.
B. Create Property
A number of sequences can be combined logically or
sequentially to create more complex sequences. SVA
provides a keyword to represent these complex sequential
behaviors called "property" [2]. In property step, the
designer integrates the input combination with its operating
Listing.1 The creation code of the state sequences
1 // input combination1: x’bxxx //
2 // State Sequences
3 // Continuous State Sequence
4 sequence s1_x’bxxx; sig1 && !sig2 && … ; endsequence
5 // Change State Sequences
6 sequence s2_x’bxxx; $rose (sig1) && !sig2 && … ;
endsequence
7 sequence s3_x’bxxx; $rose (sig1) && $fell (sig2) && …. ;
endsequence
8 //………. The other change state sequences …………`
9 // Operating Sequence of input combination (x’bxxx)
10 sequence so_x’bxxx; s1_x’bxxx or s2_x’bxxx or s3_x’bxxx or
…. ;
11 endsequence
sequence according to the design specifications. In this
integration, the designer will use concurrent definition
which is based on clock cycles. In concurrent assertions, test
expression is evaluated at clock edges based on the sampled
values of the signals involved. In SVA, clock cycle delays
are represented by a "##" sign and implication operator
with its different types. There are three types of implication
operator which are overlapped implication, non-overlapped
implication and implication with a fixed delay on the
consequent.
Overlapped implication: Overlapped implication is
denoted by the symbol (|->). If there is a match on the
antecedent, then the consequent expression is evaluated in
the same clock cycle.
Non-overlapped implication: Non-overlapped implication
is denoted by the symbol (|=>). If there is a match on the
antecedent, then the consequent expression is evaluated in
the next clock cycle. A delay of one clock cycle is assumed
for the evaluation of the consequent expression.
Implication with a fixed delay on the consequent: This
type uses both of overlapped and non-overlapped
implications, however the designer specify the number of
clock cycles delay. It is recommended to use overlapped
implication to easily specify the targeted delay directly after
the symbol of overlapped implication (|->) using "##" sign.
Thus, the property creation just must be coded as shown in
Listing.2.
Listing.2 The creation code of the property step
1 //Property of input combination1: x’bxxx //
2 property p_x’bxxx;
3 @(posedge …) ( specific input combination) (|->,|=>)
4 (so_x’bxxx “operating sequence of the specific input
5 combination”);
6 endproperty
C. Assert Property
The property is the one that is verified during a simulation.
It has to be asserted to take effect during a simulation. SVA
provides a key word called "assert" to check the property
[2]. In this step, the designer asserts the property of each
input combination and specifies the displayed information
of the directive massages. A designer can print a custom
error or success message using the "action block" in the
assert statement. In this action block, several system tasks
can be used to control over severity of a failing assertions.
As ($fatal) will be used with fault massages and ($display)
is used for warning massages. Thus, the assert property step
must be coded as shown in Listing.3.
Listing.3 The creation code of the assert property step
1 //Assert property of input combination1: x’bxxx //
2 assert_pro_x’bxxx: assert property ( p_x’bxxx)
3 else ($display,$fatal) ("%m: warning/fault massage:
4 information of the directive massage");
After explaining the assertions creation flow of the
proposed technique which is presented in Fig.1, this
technique follows the assertions creation flow to propose
two different categories of assertions which are warning
assertions and fault assertions.
1) Warning Assertions
Warning assertions are responsible for catching the
additional code which doesn’t affect the design correctness,
but consumes additional wasted power. These warning
assertions will be created by following the assertions
creation flow presented in Fig.1. Warning assertions display
directive warning massages which contain directive
information to be followed by the designer to modify and
enhance the design code and reduce the design consumed
power. This directive information must be displayed as
shown in Listing.4.
Listing.4. The displayed information of different directive massages.
1 //Displayed Information of the directive massages //
2 Warning/Fault massage: input combination,
3 additional/wrong setting signals, correct setting signals.
2) Fault Assertions
Fault assertions are responsible for catching the wrong
code which violates the design specifications and affect the
design correctness. Thus, fault assertions are used as
directed test cases to verify the correctness of setting the
design signals and correct them. These fault assertions will
be created by following the assertions creation flow shown
in Fig.1 except in property step. In property step, (not)
operator is used to create a forbidden sequence from
happening. In other words, it is expected that the property to
be false always. If the property is true, the assertion fails.
Thus, fault assertions also display directive fault massages
as shown in Listing.4 which contain directive information to
be followed by the designer to correct the design code with
respect to the design specifications.
 TABLE 1.
III. A CASE STUDY : DE-MULTIPLEXER COMPARISON BETWEEN THE POWER RESULTS OF THE DE-
MULTIPLEXER CODE
Consumed power of
As setting the design signals to high state increases the the DE-MUX code
consumed power of the design, this paper is interested in Before applying the modification of the
the case where the signals of the clocked de-multiplexer is 17 mW
technique directive massages
high ‘1’. This de-multiplexer is one hot output design After applying the modification of the
14 mW
which has two input control signals; regardless of the technique directive massages
clock and reset signals; and two output signals as shown in
Fig. 2. This paper studies only when input (A) is high. The
other input signal is a one bit select signal which chooses RTL Design Simple RTL
only one output of the two de-multiplexer outputs will be Tesetbench
set to the high state (‘1’). We have implemented the de-
multiplexer using Verilog hardware description language. Xilinx ISE QuestaSim
In Listing.5, the case statement of the de-multiplexer (RTL Synthesis) (RTL Simulation)
Verilog RTL code is provided. Place and Route Simulation Dump
To generate the power report of the RTL code, some Netlist
NCD VCD
files are needed to be generated from the RTL code. These
files are the native circuit description file (.ncd) and the
value change dump file (.vcd). The NCD file is a fully XPower Analyzer
placed and routed netlist file generated from the place and (Consumed Power Calculation)
route process in Xilinx tool [3]. The VCD file contains a
Power Report
series of time-ordered value changes for the signals in the
given simulation model which generated from Questasim PWR
tool [4]. To generate the VCD file from Questasim tool, a
simple test bench must drive the RTL code to insert all of Fig.3 The flow of extracting power report of the RTL code.
the valid input combinations to the design input signals.
Finally, the resultant power report file (.pwr) is generated
from XPower Analyzer tool [5] as shown in Fig. 3. IV. CONCLUSIONS
After applying the proposed technique in Listing.6 on the This paper proposed a novel technique which employs
de-multiplexer code in listing.5, the resultant directive the power of System Verilog assertions to optimize the
massage will be as follow: DE_MUX design consumed power. We have discussed our technique
_tb.dut.output_monitoring.assert_set_out1: Warning strategy which is utilizing System Verilog assertions to
Massage: select: 1’b0, Out2:1'b1, Out2:1'b0. continuously watch the whole signals of the design since
Enhancing the de-multiplexer code according to the any design signal is set at any time can be monitored. Thus,
displayed directive massage makes out2 in line 4 of this technique catches the code mistakes in setting the
Listing.5 must be equal to 0. By comparing the power design signals which consume additional wasted power and
reports of the de-multiplexer code before and after the displays directive massages to correct the design code.
modification of the directive massages, the power results in Regardless of the abstraction level of the design code, the
TABLE.1 shows that the consumed power of the modified proposed technique is a generic methodology which can be
de-multiplexer code is reduced by more than 17.5%. applied on any design code to enhance it. The proposed
Clk Reset technique can be included in any verification framework to
Out1 integrate the power optimization feature of this technique
A with the features of the used framework. For our future
DE-MUX work,, we are going to create a computer aid design tool to
Out2 systematically generate the proposed types of assertions
Select (1bit)
Fig.2 The architecture and the truth table of the DE-MUX case study. according to the user design specifications to be attached in
Listing.5 The case statement of the DE-MUX case study the user verification environment. So the designer doesn’t
1 case (select) need to think about all possible cases and the CAD tool will
2 1'b0 : begin automatically generate them.
3 out1 = A ;
4 out2 = A ; // Insert directive warning message
REFERENCES
5 end
[1] Yeap, Gary K. Practical low power digital VLSI design. Springer
6 1'b1 : begin
Science & Business Media, 2012.
7 out1 = 0 ;
[2] S. Vijayaraghavan and M. Ramanathan. A Practical Guide for
8 out2 = A ;
SystemVerilog Assertions. Springer, 2005.
9 end
10 default : begin [3] http://www.xilinx.com/support/documentation/sw_manuals/xili
11 out1 = 0 ; nx 13_1/ise_c_overview.html.
12 out2 = 0 ; [4] http://www.mentor.com/products/fv/questa/
13 end [5] http://www.xilinx.com/support/documentation/sw_manuals/xili
14 endcase nx11/pp_p_process_xpower_analyzer.html.