The Verification Checklist

Verification checklist

As complex as today’s systems on chip (SoCs) are, it’s simply not possible to go “by the seat of your pants” and hope for a project to complete successfully. You must be thorough and methodical in your approach. And, with verification taking an ever-increasing chunk out of the development time, much of the required discipline goes to making sure that all of the design work has been done correctly.

A time-tested means of making sure nothing is forgotten in any process is a checklist (see the figure). A verification checklist will help manage all of the details that must be attended to in an SoC of any significance. Even if we simply focus on the front-end process of generating and validating register-transfer-level (RTL) code in a digital design — without even considering the mind-numbing array of back-end verification steps — a structured approach is still important.

You need three basic things to ensure correct, robust RTL code:

• A well-articulated description of what the design is supposed to do;
• All of the tools and infrastructure for doing the testing; and
• A comprehensive plan for executing the tests.

The design spec itself may sound almost self-evident, but it must contain more information than simply what the designer needs to complete the design. Three particular elements that should be clearly spelled out for the verification team are:

• A thorough delineation of all of the modes of operation, and whether the modes are co-existing or mutually exclusive. This helps form the basis of a checkout that doesn’t miss any of the less obvious use cases, and it helps identify corner cases where different modes might be used at the same time. For example, is it possible that the target system is downloading a software update while a call is in progress and a reminder alarm is sounding?

• A designer might get started on a design with a loose description of how the design should behave in response to different inputs, but verification requires an exhaustive description of what the outputs should be for each set of inputs. This is probably available for outputs relevant to a given test, but what should happen on the outputs that aren’t relevant? What happens when modes conflict? Which mode takes precedence? These details not only provide for a complete test, but they also force the design team to consider these less-than-obvious situations, making the design more robust from the start.

• What key assertions are being placed into the design? What will various failures indicate? This is an area where designers and verification engineers effectively collaborate: the designer puts tests into the design, but the verification team needs to know how to interpret them.

When assembling the verification environment, you may be starting from scratch or you may inherit something that was originally built during the architectural exploration phase of the project. Either way, you’ll have work to do to build it out for design verification.

Key considerations are:

• How complete is your testbench? You need to provide stimulus for every part of the circuit, which may involve various data and traffic generators. Traffic generators need to be tuned to provide the kind of traffic expected in the target system. If the chip is being designed to handle traffic on a network intended for financial trading transactions, then testing with lots of YouTube videos probably won’t be helpful.
  
  In addition, do you have checkers in place for the assertions in the design? Do you have simulation vectors that provide acceptable coverage? Do you have transaction-level models (TLMs) for as-yet un-designed blocks in the system or for intellectual property (IP) being purchased?
• You will need a simulator to test digital logic.
• For systems that will execute software, you will want a virtual platform so that you can test out the software quickly without waiting for hardware.
• You need to have an emulation strategy lined up both for accelerating simulation and for taking the whole design and running it with real stimulus.
• You need to have a clear, clean interface between your simulation and emulation environments. This serves to allow the emulator to accelerate simulation selectively and for execution of software. In order to get acceptable performance, you want to be sure to have an efficient transaction-handling capability over a Standard Co-Emulation Modeling Interface (SCE-MI) interface.

Finally, the test plan has to include provisions for various different blocks that may coexist in the chip. Digital logic is typically the focus of the testing of an integrated chip since the behavior and characteristics of analog blocks are driven so much by back-end considerations and are typically tested separately. But that still leaves the following that must be considered:

• All of the digital logic blocks in all modes and legitimate combinations of modes;
• Clock domain crossings;
• Interfaces to analog blocks;
• Digital portions of mixed analog/digital blocks; and, of course,
• Software.

Bear in mind that as much work as it may take to complete the verification checklist, it only gets you from high-level design concept to RTL. Making sure the RTL code is implemented correctly and that the entire monolithic chunk of silicon provides all the desired functions at the desired speed for the desired power suggests another separate checklist for the back end.

But none of the backend portion will be correct if the front end has problems. Disciplined execution of front-end verification that addresses all of the items on the checklist will ensure that the back end gets the best possible chance for success by giving it a clean, thoroughly-tested starting point.