BootROM is still found in system-on-chip (SoC) designs, especially where security concerns rule out the use of booting from off-chip, non-volatile memory. While verification strategies for RTL are well-established and widely practiced, ROM verification methodologies are less well-developed and not widely standardized. Some ROM software verification approaches leverage highly integrated hardware/software co-simulation platforms, which can add significant costs to the verification effort. By applying standard RTL verification practices to BootROM, Intrinsix, now part of Cadence, has developed a methodology that relies only on standard RTL verification toolchains.
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 toolchains, 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. Another way to reduce bug risk would be to boot from an off-chip, non-volatile memory, but that decrease in bug risk can come at the cost of increased security concerns. Consequently, many SoCs have some embedded processor code that resides in on-chip ROM. At a minimum, this code boots the CPU after a power-on reset, but in practice, the process is more complicated.
Figure 1: Example BootROM Software Flow Diagram
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
The Cadence team 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. Cadence has automated this process by extending the software toolchain that generates the BootROM image. In addition to loadable ROM code, the extended toolchain 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 are 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.
Analysis of Results
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 Cadence 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.