ABQ: Assertion Based Qualifier Methodology for Pre Existing Environment

Krishnan Ramakrishnan, Kotasubbarao Sajja, Md. Ameenoddin, Divya Shankar, Shiju Ullattil
Samsung India Software Operations

Abstract:

In the present Verification Scenario with shortening time to market, reuse of pre-existing verification environments becomes very important. It becomes part of verification engineer’s scheduled work list to check on the quality of pre-existing environments as well as to predict the amount and limitations of possible reuse.

ABQ (Assertion Based Qualifier) methodology provides the means to a verification team to reduce the qualifying time as well as provides insight into shortcomings of present and ingredients into future environment.

Introduction to ABQ Methodology

Assertion Based Qualifier methodology was born as a probable answer to the “reuse” predicament. As a methodology, ABQ offers the following advantages

• Validation of the effectiveness of pre-existing verification environment

• Allows assertions to be embedded to this pre-existing environment to verify newly added feature of DUT.

This methodology tries to harness the full potential and features of ABV (Assertion Based Verification) based methodology and IES (Incisive Enterprise Simulator by Cadence) tool, respectively. ABQ also provides the means to an engineer team to reduce the qualifying time of the existing environment. On following ABQ methodology for verification, o with the assertion coverage metrics compiled after regression, one can get a deep insight into shortcomings of present and ingredients into the future environment.

Issues with traditional verification flow

Traditional verification flow has certain inherent flaws which are addressed by the ABQ. In conventional hardware verification flow, there are no major hurdles when there are no major design changes and the same verification engineer is present and available throughout the course of the verification activity. However, when the design changes frequently, there is a need to update and account for these changes in the verification environment too. Validating these environment modifications consumes time and effort. Similarly, when the working verification engineer is changed/replaced mid-way during the verification activity, considerable time is spent by the newly appointed engineer to study and understand the existing verification environment. This study phase by the new engineer adds to the timeline of the verification. ABQ methodology aids in avoiding these kinds of unforeseen delays and meeting the initially agreed deadline for the verification activity.

This idea is represented as a flowchart below:

ABQ Methodology

ABQ is an assertion based functional coverage methodology which allows implemented SV (System Verilog) functional assertions to provide a qualitative insight into verification environment as well as much needed observability and controllability into ever evolving functional coverage metrics.

SV chosen as the language for implementing the assertions because of the following reasons:

• Since DUT was in Verilog, assertions written in SV will not hamper the simulation throughput (i.e. there will be no need for the IES simulator to use PLI).
• In certain specific scenarios, assertion implementation in SV is simpler when compared to PSL, OVL.

The approach in implementing ABQ methodology is listed below:

• Good understanding of DUT (Design Under Test)/standard specification
• Identify crucial interfaces/features supported by the DUT
• Verification environment development (which includes reference model and coverage implementation) in Specman or any other suitable language
• Write assertions which will cover the important control interfaces of DUT/features supported by the DUT (these assertions also act as checkers for the respective control paths)
• Activate coverage for the assertions created
• Run the existing regression suite for the DUT and report coverage

At this point of the verification cycle, the DUT RTL is modified and design features are changed.

ABQ implementation at this point through:

• Write assertions for new/changed features (can be written by any new engineer and does not have dependency on earlier environment developers)
• Run existing regression suite
• Analyze assertion coverage and check how much features/control signal conditions are covered.
• Report assertion coverage statistics using ICCR tool

ABQ Verification flow is represented in a flowchart given below:

Case study – DDR2/3 Memory controller interface

IP Features

• Compatible with AMBA AXI for access to DDR2, DDR3 SDRAM devices
• Configurable 1 or 2 memory chips
• Run time configurable row and column address bit number
• Programmable CAS Latencies.
• Synchronous 1:1 and 1:2 ACLK, MCLK Ratio
• Active, Precharge, Force Precharge and Self Refresh Power down features are supported
• Run-time configurable timing parameters for CAS Latency (CL), Write Latency, Read Latency etc.

The reason we chose memory interface for ABQ methodology implementation is that:

• Standard Interface:
  • Increases reuse
  • Reduced dependency on vendor/model correctness
  • Assertion standardization
  • Reduced Assertion Number
  • Reduced Compilation Time
• Coverage:
  • Multiple Item, Cross and Transition coverage to be implemented without dependency on vendor/model
  • Allows the complete set of commands to be uniformly implemented
• Generalization:
  • Increases extendibility for other memory sizes
  • Portability across various models and sizes
  • Easier Convertibility based on script/command line defines.

Assertion examples

Given below are 2 examples of the assertions which were coded in SV for the memory controller interface as part of ABQ methodology implementation

Example 1

• The Precharge Command is triggered when CS, RAS and WE are LOW and CAS is HIGH at the rising edge of the clock.
• Check for all the banks.
• Code –

Example 2

• This is accomplished by setting RAS HIGH, CS and CAS LOW at the clock’s rising edge.
• WE must also be defined at this time to determine whether the access cycle is a read operation (WE HIGH).
• Code –

Advantages of ABQ methodology

The main advantages of using ABQ can be summarized as given below:

• Writing assertions are far more simpler than trying to add new verification environment components and hence save development time
• Assertions suite are reusable across projects and promote reusability and reduce verification timeline
• Assertion coverage gives good insight on the effectiveness of the existing verification stimuli in shorter time, when compared to traditional approach of regression
• ABQ can be easily adopted by any new verification/design engineer who is not fully conversant with the existing verification environment, as it involves only coding assertions

Results achieved

The results achieved by ABQ methodology implementation for the Memory controller project are as follows:

• Cadence IES8.2-s008 supports Assertion coverage feature
• Using IES8.2-s008, assertion coverage was dumped for the existing regression suite
• Reported 2 major issues in memory interfaces of newly added feature
• With the assertion coverage data, we could also qualify the effectiveness of the existing verification environment

Conclusion

ABQ methodology was applied to the existing DDR2/3 Specman Verification environment. With ABQ application for the memory controller verification activity, we saved about 1 week of time with respect to the schedule of the activity.

As a methodology ABQ aids in

• Get a clear idea of the verification stimulus input to the RTL and their comprehensiveness
• Estimate the time needed for any environment changes far more precisely and in shorter time compared with the traditional approach of collecting functional coverage through regression

We also see that this result is achieved even the verification engineer is new to the verification environment.

Also, some preliminary checks on Memory PHY interface, normally overlooked in traditional verification flow for memory controllers was made possible through assertions in short time.

Acknowledgements

We would like to convey our thanks to the following people

• Mr. Arun N.C. (Senior Manager, Hardware Verification)
• Mr. Pushkar M.D.  (Development Manager, Hardware Verification)
• ASIC Memory Design and Verification team, India
• Cadence India Support team

for their constant motivation  and cooperation through out  the duration of  this project.

References

• Verification Methodology Manual for System Verilog by Janick Bergeron, Eduard Cerny, Alan Hunter, Andrew Nightingale
• System Verilog Language Reference Manual 3.1, Accellera
• DDR2 SDRAM Specifications, JEDEC
• DDR3 SDRAM Specifications, JEDEC
• System Verilog for Verification by Springer