Dependable Verification Is The Foundation ICs Require

As our world becomes increasingly high-tech, it is easy to lose sight of the little things that make all of our fancy gadgets achieve optimal performance. The one thread that enables you to get all of the benefits of a new laptop, tablet, smartphone, or your automobile’s digital dashboard and connects the components that ensure best performance is the integrated circuit (IC).

For as breathtaking as today’s new technology can be, it is of little use without reliable ICs. The main component of any computing device, each IC has to be perfect or the device can be rendered inoperable. Think of the phrase, “a bad apple ruins the whole batch.” This sums up how important each IC is to the operation of a device.

With the current global chip shortage showing no signs of improving, today’s ICs need to be even more accurate and precise. To ensure ICs are production ready, coverage and assertion tools are vital. Dependable verification tools ensure chip accuracy and can diagnose any current or potential problems. As the size and complexity of ICs grow, it is even more important to use available, proven verification tools.

New chip architectures lack the test quality and coverage data from previous projects. They may, however, have intricate bugs lurking. Execution and debug cycles can have a significant impact on product resources and schedules.

Coverage and assertion tools are broadly leveraged when simulating IP and other constituent blocks that make up a larger system-on-chip (SoC). Each block can be verified in isolation, providing confidence at the block level. But keep in mind a large application-specific integrated circuit (ASIC) or SoC employs hundreds of these IP blocks. Their interaction must be thoroughly tested to make sure they work well together.

The challenge is that it is impractical to perform comprehensive system-level verification in simulation given the amount of time it would take to complete. System-level tests can run for millions of clock cycles, putting them out of practical reach for simulation.

Emulators run many orders of magnitude faster than simulators, making them a natural fit for system-level verification. But that means the tools used in simulation must be easily re-used when moving to emulation. If that is not possible, then there will be a verification gap at the system level that will be difficult to close. This is a job that Siemens EDA’s Veloce Coverage app and Veloce Assertion app can handle.

Coverage: Are we there yet?

The only way to be confident that a new design has been thoroughly vetted is to track, in detail, what has been verified and what remains to be verified. That has been formalized in the concept of coverage. The aspects of the design that have and have not been covered make up the content of the Unified Coverage Database (UCDB) (figure 1).

Fig. 1: The Unified Coverage Database.

Different verification tools, like simulation and formal, record the items they have verified in the UCDB. The Veloce emulator can do this as well, but critical to productivity is the ability to ensure emulation effort is spent only on items that have not yet been verified to avoid duplication of effort. This means that coverage in emulation can have meaningful benefits to the verification productivity while ensuring the quality of the chip.

The platform can be used to target coverage at the SoC level while running software workloads or benchmarks to ensure the SoC architecture and microarchitecture features meet their specification. Run regressions, including stress tests (and negative testing), achieve coverage closure and refine the test suite that delivers the intended coverage in the least amount of time.

It is possible to accelerate validation of late-stage bug fixes and engineering change orders (ECOs) by adding the relevant code and functional coverage around the intended regions and executing the streamlined test suite. As a result, this builds up the quality for silicon-readiness.

Assertions: Watching for bad behavior

Assertions are a means of watching what is going on during verification and flagging events of interest. While one can flag any event, assertions are often used to raise a red flag if something incorrect happens. This can have a couple of productivity benefits.

First, it can help with a very fast and localized debug. Often, when an incorrect outcome appears in a full system-level application, some low-level event going wrong may be an early indicator. The challenge is that it may take tens of thousands of clock cycles before that low-level event shows up as a higher-level behavior. When trying to debug the error, it can be extremely valuable to have a low-level event on the record to quickly identify where to start looking for issues.

This is useful not just for verification engineers but also the design engineers who can embed these assertions in their code and expedite the debug process when presented with emulation logs and waveforms.

Second, assertions can reduce verification time if an event occurs that will make future results meaningless. If a long test detects an error early on, then it is nonsensical to keep the test running when the subsequent results will be invalid. Having an assertion that can prematurely end the test in this situation allows for faster issue resolution and can save valuable emulator time.

Coverage and assertions in emulation

The Veloce Coverage app and Veloce Assertion app play a central role in bringing coverage and the use of assertions up to the system-level verification that will be run on a Veloce emulator.

The Veloce Coverage app supports code coverage (statement, branch, toggle and finite-state machine) as well as functional coverage constructs (covergroup, coverpoint, bins, cross, etc.). Toggle coverage is supported at the gate level netlist as well. It is relevant when qualifying the stimulus to a region of the design in context to its output from a synthesis tool.

On any given run, the app allows the verification engineer to select whether to test the entire system or focus on one or more IP blocks. Those blocks will likely have been at least partially tested already during simulation. This allows Veloce to identify that in the UCDB and instrument the coverage that hasn’t been covered yet

The Veloce Coverage app provides the following options to define the coverage scope of the design by the user:

• Pass a cover file with regions of the design to cover or not cover
• Pass UCDBs from prior runs in simulation or emulation

The latter option (that includes assertions as well) can be particularly useful if prior coverage from simulation/emulation engines needs to be omitted from future compiles.

Assertions, meanwhile, can be included at the simulation level and then used as-is during emulation. All assertion types are supported by the Veloce Assertion app.

For ease of debug, the required set of assertions can be compiled into the design and then selectively enabled or disabled at runtime. This saves the compile time that would be necessary if the design had to be recompiled each time the new assertions are incorporated.

For ease-of-use flexibility, TCL and C-API interfaces are available to control enabling coverage and assertions at runtime.

All the coverage and assertion constructs are synthesized and mapped into the Veloce platform, providing an environment for the tests to run at full emulation speeds without impacting performance.

Plays well with other apps in all modes

Emulation can be performed in different ways to address unique challenges. Examples include simulation acceleration, virtual system-level emulation and in-circuit emulation (ICE). The Veloce Coverage app and Veloce Assertion app can be used regardless of the emulation verification use modes in effect. Using both the Veloce Coverage app and Veloce Deterministic app in an ICE environment allows coverage collection from complex real-world stimulus to exercise the design under test (DUT).

Both apps can also be used alongside other Veloce apps like the Veloce Power and Veloce Design-for Test (DFT) applications. In addition, the Veloce Coverage and Veloce Deterministic apps work with Veloce VirtuaLAB components that generate system-level traffic for stimulating the design. Together, these elements can be used to assemble a comprehensive digital twin of the design being tested, allowing a verification team to run a rich set of tests to ensure that even tough corner cases are analyzed.

Conclusion

The interoperability of the Veloce Coverage app and the Veloce Assertion app with other verification engines (simulation and formal) enables merging coverage collected by each engine and provides a cohesive coverage closure report and analysis flow. It enables the verification team and product-level management to make important decisions such as coverage closure sign-off, test quality analysis, and traceability from the specification to the design features and verification collateral. A unified coverage methodology is now a key requirement in the industry.