Shift left and Reuse in verification

SNUG India 2014 was a jam packed event! All sessions including the keynotes, papers, tutorials and the design expo were full with engineers pouring in huge numbers. Follow up questions during the presentations and curiosity of the engineers during the expo to understand the solutions from partners were clear indicators of the value these conferences bring in apart from the freebies :) 

Papers on the first day of Verification track focused on the 'Shift Left' approach viz confirming that the design is an exact representation of the spec by uncovering the issues early in the design cycle. The first 3 papers discussed involvement of acceleration/prototyping to enable early SW development and validation of the design in parallel to verification. The 4th paper talked about how the X’s of GLS can be stimulated at RTL to save time & avoid ECOs. While shifting left helps in achieving the goals faster, it is equally important to deploy tools & flows improving 'Reuse'. This was the gist of papers presented on the second day where users shared their experience with enhanced scalability and reusability on different aspects of the verification paradigm be it Formal, low power or IP and SoC verification. 

‘Shift left’ & ‘Reuse’ are interesting concepts sure to reap wonders when applied in conjunction! Really? Let’s see.

Reuse in verification is achieved predominantly through VIPs and test scenarios. 

Expectations from the VIP are not only limited to reuse in the context of IP at block or SoC level simulations. There is a need to have VIPs architected in such a way so as to be reused while porting the target design to a prototyping or emulation platform. If it is the system bus, the VIP needs to be partitioned such that the timed portion of the VIP can move into the box while the untimed portion still continues to be on the work station. SCEMI protocol enables the required communication between the host and the target box. If the VIP is a model for a peripheral sitting outside the chip, it can either fully reside inside the box if everything is to be programmed through the corresponding host IP or else have the same partitioning as the system bus VIP. While the benefits of moving to faster platforms are obvious, the challenges to enable this transition are multi-fold. Porting the design to a target box demands a struggle with partitioning amidst the complexity arising due to multiple clock and power domains. Though the industry has evolved to a large extent on these aspects, architecting and developing verification code that is portable between simulation and emulation is still in its infancy. 

VIPs are available off the shelf but a lot of test development today still happens with home grown test plan and test suite with reuse from what is provided as part of the VIP. Given that the ultimate verification goal is to have a functional SoC with minimal probability of a design bug, C based tests play an important role in achieving it. These tests need to be defined & developed in a planned fashion so as to enable reuse at simulation, emulation and even for Si bring up. A well thought about strategy can actually enable the first level of test development right at the IP stage where a model of the processor can be plugged as part of the IP test bench enabling early test development. Once this suite is ready, complex cases can be covered either with a detailed use case test plan and/or deployment of tools that enable test definition and development in an automated manner. With HW SW teams working in silos and probably in different geographies, a comprehensive solution that converges the two is quite difficult to achieve.

To realize the above there is a need to conceive the end picture, enable development of the pieces and finally connecting the dots to bring up multiple platforms early enough in the ASIC design cycle.

Gate Level Simulations : A Necessary Evil - Part 3

The response to the initial 2 posts (Part 1, Part 2) clearly show that GLS touches the career profile of almost all verification engineers. I am wrapping up this 3 part series on GLS with some recommendations that might be of some help if you aren’t already deploying them. Please do drop in an email or comment to share your tips & tricks.

To start, it is important to identify features targeted for GLS in the test plan upfront. Adding functional coverage/assertions to these features is a good practice. To set up GLS, develop the Verilog/VHDL TB (with DUT instantiation) from scratch so as to avoid any exceptions/force statements that might just pass from RTL simulations to GLS. If there is a provision, setup a process to develop/tune test cases for GLS such that all HDL code (DUT, TB & test cases) is compiled once and using ‘plusargs’ different tests can be simulated. The SDF should be compiled once and used for all tests. For initial netlist, whether you use zero delay/unit delay/pre layout SDF, disable timing check and have few smoke tests for sanity checks on the netlist. In case of large gate count, implementation team would be using hierarchical synthesis. If the hierarchy is logical you may want to try segregating GLS test points that are local to the components in hierarchy and try out GLS at that level. For designs that take some initial time to synchronize before the actual feature testing starts (particularly in networking domain), the tests can be developed such that multiple features are clubbed in 1 test. Some level of test case rewriting will save a lot of time during simulations.

Following is a basic common list of tests that most of the teams have in the GLS test suite –
1. Initialization tests i.e. chip coming out of reset and functional in different boot modes
2. Clock, Reset generation and clock dividers
3. Power aware simulations – covering features based on the power format specification
4. Test structures
5. Digital - Analog boundaries
6. Dedicated tests for timing exceptions in the STA
7. Stimulus to each block of the design atleast once

In order to have a controlled rework on the hierachical paths for force statements or monitors, pull out all paths in 1 HDL file under compile directives (e.g. `define in Verilog). This file can be included in the TB and modified/reviewed for every netlist release.

To control the SDF timing on synchronizers –
Enforce naming rules for such modules so that with a perl script you can turn off timing in SDF or through tcl interface to the tool turn off timing checks on selective instances. Where naming convention is not followed, there are some interesting ideas in the following papers –
- My favorite DC/PT TCL tricks, SNUG San Jose 2003
- SoC Gate Level Simulations (GLS) cycle time reduction – Simulation flow enablers, SNUG India 2008.
- Identification of Non-resettable flops for faster Gate Level Simulation, SNUG India 2010.

For debugging, simulation tools have some interesting features that can help narrow down the problem to some extent. A couple of them are – tracing the source of X propagation and expanding time step to highlight the order of execution. With some basic perl scripting you can triage the timing violations report into bins and then chase it accordingly.

Most of the above recommendations have worked well across multiple projects. It would be interesting to know if they hit any limitations in the design space that you work on so that we can discuss further on those specific corner cases for these recommendations.

Hope some of these would help you in your next tryst with GLS.
Happy BUG hunting!!!

Gate Level Simulations : A Necessary Evil - Part 1
Gate Level Simulations : A Necessary Evil - Part 2

Gate Level Simulations : A Necessary Evil - Part 1

Rising complexity, tightening schedules and ever demanding time to market pressure are pushing the industry to move to the next level of abstraction for design representation viz ESL (Electronic System Level). A similar push came in when there was a need to move from gate level to RTL. Even after efficiently using RTL simulations for a couple of decades, the industry is still relying on GLS (Gate level simulation) before sign off. Many organizations have recognized this effort so very important that there are dedicated GLS teams verying netlists for one project or the other throughout the year. Advancements in static verification tools like STA (static timing analysis) and Equivalence Checking (EC) have leveraged GLS to some extent but so far none of the tools have been able to abandon it. GLS still claims a significant portion of the verification cycle footprint.

On demand from some readers, here is a 3 part series that would try to address this less talked but significant topic.

Why necessary?

GLS or Netlist simulations typically need to start early when functional verification is still progressing to flush the GLS flow and verifying that the netlist is hooked up correctly. Timing at this point can be ‘zero delay’, ‘unit delay’. Later, these simulations are performed after back annotating first 'pre layout SDF' and finally ‘post layout SDF’ with the goal to assure that the design will run at the desired operating frequency. Following points summarize (in no specific order) the need for GLS in the ASIC design flow.

GLS are a must –

- To verify critical timing paths of asynchronous designs that are skipped by STA.
- To validate the constraints used in STA and EC. Static verification tools are constraint based and they are only as good as the constraint supplied. Careless use of wildcards, typos, design changes not propogating to constraints or incorrect understanding of the design all demand validation of these constraints.
- ­To verify any black boxes in EC. Multi vendor EDA tools flow is common. Sometimes to direct the synthesis, RTL instantiates a module from the synthesis tool vendor library for which an equivalent is hard to find in a competitor’s EC tool.
- To verify the power up and reset operation of the design.
- To verify that the design doesn’t have any unintended dependence on initial conditions.
- To verify low power structures absent in RTL and added during synthesis (power aware simulations). Apart from logical netlist even physical netlist (with VDD & GND) needs to be verified here.
- To collect switching activity for power estimation and correlation.
- To verify the integration of digital and analog netlist.
- To verify DFT structures absent in RTL and added during or after synthesis. Also required to simulate ATPG patterns.
- To generate ATE test vectors.
- To validate EDA tool flow change while moving from one vendor’s sign off tool to another.
- To validate that RTL simulations were not having any undesired force statements from test bench and masking bugs.

Finally, GLS is a great confidence booster in the quality of the netlist. The probability of having ‘sound sleep’ after tape out improves with GLS.

Suggested Reading -

1. ESNUG article - http://www.deepchip.com/items/0421-01.html
2. All my X's come from Texas...Not!! (SNUG 2004)

Gate Level Simulations : A Necessary Evil - Part 2
Gate Level Simulations : A Necessary Evil - Part 3

SNUG 2010, Bangalore

Although it's been a couple of months, I still thought of sharing my experiences from SNUG, one of the most touted conference in VLSI industry. SNUG 2010 @ Leela Palace Bangalore was witnessed by almost 2000+ engineers.

For me it was the first time I attended this event. Thanks to the recession that forced me to pack my baggages from Noida and move to Bangalore where most of the action is.

It started with the CEO Dr. Aart de Geus sharing vision of future from Synopsys perspective with a jam packed audience from the engineering community.

A few interesting messages from his keynote -

- Growth of semiconductor business = f(technology + state of economy) = Technomics.

- India & China slowly claiming stake with 6% & 9% growth during shrinking economy worldwide.

- Even though technology tried to pace up with Moore's law, the ROI is failling behind.

 

He also listed technologies to watch out for in 2010 -

- Cloud computing

- Energy conservation

- Video applications

 

After his enlightening talk, the technical tracks picked up. Since I was keen on keeping my tryst with taming bugs I jumped into the verification track. It started off with summarizing future trends on verification and then went into core technical where Synopsys users shared their interesting experiences.

 

Interestingly, there was an EXPO planned in the evening with different partners from the VLSI ecosystem show casing their products & services - a new feature successfully added to SNUG India.

 

Next day kicked off with a keynote from Global Foundries followed by an interesting session on cloud computing and verification papers.

Overall the SNUG expereince was good. Got a chance to meet friends and old colleagues. On my way back after 2 days of conference the mood was in sync with the BAG (probably inspired by bollywood flick - 3 idiots) gifted to the SNUG attendees by Synopsys symbolizing ALL IS WELL!!!