Upfront Analysis of Low Power Specification, Assertions and Testbench to Enable Reuse

By Kanwar Pal Singh,
Cadence Design Systems, Inc.

Abstract

Static analysis of the design during RTL development, to check for design errors and violation of the coding styles leads to shorter design and verification cycle. Design checking has often been associated with checking just the RTL code. As design and verification become complex, just ensuring that the RTL follows good coding practices does not give you the maximum return. One need to ensure that not only the design but the complete environment around it (Power Specification, Assertions and Testbench) is semantically correct, reusable, portable and follows good coding practices. This ensures that the engineer spends less time in the downstream design and verification steps and also ensures that when the design block is integrated in different designs, engineers can save on time. During RTL development, problems are easier to identify and fix, and the cost of any changes is very low. Proposed methodology is an enhancement of the checking of HDL design before the design is functionally verified and synthesized [1].

Introduction

This paper discusses the different aspects, in addition to the RTL, which should be checked for static errors and good coding practices to reduce design and verification cycle time. These are: Power specification, Assertions and Testbench. The methodology created to check power specification, assertions and testbench, upfront during design and testbench development is also discussed in this paper. Setting up this methodology has benefited both the design and verification engineers and details are shared in this paper. The last section presents the future work, which can be taken up to extend the analysis of the RTL and the associated environment upfront in the design and verification cycle.

Analysis of the Power Specification

With the evolution of low power design methodology, the specification of low power circuit/domains is now done along with the RTL development. This common low power specification is used for power aware verification, low power synthesis and other downstream tasks. Checking the low power specification upfront (during RTL development) for correctness and integrity with RTL helps in saving the design time and also facilitates reuse. There are primarily two kinds of checks which can be performed to ensure efficient low power design:

• The low power specification is in sync with the RTL
• The RTL follows good coding practices for low power simulation and synthesis

Following are the checks to ensure that the low power specification is in sync with RTL:

• An isolation rule/cell is specified for insertion between two power domains

• All the design elements referenced in the power specification are actually present inthe design e.g.

For the following specification of the isolation rule to get executed

create_isolation_rule -name ir -from PD1 - isolation_condition cond1

"cond1" should be present in the design

• The design element specified for state retention should get synthesized into astate element

• All retention flops in a power domain should have a common save/restore control

• The control for isolation cells in the same power domain should be connected to acommon pin

• If there is a Power Control Module (PCM) in the design, the control for isolation and state retention should be the output of the PCM

Some of the good low power design practices which can be checked at the RTL include:

• The switch able power domain should not contain any non-synthesizable constructs.
• All the Flip-Flops in a power domain should be initializable
• The design should not contain Flip-Flop models which will not allow clock gating

Analysis of Assertions

To enable Assertion Based Verification (ABV), the RTL code is instrumented with assertions, which capture the intended behavior of the design [4]. It may happen that the bug is in assertion itself rather than the design or the assertions are not verifying the intended behavior. In such cases, time is wasted in verifying and debugging the failures in the incorrect assertion.

Following are some of the issues, which are detected by analyzing the assertions written with the RTL description:

• Issues in the HDL expressions inside the assertions
• Contradictory assertions
• Trivially true/false assertions
• Overlapping assertions
• The Assertions that can lead to different results in simulation and formal verification
• Assertion naming conventions

Checks on HDL expressions inside the assertion:

• Operand size mismatch in case of comparison, arithmetic and relational operators e.g. property P1 = always (a == b)-> c; This may lead to unpredictable result if ‘a’ and ‘b’ are of different sizes

• Potentially incorrect use of operators in the HDL expressions i.e, use of bitwise operators in case of conditional expression e.g property P2 = always (a & b) -> next d; This can lead to unpredictable result if ‘a’ and ‘b’are multibit vectors.

Contradictory assertions:

• Two assertions in the design that verify opposite behaviors. e.g
  

property P1 = always (sig_a == 1’b1); and property P2 = always (sig_a == 1’b0);

• Single assertion with two contradictory expressions e.g.
  

property P3 = always ((state == S0) && (state != S0));

Trivially true/false assertions:

• Trivially true assertions – The assertions which will always evaluate to TRUE irrespective of the design context e.g
  

property P1 = always (d || !d)

• Trivially false assertions - The assertions which will always evaluate to FALSE irrespective of the design context e.g
  

property P2 = always (d && !d)

Overlapping assertions:

An assertion for which the start value exists for more than one sample when the assertion is active is called an overlapping assertion. e.g.

Assertions that lead to different results in simulation and formal verification:

The simulator and the formal verification tools interpret certain constructs differently.

• Use of ‘X’ or ‘Z’ in assertions e.g.
  

property P1 = always ((out2 != 1’bX)) -> next req);

• Unclocked sequential Assertions e.g.
  

property P2 = always {in1;in2} |=> {in3; in4};

Assertion naming conventions:

 As per the methodology, naming conventions can be applied to assertions, assumptions, coverpoints etc. e.g.

• All Assert statements should start with assert_. These should include a prefix indicating whether the assertion is written on an input, output or an internal design signals

• All Cover statements should start with cover_

• All assume statement names should start with assume_

• All property and sequence names should follow the recommended naming conventions

Analysis of the Testbench

With structured verification approaches becoming more and more important, it is required that the testbench is highly efficient and reusable [6].

Analysis of the testbench primarily includes:

• Checking that the testbench follows the coding guidelines as per the chosen verification methodology
• The testbench does not contain any constructs which can lead to portability issues

This ensures that the time spent in simulation is spent on debugging the design errors and not the testbench errors and the testbench can be reused with different variants of the DUT and in different verification environments #

Checking the compliance of testbench with the verification methodology:

• Correct connectivity of components in the testbench e.g
• Monitors should not drive any design signals
• The monitor at the sub-system level can be parameterized and used at system level
• Response Checkers must avoid accessing design signals
• Response checkers should check the design at transaction level
• Naming conventions for testbench components
• The testbench components –monitors, response checkers, Bus Functional Models (BFM), clocking blocks should be named according to the chosen methodology

Coding practices which can lead to portability issues:

• Use of non-standard language constructs
• All connections not made using mapping by name. Instead positional mapping is used

Proposed Methodology

In a typical flow, the RTL design is first checked for coding style, semantic and structural errors. This design checking applies only to the RTL description of the design. Once the design qualifies this stage, it is simulated and/or formally verified to catch the functionality bugs and then synthesized. In the proposed flow the initial checking of RTL description of the design is enhanced to include the checking of power specification, assertions and testbench as well. The design is taken for functional verification and synthesis only when all the semantic issues in the design, power specification, assertions and the testbench are rectified. This is shown in Fig 1.


Fig 1

As the proposed methodology is to enhance the already existing RTL checking step to include the additional aspects, it does not introduce an extra step in the design flow. This makes the application of the methodology very easy and efficient.

Experimental Results

Currently this methodology has been successfully piloted by different design and verification teams at different companies. Design and verification engineers in these pilot projects have started to reap benefits of checking power specification, assertions and testbench upfront. As the issues are reported during the RTL development it gives a lot of flexibility to the engineer to make changes and avoid iterations later. The results from these pilot projects have shown a significant savings in time as the engineer can catch issue and fix it upfront in the design cycle.

Future Work

Currently the set of checks developed for checking the power specification, assertions and Testbench is evolving. As design and verification engineers use this methodology more, in future the set of checks will be enhanced to make it more comprehensive. This will increase the value add of upfront analysis of power specification, assertions and testbench. Another area of future work is to include more aspects in the upfront analysis, which get added asadditional design and verification specification are moved up at the RTL level e.g Timing information of the design.

Conclusions

This paper discussed the upfront analysis of power specification, assertions and testbench along with checking the RTL This analysis helps in early detection of any errors and helps to make the power specification, assertions and testbench reusable. This eliminates a lot of issues which the designer will otherwise catch in the downstream design and verification process, and thus represent a timesaving. This upfront analysis can be done along with the usual RTL design checking and does not introduce any extra step in the typical design and verification flow. This methodology has been piloted with different design and verification teams and has shown desired results.

References

[1] L. Bening , “An RTL Design Verification Linting Methodology” Proceedings of the 8th International HDL conference, April, 1999

[2] Architecting, Designing, implementing and verifying low-power digital integrated circuits

[3] Stephen Bailey, Mentor Graphics, Low Power Design Specification from RTL through GDSII

[4] Harry Foster, Adam Krolnik, David Lacey, Assertion-Based Design, Kluwer Academic Publishers

[5] L. Bening and H. Foster, Principles of Verifiable RTL Design, Kluwer Academic Publishers, June 2001

[6] Leena Singh, Tim Pylant, “Leveraging Assertions in SystemVerilog Testbench to get to Closure”, Proceedings of DesignCon 2006