Over-verification : an intricate puzzle

For verification, it was an eventful week. DVCON 2013 kept everyone busy with record attendance at the sessions and by following the tweets & blogs that resulted from them. The major highlight of this year’s conference was release of the latest update to System Verilog standard, IEEE 1800-2012 and free PDF copies made available, courtesy - Accellera.

 

With verification constantly marching to increase its claim on ASIC design schedule while retaining its position as a major factor for silicon re-spins, verification planning was a hot topic of discussion at DVCON. Some of the interesting points that came out of a panel discussion on verification planning were –

 

- Verification plan is not just a wish list. You have to define how you’re going to get there.

- Problem is not over-planning, but over-verifying designs because there has not been enough planning.

- Biggest objection we hear is we don’t have time to capture a verification plan. But you'll lose more time if you don't.

- What’s useful in verification planning is “ruthless prioritization.” You can never get it all done.

- My biggest challenge is getting marketing input into my verification plan.

- Failure to plan means planning to fail.

 

Last week, I guest blogged on a similar topic based on a recent survey conducted by Catherine & Neil. Clearly, the issue of poor planning gets highlighted in all areas of product development.

 

Traditionally, the verification plans were just a list of features to be verified, addressing ‘what to verify’. With the emergence of CRV, the plans started including the second aspect i.e. ‘how to verify’. Further, to bring focus to this never ending verification problem, CDV was adopted. The verification plans now started including target numbers in terms of coverage (code, functional and assertions) to define ‘when are we done’. With a given set of resources, when the ASIC design schedule is imposed on the verification plan, meeting the goals is a challenge. There arises a need to prioritize verification in terms of the features. Remember, Any code that is not verified will not work!

 

To enable this “ruthless prioritization”, collaboration is required among marketing, software and hardware groups to align to the design objectives. Everyone needs to understand the potential end applications and preferential ways in the design to achieve them. In case of IPs, this could mean that the initial releases target a limited set of applications based on the customers on board. Once that is achieved, ‘over-verifying’ can take over to further close on the grey areas. In case of SoC, it is a tough call. While design cost continues to increase with diminishing dimensions, the break even may not happen with limited applications (as a result of limited verification) of the SoC. The problem gets aggravated further with the specifications changing on the fly. A platform based approach could be a potential solution where variants of SoC are churned out frequently, but again defining the platform and prioritizing the features boils down to the same problem. A tough nut to crack!

 

The whole point of over-verifying comes to the fore front because verification is the long pole in the schedule. What if the designs could be ‘over verified’ within the timelines? What does it take to achieve that? Are tools like intelligent test benches, formal verification, hardware acceleration or cloud computing a solution? If yes, what is the associated cost and how does it affect?

 

There is no easy answer to any of these questions. In words of Albert Einstein, “The world we have created is a product of our thinking. It cannot be changed without changing our thinking.”

 

Probably when an answer comes out, we will be on the road of commoditizing the hardware. Till then 'over-verification' is what we have to live with!

Evolution of the test bench - Part 2

In the last post, we looked into the directed verification approach where, the test benches were typically dumb while the tests comprised of stimuli and monitors. The progress on verification was in linear relationship with the no. of tests developed and passing. There was no concept of functional coverage and even the usage of code coverage was limited. Apart from HDLs, programming languages like C & C++ continued to support the verification infrastructure. Managing the growing complexity and constant pressure to reduce the design schedule demanded an alternate approach for verification. This gave birth to a new breed of languages – HVLs (Hardware Verification Languages).

 

HVLs

 

The first one in this category was introduced by Verisity popularly known as ‘e’ language. The base of this language was AOP (Aspect Oriented Programming) and required a separate tool (Specman) in addition to the simulator. This language spear headed the entry of HVLs into Verification and was followed by ‘Vera’ that was based on OOP (Object Oriented Programming) promoted by Synopsys. Along with these two languages, SystemC tried to penetrate this domain with support from multiple EDA vendors but couldn’t really gain wide acceptance. The main idea promoted by all these languages was CRV (Constrained Random Verification). The philosophy was to empower the test bench with all features of drivers, monitors, checkers and a library of sequences/scenarios. The generation of tests was automated with the state space exploration guided by constraints and progress measured using functional coverage.

 

Methodologies

 

As adoption of these languages spread, the early adopters started building proprietary methodologies around them. To modularize development, BCLs (Base Class Libraries) were developed by each organization. Maintaining local libraries and continuously improving them while ensuring simulator compatibility was not a sustainable solution. The EDA vendors came forward with methodologies for each of these languages to resolve the above issue and standardize the usage of language. Verisity led the show with eRM (e Reuse Methodology) followed by RVM (Reference Verification Methodology) from Synopsys. These methodologies helped in putting together a process to move from block to chip level and across projects in an organized manner thereby laying the foundation for reuse. Though verification was progressing at a fast pace with these entrants, there were some inherent issues with these solutions that left the industry wanting for something more. The drawbacks include –

 

- Requirement for an additional tool license beyond simulator

- Efficiency of simulator took a toll because of passing the control back & forth to this additional tool

- These solutions had limited portability across simulators

- As reusability picked up, finding VIPs based on the HVL was difficult

- Hardware accelerators started picking up and these HVL couldn’t compliment it completely

- Ramp up time for engineers moving across organizations was high

 

System Verilog

 

To move to the next level of standardization, Accellera decided to improve on Verilog instead of driving e or Vera as industry standard. This led to the birth of System Verilog which proved to be a game changer in multiple respects. The primary motivation behind driving SV was to have a common language for design & verification to address the issues with other HVLs. Initial thrust to System Verilog came in from Synopsys by declaring Vera as open source and extending its contribution to definition of System Verilog for verification. Further Synopsys in association with ARM moved RVM to VMM (Verification Methodology Manual) based on System Verilog providing a framework for early adopters. With IEEE recognizing SV as a standard (1800) in 2005 the acceptance rate increased further. By this time Cadence acquired Verisity after its quest of promoting SystemC as a verification language. eRM was transformed to URM (Universal Reuse Methodology) that supported e, SystemC and System Verilog. This was followed by Mentor proposing AVM (Advanced Verification Methodology) supporting System Verilog & SystemC.  Though System Verilog settled the dust by claiming maximum footprint across organizations, availability of multiple methodologies introduced inertia to industry wide reusability. The major issues faced include –

 

- Learning a new methodology almost every 18 months

- The methodologies had limited portability across simulators

- Verification env developed using VIP from 1 vendor not easily portable to another

- Teams confused in terms of road maps for these methodologies based on industry adoption

 

Road to UVM

 

To tone down this problem, Mentor and Cadence merged their methodologies and came up with OVM (Open Verification Methodology) while Synopsys continued to stick to VMM. Though the problem was reduced, still there was a need for a common methodology and Accellera took the initiative to develop one. UVM (Universal Verification Methodology) largely based on OVM and deriving featured from VMM was finally introduced. While IEEE recognized ‘e’ as an standard (1647) in 2011, it was already too late. Functional coverage, assertion coverage and code coverage all joined together to provide the quantitative metrics to answer ‘are we done’ giving rise to CDV (Coverage Driven Verification).

 

Suggested Reading - Standards War

Evolution of the test bench - Part 1

Nothing is permanent except change and need constantly guides innovation. Taking a holistic view with reference to a theme throws light on the evolution of the subject. In a pursuit to double the transistors periodically, the design representation has experienced a shift from transistors  à gates à RTL and now to synthesizable models. As a by-product of this evolution, ensuring functional correctness became an ever growing unbounded problem. Test bench is the core of verification and has witnessed radical changes to circumvent this issue.

 

While the initial traces of the first test bench is hard to find, the formal test benches entered the scene with the advent of HDLs. These test benches were directed in nature, developed using Verilog/VHDL and mostly dumb. The simulations were completely steered by the tests i.e. the stimuli and checker mostly resided inside the tests. Soon variants of this scheme came wherein the HDLs were coupled with other programming languages like C/C++ or scripting languages like perl & tcl.  Typical characteristics of that period were, stretched process node life, multiple re-spins a norm, elongated product life cycle and relatively less TTM pressure.  For most part of the 90’s these test benches facilitated verification and were developed and maintained by the designers themselves. As design complexity increased, there was a need for independent pair of eyes to verify the code. This need launched the verification team into the ASIC group! Directed verification test suite soon became a formal deliverable with no. of tests defining the progress and coverage. After sustaining for almost a decade, this approach struggled to keep pace with the ramifications in the design space. The prime challenges that teams started facing include –

 

- The progress was mostly linear and directly proportional to the complexity i.e. no. of tests to be developed

- The tests were strictly written wrt clock period and slight change in design would lead to lot of rework

- Maintenance of the test suite for changes in the architecture/protocol was manual & quite time consuming

- Poor portability & reusability across projects or different versions of the same architecture

- High dependency on the engineers developing the tests in absence of a standard flow/methodology

- Corner case scenarios limited by the experience and imagination of the test plan developer

- Absence of a feedback to confirm that a test written for a specific feature really exercised the feature correctly

 

Though burdened with a list of issues, this approach still continues to find its remnants with legacy code.

 

In the last decade, SoC designs picked up and directed verification again came to the fore front. With processor(s) on chip, integration verification of the system is achieved mainly with directed tests developed in C/C++/ASM targeting the processor.  Such an approach is required at SoC level because –

 

- The scenario should run on the SoC using the processor(s) on chip

- Debugging a directed test case is easier given the prolonged simulation time at SoC level
- The focus in on integration verification wherein test plan is relatively straight forward
- Constraints required for CRV needs to be strict at SoC vs block level and fine tuning them would involve a lot of debugging iterations which is costly at SoC level

 

While the above points justify the need for a directed approach to verify SoC, the challenges start unfolding once the team surpass the basic connectivity and integration tests. Developing scenarios that mimic the use-cases, concurrence behaviour, performance and power monitoring is an intricate task. Answers to this problem are evolving and once widely accepted they will complement the SoC directed verification approach to further evolve into a defined methodology.

 

Directed verification approach isn't dead! It has lived since the start of verification and the Keep It Simple Silly principle would continue to drive its existence for years to come. In the next part, we check out the evolution of CRV, its related HVLs and methodologies.

 

If you enjoyed reading this post, you would also appreciate the following –

Recap from the PAST - the last decade!

Living the PRESENT - the current decade!

Predictions for future - The next decade!

 

Wish you a Happy and Prosperous 2013!!!

 

KEYWORD - HISTORY

Verification claims 70% of the chip design schedule!

Human psychology points to the fact that constant repetition of any statement registers the same into sub-conscious mind and we start believing into it. The statement, “Verification claims 70% of the schedule” has been floating around in articles, keynotes and discussions for almost 2 decades so much that even in absence of any data validating it, we believed it as a fact for a long time now. However, the progress in verification domain indicate that this number might actually by a "FACT".

20 years back, the designs were few K gates and the design team verified the RTL themselves. The test benches and tests were all developed in HDLs and sophisticated verification environment was not even part of the discussions. It was assumed that the verification accounted for roughly 50% of the effort.

Since then, the design complexity has grown exponentially and state of the art test benches with lot of metrics have pre empted legacy verification. Instead of designers, a team of verification engineers is deployed on each project to overcome the cumbersome task. Verification still continues to be an endless task demanding aggressive adoption of new techniques quite frequently.

A quick glance at the task list of verification team shows following items –

- Development of metric driven verification plan based on the specifications.

- Development of HVL+Methodology based constrained random test benches.

- Development of directed test benches for verifying processor integration in SoC.

- Power aware simulations.

- Analog mixed signal simulations.

- Debugging failures and regressing the design.

- Add tests to meet coverage goals (code, functional & assertions).

- Formal verification.

- Emulation/Hardware acceleration to speed up the turnaround time.

- Performance testing and usecases.

- Gate level simulations with different corners.

- Test vector development for post silicon validation.

The above list doesn’t include modeling for virtual platforms as it is still in early adopter stage. Along with the verification team, significant quanta of cycles are added by the design team towards debugging. If we try to quantify the CPU cycles required for verification on any project, the figures would easily over shadow any other task of the ASIC design cycle.

Excerpts from the Wilson Research study (commissioned by Mentor) indicate interesting data (approximated) –

- The industry adoption of code coverage has increased to 72 percent by 2010.

- The industry adoption of assertions had increased to 72 percent by 2010.

- Functional coverage adoption grew from 40% to 72% from 2007 to 2010.

- Constrained-random simulation techniques grew from 41% in 2007 to 69% in 2010.

- The industry adoption of formal property checking has increased by 53% from 2007 to 2010.

- Adoption of HW assisted acceleration/emulation increased by 75% from 2007 to 2010.

- Mean time a designer spends in verification has increased from an average of 46% in 2007 to 50% in 2010.

- Average verification team size grew by a whopping 58% during this period.

- 52% of chip failures were still due to functional problems.

- 66% of projects conitnue to be behind schedule. 45% of chips require two silicon passes and 25% require more than two passes.

While the biggies of the EDA industry are evolving the tools incessantly, a brigade of startups has surfaced with each trying to check this exorbitant problem of verification. The solutions are attacking the problem from multiple perspectives. Some of them are trying to shorten the regressions cycle, some moving the task from engineers to tools, some providing data mining while others providing guidance to reduce the overall efforts.

The semiconductor industry is continuously defining ways to control the volume of verification not only by adding new tools or techniques but redefining the ecosystem and collaborating at various levels. The steep rise in the usage of IPs (e.g. ARM’s market valuation reaching $12 billion, and Semico reporting the third-party IP market grew by close to 22 percent) and VIPs (read posts 1, 2, 3) is a clear indicative of this fact.

So much has been added to the arsenal of verification teams and their ownership in the ASIC design cycle that one can safely assume the verification efforts having moved from 50% in early 90s to 70% now. And since the process is still ON, it would be interesting to see if this magic figure of 70% still persist or moves up further!!!

Verification IP : Changing landscape - Part 1

For decades, EDA industry has been working out options to improve their offerings and ensure silicon success for the semiconductor industry. A few decades back, while the EDA giants were unknown, design automation was exercised individually in every organization developing a product. Gradually these tools moved out of the design houses and the ‘make vs buy’ decision carved a new league with EDA front runners. Talking specifically about verification, while the simulation tools were procured from outside, the in house CAD groups were still required to develop a flow for automation, self checking, regression management and data analysis. In the last decade, all of this came up as a package from EDA vendors thereby further squeezing the CAD teams in the design houses. So, what next?  Well, the recent acquisitions in this space i.e. Cadence acquiring Denali, Synopsys acquiring nSys and ExpertIO indicate where we are heading. Initially the VIP providers were able to sustain with licensing and basic verification support model but now the pressure is surmounting as VIPs get commoditized. The VIP only vendors will have to identify themselves either with the EDA vendors or with Design service providers wherein the VIPs complement other offerings. Before moving ahead let’s discuss what is a VIP?

What is a VIP?

A Verification IP is a standalone ‘plug and play’ verification component that enables the verification engineer in verifying the relevant DUT (design under test) module at block, sub system and SoC level. Based on the need, the VIP can act as a BFM to drive DUT signals or MONITOR the signals and VALIDATE them for correctness and data integrity. It may have a set of protocol CHECKERS and test scenarios to confirm compliance with the standards (if any) or COVER groups identifying corner cases and test completeness. VIPs are developed using HDLs or HVLs with standard methodology or as a set of assertions. It needs to have enough APIs providing flexibility for modifying the internal units as per DUT. User should be able to extend the available monitors, scoreboard and checker hooks while developing a verification environment around this VIP. Ease of developing scenarios at different levels using available functions and sequences is important in minimizing the verification turn around cycle. Quick integration with other tools like coverage, simulate, debug and transaction analysis is critical in successfully deploying the VIP.  Finally the most crucial is the support provided by the VIP vendor to the user in responding to issues and upgrading the VIP as the standards evolve.

The common VIPs available include –

- MIPI protocols like DSI, CSI, HSI, SlimBus, Unipro, DigRF & RFFE.

- Bus protocols like AXI, AHB, APB, OCP & AMBA4.

- Interfaces like PCIexpress, USB2.0, USB3.0, Interlaken, RapidIO, JTAG, CAN, I2C, I2S, UART & SPI.

- Memory models & protocol checkers for SD/SDIO, SATA, SAS, ATAPI, DDR2/DDR3, LPDDR etc.

Companies providing the above VIPs fall into one of the below categories -

- EDA vendors

- VIP only providers (some of them offering IPs also)

- Design services companies

Although, there is a lot of IP development still continuing with the design houses, the motivation to procure VIP from outside is much higher for obvious reasons. 

In the next post we will discuss the challenges for new entrants that raise barriers to entry and role of Soc Integrators, EDA companies and design services organizations in this changing landscape.

Related posts -
Verification IP : Changing landscape - Part 2
Choosing the right VIP

 

2011 : Bidding Adieu

The year 2011 had its own set of twists and turns. A plethora of applications riding over interesting set of electronic gadgets became part of our lives. Consumption of electronics devices continued to rise and market dynamics were unpredictable more than ever. New process nodes stabilized thereby promising to shrink designs  and reduce power consumption further. The tsunami added to the woes but Japan defied the odds and showcased its ability to bounce back quickly. The sad demise of Steve Jobs was a big loss to the electronics world. Amongst all of this we experienced that market window for products is constantly tightening which means the turnaround time for designs needs to reduce incessantly. Since verification claims most of the cycles in ASIC design, the community took one step further in multiple areas to bridge this gap. Some of the highlights include -

- UVM : Final release happened with quick adoption.
- Steps taken to bring together the differences in UPF & CPF.
- Tools for generating assertions automatically adopted widely.
- Cloud computing discussions moved from closed rooms to open forums.
- Hardware acceleration jumped to mainstream.

 

Some interesting facts also came up. While we keep talking about next generation of verification technologies, the primitive techniques continue to dominate in parallel. For example, at ‘Siddhakarana’ the most popular post was “Gate Level Simulations” with more than thousand hits and still getting visitors on daily basis. This essentially means there are areas that need attention before they become a bottleneck in getting the designs shipped faster.

On this note, I thank you for your valuable suggestions and readership throughout 2011. I look forward for the same in 2012.

Wish you and your family "HAPPY & PROSPEROUS 2012".

:)

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

2010 : Bidding Adieu

2010 has been an eventful year on all fronts for everyone.
After experiencing a worse downturn, the semiconductor industry witnessed close to +30% YoY growth in 2010. Customers, revenues, profits and jobs kept adding up month after month.

The verification space saw a lot of activity on multiple fronts.
A few highlights include -
- IEEE 1800-2009, a revision to existing System verilog standard was completed.
- UVM : Early Adopter version was released.
- Enhancements made to UPF IEEE standard.
- A lot of other (coverage, IP, AMS) standardization efforts progressed.
- ESL picked up after much delay.
- Formal verification complemented simulations more than ever.
- FPGA verification came up as hot topic.
.....
- sid'dha-karana, a blog focused on verification kicked off.
.....

On a closing note for the year, a few personal recommendations from 2010 -

MUST READ -

Evolution of design methodology - Part I

Evolution of design methodology - Part II

MUST WATCH -

Sand to silicon : the making of a chip

At this juncture I would like to thank you for your valuable feedback, support  and readership. I look forward for the same in 2011.

Wish you and your family "HAPPY & PROSPEROUS 2011".

:)

EDA360 Realizations : Verification perspective

EDA360 is all about bringing a CHANGE. A change in perception, planning and execution to bring about a change in the 3Ps that limit our Product. The approach widens the horizons and opens up new avenues for all the stakeholders associated with product development. With involvement of verification team at all levels in the ASIC design cycle, this new theory affects a verification engineer in multiple ways.

-    Movement to a higher abstraction layer demands verification at a new layer. The verification plan now needs to address verification of models at this layer and define an approach to reuse the efforts at following layers. The Verification IP should be portable so as to verify the IP model stand alone and when integrated into an SOC. The verification environment at this level must provide enough hooks to assist in power, performance what-if analysis. It should also have enough APIs to simulate the embedded drivers on this platform.

-   Verification IP needs to become an integral part of IP deliverable. Apart from providing required constraint random infra structure, the VIP should also include a protocol compliance suite to exercise the IP with these vectors at different levels. It must also ensure that the drivers coming as part of the IP stack can be simulated with required modification to the verification environment. Extrapolate this to sub-system or SOC level and we get a list of expectations from the verification environment at different stages of the design integration.

-    With analog claiming more area on the chip, there is a need to define a methodology to verify analog modules. Abstract layers modeling analog blocks needs to be added to ascertain their presence at all levels of design cycle. Verification of these models at different levels, defining a reusable constraint random verification flow, planning a metric driven verification approach, seamless integration verification of analog and digital blocks are major challenges to be taken care for mixed signal designs.

-    Simulating real time scenarios is needed to ensure system level functionality. Hardware acceleration is desired to drive real time data into the design before tape out while reducing simulation turn-around time. Application driven approach requires software to be developed in parallel with the hardware. To test this software early enough Virtual prototyping and emulation are potential solutions. Verification team’s involvement is required at all these levels to reuse the infrastructure and recreating failing scenarios for detailed design debug.

-    Advancement in Verification platforms has been exorbitant. Apart from coverage driven methodology, dashboards (with different views) are available to effectively manage the resources (engineers, hardware and licenses) while tracking the progress. Deploying similar flows to Mixed signal verification, Embedded software verification and System level tracking would help a lot in bringing the teams contributing to the product development together.

EDA360 preaches elimination of redundant verification to reduce cost and improve productivity, profitability and predictability. It proposes sharing the innovation in verification with other areas of the system development. A complete holistic verification is demanded that will eventually lead to more work, more jobs and more $$$ for the verification engineer J   

Related posts -
EDA360 : Realizing what it is?
EDA360 : Realizing the Realizations

Predictions for future - The next decade!

Constraints & limitations with available resources lead to innovative thinking... to inventions... to evolution...

As we step into the next decade, the verification fraternity is all set to reap the benefits of the investments made in the present decade. Listed below are technologies (in no specific order) that would define the future course of verification. [Watch out for details on each one of them in future posts.]

1. UVM - The UVM standard committee is all set to roll out the UVM1.0 standard. This methodology sets up a new base for reusability, coverage driven verification, supporting different HVLs and curtailing the confusion of (which one's better).

2. Formal verification - Faster simulation, exhaustive scenario generation, handling complexity, you name it and formal [hai na] is there for it. Improved engines shall handle larger database and provide a defined way of moving from unit to chip level with formal. The APP based approach further brings in the required focus & results.

3. Hardware accelerators - Running real time applications at pre-silicon database with faster turnaround is the need of hour. Hardware accelerators would be able to suffice this demand enabling all domains to exercise real life data before moving to back end implementation.

4. Unified coverage model - Slowly creeping into main stream the work group is making progress to unify the coverage data base across different sources and simulators thereby improving reusability across many levels.

5. AMS - With analog claiming bigger chunk of the mixed signal die, verification is not limited to address correct integration only, instead measurement of analog performance while harmonics from digital operates in tandem would be more prevalent.

6. Low power designs - Orientation to go GREEN brings in new techniques to curb power. While verification ensures correct implementation it shall move a level up & assist in estimating power figures with different application scenarios (use cases) thereby defining optimum system architecture.

7. Electronic System Level (ESL) - Dealing with complexity is easier at higher abstraction levels. System modeling is gaining traction and so is system verification. Standards like TLM2.0 opened up gates for support of transaction modeling in different languages assisting in both design & verification.

8. Cloud computing - Problems associated with verification aren't only in developing test benches, debugging or reusing. Efficient management of compute infra structure to get maximum return on investments made in hardware & software is equally important. Cloud computing defines a new approach to deal with this chronic techno-business problem.

9. Virtual platforms - A complete platform that engages all players of the eco system at the same time i.e. application developers, embedded designers, ASIC design, verification & implementation teams to aid faster time to market will be the key to next generation designs. Verification holds the key to defining & developing such platforms.

10. Courses - With so much going in Verification, don't be surprised if it emerges as a separate stream for specialization in masters degree and adding more PHDs in this domain :)

The above list is what I forsee as the key to NEXT GEN verification.

If you have any other exciting stuff that should unfold in next decade do drop in your comments.

Previous -
'Recap from the past - the last decade'
'Living the present - the current decade'

Living the PRESENT - the current decade!

The present decade (2001-2010) witnessed the metamorphosis of verification domain from adoloscence to maturity. A lot of the initiatives from the last decade paid off well to scale verification along with the ASIC designs while a lot of new investments were made keeping the next decade in mind. Some verification features that made their mark in this decade include -

1. System Verilog - touted as a one stop solution for HDL+HVL, addressing the limitation of the designers using HDLs (Verilog/ VHDL) and the verification engineers debating on HVLs (e/Vera). An extension of Verilog 2005 and largely based on OpenVera language, System Verilog became a darling of everyone from the Semiconductors as well as the EDA companies.

2. Standardization of HVLs e & SV - System Verilog was adopted as IEEE Standard 1800-2005 and then merged with the Verilog IEEE 1394-2005, leading to IEEE Standard 1800-2009. 'e' language promoted by Verisity and bought by Cadence went ahead getting standardized as IEEE 1647-2006. 

3. CDV - Code coverage stagnated as a baseline for measuring verification progress & completeness. Functional coverage supported by the HVLs was able to put forward a different dimension and widely accepted. Assertion coverage though promising wasn't able to spread its wings wide enough, partly, since it was scenario focussed and partly because of ownership issues between design & verification teams. Even test planning evolved a lot with many tools now aiding in developing a robust test plan by keeping a track of architecture document and extending means for defining comprehensive coverage goals upfront.

4. Reusability - A jargon that still makes news every now & then. Design complexity jumping new heights and time to market panic lead to evolution of IP designs and reusability. With design, verification IPs also defined their market quite strongly. Methodologies (eRM & RVM) helped in packaging the verification environment so as to make it portable from module to chip level and between programs. SV evolution brought in OVM & VMM complementing eRM & RVM respectively. [Note - OVM is a mix of eRM & AVM]. Finally, this decade will commence with standardization of methodology - UVM.

5. AMS - The intricacies of Analog always kept it behind the digital world in terms advancements in process technologies or other methodologies. Product demands from various domains lead to single chip (packaging) and later single die solutions. Since analog & digital designers were always alien to each other these integrated designs demanded verification. AMS simulations addressed this space with various schemes like - Gate level representation of digital & transistor level representation of analog, Gate level or RTL representation of digital & behavioral modeling of the analog etc.

6. Formal verification - Directed verification opened gates to constrained random verification (CRV) where unforseen scenario generation was the focus. Given time & compute resource limitations CRV struggled to reach all possible points in the designs in a defined time. Formal approach proposes to resolve these limitations. However, slow advancement on the simulators limited the adoption of this methodology for most part of the decade.

7. Low power verification - Area and performance had been defining ASIC designs until power became an important measure. Innovative design techniques reduced power consumption with an overhead logic. EDA tools capable of verifying power aware designs - MVSIM & MVRC from Archpro (later acquired by Synopsys) and Cadence IUS & Conformal LP did quite well to address this issue. UPF & CPF emerged as two power formats that rushed to address representation of power aware designs. [UPF - IEEE 1801-2009].
 
8. Hardware accelerators - More gates, big designs, long simulation run time = bottleneck to tapeout in time. Next generation of hardware accelarators paved way for reducing the simulation turn around time. These boxes soon took shape of a complete platform for verification of the whole system and further advanced to help simulate some real time data into the designs before tapeout with much ease.

9. HW SW co-verification - With design focus shifting from the ASIC to SOC, system design & modelling became all the more important. Software testing became the next chokepoint for time to market. A well defined platform where software design & testing could start in parallel to the ASIC design came forefront. Better HW SW partioning, performance checks, system design issues etc all were well addressed with this platform.

10. Courses in verification - VLSI course became more prominent and adopted in almost all electrical & electronics courses. Late in the decade a need for focussed verification courses took centre stage. Many institutes delivering these courses addressed the need for a competent verification work force.

Next -
'Predictions for future - the next decade!'

Previous -
'Recap from the past - the last decade!'

Recap from the PAST - the last decade!

Verification has evolved a lot in the past 2 decades and there is more to come as we step in the next decade. This 3 part series lists out the highlights of the past, the present & predictions for the future.

Nineties had a crucial role in justifying verification to get a prominent berth in ASIC design cycles, ASIC schedules and ASIC teams. It was during this decade when verification commenced with full pace. Following are some milestones that helped achieve this. Some of them peaked & stagnated while others blossomed to scale even bigger in the following decade.

1. Standardization of HDLs and ownership of revised versions.
- VERILOG - IEEE 1364-1995 [Latest version 1364-2001, 1364-2005]
- VHDL - IEEE 1076-1987 [Latest version 1076-1993, 1076-2002]
- (OVI) Open Verilog International and VHDL International merged in 2000 to form Accellera.

2. The Simulator war.  Following are the ones that received wide acceptance -

- Verilog XL [Interpreter]
- VCS (Verilog compiled simulator) [Compiler]
- Modelsim

3. Directed verification - With low gate count, HDLs/C based verification was the softest path to tapeout. The test plans and test benches were primitive enough targeting only the features to be verified with no scalability & reusability.

4. Defined verification teams - With increasing design size (gate count) and  complexity there was a need to parallelize the effort of RTL with verification. Other factors like, having second pair of eyes to look into code and verification comprising 70% of ASIC schedule etc. ignited the look-out for dedicated verification teams to tame the bugs in the design.

5. Automation of verification infrastructure - The increasing complexity and no. of tests were a challenge to manage. Scripting took the front seat to automate the whole process of verification which includes, running tests in batch mode, checking for failures, regressions etc.  Typically every organization had a script called runsim as a initial step to get the flow working.

6. Constrained random verification - With design advancements poised to follow Moore's law, directed verification saturated and there was a need for controlled aka constrained random stimuli to uncover unforseen bugs. C++ came up to rescue followed by hardware verification languages like Vera & e.

7. Code coverage - Increasing verification complexity lead to the basic but intricate question - 'are we done'? Covering the RTL code with the given set of stimuli has been one of the important milestone defining closure since then.

8. Gate level simulations - With equivalence checkers still stabilizing, setting up gate level simulations flow was crucial to ensure the synthesized netlist was sane enough to go for a tapeout.

9. Hardware accelarators - The concept of FPGA prototyping was replicated to develop boxes that could synthesize the design and run them 10x or faster to reduce the test case turn around from days to hours.

10. ASIC design as part of the curriculum was introduced at institutes in India offering Micro-electronics/VLSI as a subject in graduation and as a complete stream for post graduation. This helped source engineers to meet the demand for the semiconductor industry.

Next -
'Living the PRESENT - the current decade!'
'Predictions for future - the next decade!'

What's in here?

Welcome to my blog which unveils the exciting world of verification in words!!!

sid'dha-karana aka Verification will explore the 'kal, aaj aur kal of verification' - literally translates to 'yesterday, today & tommorow of verification (context matters! the word 'kal' changes meaning with context of time).

This blog is primarily targeted to ASIC/SOC & related verification and will share -

past      - legacy stuff...

present  - insight into what's going around...

future    - some predictions and trends for future...

The hindi lingo above reflects my mother tongue (Hindi) and signifies that, the discussions though will cover verification irrespective of geography in general but will still have some focus on India in particular.

The breadth of the topics expected to be covered are -

- Verification basics

- Verification flow

- Verification languages & methodologies

- General about semiconductor industry

Apart from this I plan to spice it up with "Experiences", "Interview Questions" and ofcourse excerpts from discussions with the who's who from verification domain in our industry.

The above are guidelines to start off with. We can do a makeover as & when demanded, after all the only thing constant is change :)

Enjoy reading & continuing your experiments with BUG HUNTING!

Do drop in line of what you think about the blog to siddhakarana@gmail.com

Yours Truly,

Gaurav Jalan