Semiconductor Design & Verification Articles

BootROM code is omnipresent in modern System-on-Chip (SoC) ASICs. While verification strategies for RTL are well established and widely practiced, ROM verification methodologies are less well-developed and not widely standardized. Some EDA vendors address ROM software verification by offering highly-integrated hardware/software co-simulation platforms at added costs. By applying standard RTL verification practices to BootROM, Intrinsix has developed a methodology that relies only on standard RTL verification tool chains.

The Need to Verify Embedded BootROM

Once powered up and out of reset, an embedded processor starts fetching code at a predefined boot address. The boot code is usually static, must survive power off, and must be available immediately after the processor exits reset. Consequently, it must reside in non-volatile memory – usually on-chip read-only memory (ROM).

The use of modern verification methodologies is standard practice for RTL design flows. Before committing an ASIC to fabrication, verification tool chains, standards, and processes are employed to verify that the RTL and synthesized gates meet the expected design specification and are free of functional bugs. But what about verification of the boot software embedded in ROM?

The risk of bugs in BootROM could be reduced by using non-volatile, on-chip reprogrammable memories, but these memories are much more expensive (area, power, license fees) when compared to ROM. Moreover, supporting a flexible scheme to remotely update these programmable ROMs in the field adds significant complexity and cost. Consequently, almost all SoC ASICs have some embedded processor code that resides in ROM. At a minimum, this code boots the CPU after a power-on reset, but in practice, the process is more complicated.

Figure 1: BootROM process flow diagram illustrates complex control flow showing features that are extracted and used as coverpoints in the testbench.

As the complexity of ASIC systems continues to increase, so does the complexity of the boot procedure. Market demands to support features like secure boot, code authentication, and encryption/decryption drive up the complexity of embedded ROM code, increasing its size and cost. The problem is compounded by the fact that boot code often utilizes complex data structures, whose contents drive specific actions. How do engineers verify that all data types have been processed and that the resulting functional behavior is correct?

Given the cost of shipping products with faulty BootROM code, it is evident that verification of the ROM is equally as important as verification of the RTL. Additionally, the need to minimize the physical size of the ASIC requires the ROM to be compact.

BootROM Verification Methodology

Intrinsix addresses ROM verification using methodologies that parallel those used for RTL verification.  Using constrained randomized test generation techniques, along with standard coverage measures, it is possible to thoroughly exercise the BootROM, while simultaneously highlighting optimizations that can be used to reduce code size.

As with RTL verification, the first step is to develop a test plan. The plan itemizes the key features of the BootROM procedure and establishes a strategy for creating and collecting functional coverage measures for these features. Oftentimes, the BootROM features can be extracted directly from the software flow diagram (Figure 1) for the boot process.

To complement functional coverage, BootROM line coverage is used to provide a measure of how thoroughly the BootROM code is exercised by the functional tests. Intrinsix has automated this process by extending the software tool chain that generates the BootROM image. In addition to loadable ROM code, the extended tool chain also generates coverpoints for each instruction in the ROM. These coverpoints are added to the testbench and provide a measure of which BootROM instructions are executed and which are not.

To cover portions of the software flow that is data-specific, constrained randomization is used to generate the test data to be processed by the BootROM code.

To collect the coverage data, the BootROM code is executed in a standard simulation environment, where a hardware implementation of the embedded processor fetches ROM code that has been backdoor-loaded into a simulation model for the ROM. Test regressions that generate constrained random stimulus are run to exercise each path in the boot software flow. Just as with hardware testing, the pass/fail results of each test are collected along with functional and line coverage.

An analysis of the simulation results, including line and functional coverage can:

• reveal bugs in the BootROM code,
• identify unused sections of the BootROM code, which might represent untested sections of code, or dead code that can never be reached,
• expose untested BootROM features itemized in the test plan.

By highlighting unused sections of BootROM code, verification engineers can determine whether the code is unnecessary. If so, it can be removed from the ROM image, resulting in a more compact ROM. Alternatively, the unused sections of code may represent a coverage hole in the BootROM tests.

Coverage holes that cannot easily be filled by constrained randomization often require directed tests. Well-defined directed tests, targeting specific BootROM features, can exercise sections of boot code that random testing fails to touch. Given the complexity of modern BootROM process flows, directed tests are typically needed to obtain the required coverage.

Summary

With only baseline tool flows, through the adoption of standard RTL verification practices, verification engineers at Intrinsix have developed a rigorous ROM verification methodology that flushes out BootROM bugs and reduces ROM footprint prior to fabrication. This nearly eliminates the risk of post fabrication BootROM failures, leading to a record of first pass success for our customers.