How to Ensure a Bug Free BootROM?

Akshay Bisht, Akash Goel, Yash Saini (Freescale)

In the era of, what we call "accident free cars", safety is the most critical area. A chip targeted for this market can be chosen based on various features and one such is presence or absence of flash.

During power on, the wake up process the chip undergoes is called booting, which is assisted by a special piece of software code called BOOT code or BOOTROM code. This software code is usually stored in flash in devices containing flash and in ROM in flashless devices. A ROM based code demands more vigilance in development and testing, as the ROM is one time programmable and any small error results in huge penalties. Thus, testing such a critical and initially encountered module is of the utmost importance, without which all fancy features of an NPI will be lost. In this article, we outline the robust testing of BootROM by churning out best capabilities of three powerful platforms – SoC simulation, Hardware emulation, and EVB Validation.

What is a BootROM?

BootROM is a piece of code stored in a Read Only Memory (ROM). Generally it is the very first code executed by the booting core when it is powered-on. Hence this code contains instructions to configure the system-on-chip (SoC) to allow the SoC to execute applications. The configurations performed by BootROM include initialization of the core’s register and stack pointer, enablement of caches and line buffers, programming of interrupt service routine, clock configuration, etc.

In a complex system, especially in the case of flash-less devices, BootROM also implements a Boot Assist Module (BAM) for downloading an application image from external memories using interfaces like Ethernet, SD/MMC, USB, CAN, UART, etc. BootROM generally drives the programming of these interfaces from internal fuses and strap pins of the SoC. In case of secure world, BootROM may authenticate the application image using some internal secure engine (e.g., AES128, DES, etc.) before ceding control of the SoC to the application image. With this important functionality governed by BootROM, it is important that the BootROM be bug free because any defect or code error found on silicon can require changes in the silicon mask or dropping of the intended functionality resulting in huge financial loss to the company.

The diagram below illustrates some major partitions of BootROM code and in the section that follows we will walk you through the debug platform best suitable to test the software building blocks of the BootROM.

Major Partitions of BootROM Code

BootROM code consists of various sections that are shown in the figure. Let us now briefly understand what they do.

Clocking section enables clock sources like PLL, RC oscillators, etc., and also takes care of locking their output frequencies to system use case frequency.
By reading the fuses or strap pins, a specific section of code, first of all selects the serial interface and then programs it for communication parameters like baud rate, serial mode (1bit, 2 bit, etc.).
For functional testing on Automated Test Equipment (ATE), BootROM may be equipped with a code downloader that downloads functional patterns into the internal memory, and to fasten the download of such functional patterns we use a parallel mode of communication.
To tackle any hang situation during BootROM execution, BootROM utilizes software watchdogs.
Application code is downloaded into various memory interfaces like flash, SDMMC, eMMC, etc., which when requested by master in DUT (programmed by BootROM code) fetch the application code into the internal memory.
Devices working on the principle of RCT (Root of Chain of Trust) have an extra liability of authenticating application code downloaded by BootROM. This is termed secure boot.
For safety critical devices to ensure the integrity of the system, it’s a must that they run a built in self test (LBIST,MBIST) on start up.

Comparative study of BooTROM testing using Simulator, Emulator and Evaluation Board

Sr. #	Description	SoC Verification (Digital Simulation)	Pre-Silicon (Emulation)	Post Silicon (Evaluation Board)
1	Testing of Clock programming done in BootROM	More suitable - depending on availability of VAMS/Spice models of PLL, Oscillator etc.	Limited because of availability of less accurate or non-availability of synthesizable models of PLL, RC Oscillator etc clock generating modules.	Most suitable.
2	Application Image Download and execution	Not suitable for bigger Application image size due to simulation time constraint	Good platform irrespective of the size of Application	Fastest way to validate the application download
3	Software Watchdog Timeout scenarios	Difficult to check in case if timeout value is too large to simulate.	Can be validated	Can be validated
4	Boot Performance Measurement	Difficult in case of large boot time due to simulation time constraint	Favorable as long as memory models are available.	Most favorable.
5	Code debugging Ease	Difficult	Easy. Because of the availability of external debugger.	Easy. Because of the availability of external debugger.
6	Issues related to Analog IPs behavioral Model	Present. Can be reduced by doing AMS simulations.	Present. For Eg. self-refresh mode of DDR cannot be validated	Not present
7	RTL(Design) signal visibility	100% across simulation time	Limited visibility	Almost None. Except signals exposed on Pads
8	Code Coverage	Difficult to analyze	Doable	Doable
9	Gate Level Verification with annotated SDF	Applicable	Cannot be done as timing information cannot be depicted because emulators are mostly cycle accurate models	NA
10	Speed of execution	Slowest(in Hz)	Fast(typically 100-500 KHz)	Fastest(typically in several MHz)
11	Sign-off Qualit	y Good – Because almost complete code can be tested without stubbing any DUT module.	Good – Because thorough testing can be done in stipulated time and L3 use cases to regress various data paths can be swiftly covered.	Best. Because we don’t rely on any mimicry of modules (analog etc) rather we have a fast platform with actual silicon.
12	Validation across PVT	Not possible	Not possible.	Can be done - by using ATE, Thermostream etc
13	Cost of Bug fixing	Very less. Because this is Pre-Tapeout state and ROM has not been ordered which embed the boot code.	Very less. Because this is Pre-Tapeout stage and ROM has not been ordered which embed the boot code.	Huge. Bug found will result in re-spin or dropping of the associated functionality.
14	Position in design cycle	Before RTL freeze and Tape-out	Before RTL freeze and Tape-out	After silicon arrives
15	Resource Cost	Comparatively cheap	Most Expensive	Cheap
16	Assertions to check design behavior	Generally used	Can be used. Depends on assertions- synthesizable or not.	Cannot be used as no design signal visibility
17	LBIST and MBIST initiation	Verifying it depends on the size of silicon and number of memory cuts present.	Can be validated irrespective of the size of silicon due to faster execution time.	Is validated swiftly.

Best way to sign-off BootROM: A Mix Debug Technique

To resolve a defect in BootROM requires a new revision of the chip, if found during silicon validation, hence it is very important that we do 100% testing of the code before base layer tape-out of the SoC. By testing BootROM in Simulation and Emulation environments simultaneously, thorough coverage of BootROM code can be ensured.

Below is a suggestive reference for validating various sections of boot code.

BootROM code section	Suggested testing platform
Clocking	Should be tested using Analog Mixed Signal simulation
Serial interface to download image on serial lines	Should be tested on Emulator as downloading is not constraint by application image size
Image downloader to be used on ATE	Should be tested by doing simulation of netlist with SDF annotated.
Watchdog timers programming	Should be tested on Emulator due to absence of run time constraint which is there in simulation
Memory Interface to download image from external memory	Should be done in simulation or emulation depending on the availability of memory model and drivers
Secure Boot	Should be done in simulation or emulation depending on the size of image to be authenticated.
LBIST and MBIST initiation	Should be checked using Gate Level Simulation of netlist with SDF annotated preferably after RTL Freeze and also in emulation due to faster speed of execution.

Conclusion

We have introduced BootROM code and its staple functions. We have described three robust platforms used for validating this code. The comparison table provides a ready-made reference for a user to utilize best capabilities of the three platforms for various target use cases. Finally focus shifts to a more direct tried and tested table, which suggests choices to make when validating code Pre Tape-Out (Simulation and Emulation). Although this articles talks mainly in context of BootROM code, this analysis can be extended to any scenario that has similar characteristics as BootROM code in terms of its content and targeted DUT infrastructure.

References

If you wish to download a copy of this white paper, click here