Assertions are already used in pre-silicon verification and can help halve debug time. So why not synthesize assertions into real logic gates in the final silicon, to catch those unexpected bugs that make validation so much harder? Here’s how.
As the complexity of SoCs continues to grow, designing and making a fully functional system is becoming increasingly difficult. Despite improvements in pre-silicon verification practices and technologies, bugs continue to escape into silicon. As a result, an increasing amount of verification is now done on actual silicon as part of post-silicon validation. [One leading semiconductor company recently reported that the effort associated with post-silicon validation efforts increased from 17% of the project’s combined design, verification and validation effort in 2002 to 25% in 2005. By 2009, the post-silicon validation effort made up 50% of the overall project effort. ]
Performing verification on real silicon introduces new challenges. On the one hand, real silicon offers great execution speed, which enables long test runs that reach deep into the design’s state-space. On the other hand, real silicon lacks both good controllability and observability, which serve an important role in pre-silicon verification. Assertions can address both the controllability and observability challenges associated with pre-silicon verification, for example in RTL simulation. There is emerging interest in using assertions to address these challenges in post-silicon validation as well.
Controllability and observability
Before we explore how this works, we need to define controllability and observability.
Controllability refers to the ability to activate an embedded finite state machine, structure, or stimulated logic element within a design by stimulating various input ports. While it is possible to achieve high controllability of the design’s input ports, test stimuli may not be able to achieve much controllability of an internal structure within the design.
Observability refers to the ability to observe the effects of a specific internal finite state machine, structure, or stimulated logic element. For example, a testbench generally has limited observability if it can only observe the external ports of the design model.
To identify a design error, the following conditions must occur:
1. The testbench must generate the proper input stimulus to activate a design error.
2. That input stimulus must propagate all effects resulting from the design error to an observable output port.
It is possible to set up a condition where the input stimulus activates a design error that does not propagate to an observable output port. In these cases, the first condition applies; however, the second condition is absent, as illustrated in Figure 1.
Poor observability and controllability misses bugs (Source: Mentor Graphics – click image to enlarge)
Using assertions to improve controllability and observability
Embedding assertions in the RTL model increases observability, because the simulation testbench no longer depends on generating input stimulus to propagate a design error to an observable output port. The approach means that improper or unexpected behavior can be caught closer to the source of the design error, in terms of both time and location. It also cuts debugging time by up to 50%, according to case studies. In addition, embedded assertions can identify complex bugs in the design that never propagated to the output ports due to limited simulation run times, and therefore, were never detected by the simulation testbench.
If assertions can help you overcome problems with testbench observability and controllability in pre-silicon verification, why not also use them in post-silicon validation? Coverage properties, which are a form of assertion looking for desirable behavior, can be used to identify controllability issues resulting from either a poor simulation testbench or a poor test that is applied to the actual silicon during post-silicon validation.
The theory and process of synthesizing efficient hardware checkers from SystemVerilog or PSL assertions is fairly mature and is well covered in the book Generating Hardware Assertion Checkers: For Hardware Verification, Emulation, Post-Fabrication Debugging and On-Line Monitoring.
In practice, though, only a few of the more advanced processor and SoC companies actually include hardware assertions as part of their post-silicon validation strategy. Aside from the process of synthesizing hardware assertions, there are other issues that must be addressed to use assertions effectively during post-silicon validation. These include:
- Identifying a practical minimum set of assertions that realistically provide improved observability during post-silicon validation.
- Obtaining (and sharing) the pass-fail status of the embedded hardware assertions without significantly increasing the gate count for the design.
- Providing a standard set of enable/disable controls across multiple hardware assertions.
One problem identified during a workshop on post-silicon debugging at DAC 2012 dealt with the number of proprietary methods currently being used to address the issues above. Ultimately, industry standards and recommended best practices must emerge to foster broader industry adoption of synthesizing hardware assertions.
For example, the challenge in addressing the first issue is to identify a useful set of assertions for areas of the design that might contain a bug. This is not trivial since, by definition, the bugs you want to find are the ones you didn’t think of. At the same time, though, no one wants to waste silicon real estate by synthesizing hardware assertions that provide little value.
One way some companies are addressing this problem is to implement a reconfigurable fabric into the SoC, which enables assertion checkers and coverage monitors to be programmed as needed. With this approach, the post-silicon validation engineer can change the observability focus during the debugging stage without committing to a fixed set of assertions identified prior to synthesis.
For the second issue, that is, obtaining the pass-fail status from the assertion, various techniques are currently being used, ranging from:
- Implementing an embedded assertion processor within the SoC that is responsible for managing the assertion status across multiple checkers within the design.
- Reusing test scan channels (e.g., JTAG) to dump the assertions’ status and debugging information.
For the third issue, that is, providing a standard set of enable/disable controls across multiple hardware assertions, the scan channel can also be used to control reconfiguration and to load the assertion bitstream data into the programmable fabric.
Using hardware assertions during post-silicon validation
Hardware assertions and coverage properties are not used solely to identify errors and measure coverage. In fact, they are often used to trigger embedded trace buffers that serve the function of an embedded logic analyzer. For example, a coverage property could be created to identify an interesting event within a design. Once that coverage property triggers, an internal trace buffer could be enabled to capture a set of data from an internal bus. The captured data could then be scanned out for further analysis. Hence, hardware assertions and coverage properties can be an effective mechanism to trigger other internal debugging logic.
Synthesizing hardware assertions and coverage properties into emulation is common practice today. It is supported by most EDA vendors, and results in improved observability and reduced debugging time. Synthesizing assertions into silicon to improve post-silicon validation is currently only practiced by advanced processor and SoC companies. However, as the complexity of designs grows, we should expect more interest in advanced techniques to improve post-silicon debugging. Establishing industry standards for hardware assertion synthesis, managing on-chip assertion status, and controlling hardware assertions during post-silicon validation will be necessary to ensure broad industry adoption.
 Amir Nahir, DAC Workshop on Post-Silicon Debug: Technologies, Methodologies, and Best-Practices, 2012 Design Automation Conference.
 Tim Cheng: “The Changing Roles of Verification and Test in the Late-Silicon Era,” 2009 PROFIT.
 Marc Boul , Zeljko Zilic: Generating Hardware Assertion Checkers: For Hardware Verification, Emulation, Post-Fabrication Debugging and On-Line Monitoring, Springer Publishing Company, Incorporated, 2008.
 José Augusto Miranda Nacif, Flávio Miana de Paula, Harry Foster, Claudionor José Nunes Coelho Jr., Antônio Otávio Fernandes: The Chip is Ready. Am I done? On-chip Verification Using Assertion Processors. VLSI-SOC 2003.
 Ming Gao, Kwang-Ting Cheng: A case study of Time-Multiplexed Assertion Checking for Post-Silicon Debugging. IEEE HLDVT 2010.
Harry Foster is chief scientist for Mentor Graphics’ Design Verification Technology Division. He holds multiple patents in verification and has co-authored seven books on verification, including the 2008 Springer book Creating Assertion-Based IP. Foster was the 2006 recipient of the Accellera Technical Excellence Award for his contributions to developing industry standards, and was the original creator of the Accellera Open Verification Library (OVL) assertion standard.