Organized test code furthers firmware reuse

In the development of an SoC design, a company must not only test the functionality of each intellectual-property (IP) core but also test the complete system. Technology providers that develop both SoC platforms and individual IP cores have a unique perspective on the system integration and verification process. Such companies not only deal with the issues of integrating and using third-party IP in their platforms but also have the opportunity to apply that experience to improve SoC design and test methods for their customers.

At Palmchip, the SoC design verification process includes three main steps: simulation with bus-functional model (BFM) tests, simulation with firmware tests and emulation. BFM tests are usually written by the hardware design engineers during the development phase to check for logic errors in the RTL designs. They are usually short and exercise limited portions of the chip design. Firmware tests can catch system-level errors involving the processor and memory interactions that cannot easily be tested with BFM tests. In addition, errors in the documentation or implementation can readily be found by firmware because firmware engineers rely on specifications and user guides to create tests.

Emulation's role

The same firmware tests that are run in simulation are run on a development board via in-circuit emulation hardware and debugger software. Testing at this stage can reveal errors resulting from timing issues not generated in the simulation environment or by running a much larger number of te st cycles than is feasible in simulation. In addition, many hardware interfaces in the design get the ultimate test by being connected to real hardware devices instead of simulation models.

Combining simulation and emulation testing with firmware tests leads to an effective debugging method. Test code may run 1,000 times faster in emulation than in simulation, allowing more testing to be done. Emulation environments, however, are not as amenable as simulation to the debugging of hardware, since internal signals cannot be easily observed. Because the design must be resynthesized each time new signals are to be observed, debugging efficiency is limited.

Enhancing test coverage

On the other hand, simulation provides a wealth of debug information that can be captured in trace logs and waveforms. Because the same firmware test can be run in both simulation and emulation, an effective test and debug method is to run all the tests in emulation first and then run in simulation only the tests that fail. Test coverage is enhanced and test execution time minimized by the use of emulation; the debugging process is enhanced with the use of simulation.

Understanding the integral part that firmware plays in SoC verification, Palmchip has designed its firmware test suite for reusability. The ability to leverage existing firmware tests has resulted in significant time and cost savings in the development of new SoC platforms. For example, the same set of firmware tests for the UART core have been used in many SoC platforms with different processors and memory configurations, different or improved interconnect technologies, a range of interrupt controllers and various combinations of hardware peripherals.

Code reusability benefits IP suppliers and customers by providing a more complete product that can save customer engineering effort. Because the firm-ware has been used on a variety of platforms, customers can be assured that it is robust enough to include in their test code or thei r product code.

Dearth of standards

Because software code requires a functional hardware system that includes a processor and memory, however, firmware tests are rarely supplied with hardware IP cores, even though firmware is an indispensable tool for SoC development and verification. While great strides have been made in hardware and application software reusability, the lack of industry standards for creating system-independent firmware test code prevents IP vendors from delivering easily reusable firmware.

Today, Palmchip ensures firmware reusability through the organization and structuring of its firmware test code. All hardware-dependent firmware is separated from portable code. Code that accesses the SoC hardware directly is compiled into a hardware-abstraction-layer (HAL) library. The firmware test code accesses hardware only through the HAL library functions. Because all firmware has been designed using this abstraction, firmware tests can be reused in any SoC platform developed with Palmchip's IP.

The separation of system-specific code, hardware-specific code and portable code increased the flexibility of the firmware.

In the future, an additional layer abstraction, analogous to the relationship between an operating system kernel and device drivers, may be required to increase the reusability of firmware test code. To create an industry standard, firmware test code would interface to "firmware test drivers," and the test drivers would then interface with the HAL. In this scenario, IP vendors write and deliver test drivers for each hardware IP core. Users of test drivers write firmware tests utilizing calls to the standardized test drivers.

Firmware tests created in this way accomplish many goals: The test driver is independent of the system, allowing the IP vendor to provide truly portable code; firmware tests have the flexibili ty to call any number of test drivers in any order; and automated generation of firmware test code is feasible.

The Virtual Socket Interface Alliance has moved toward this goal by forming the Hardware-dependent Software, or HdS, working group, but much work remains to be done. Improvements to firmware reuse can only benefit the SoC and IP community.

Linda Yang is a firmware engineer at Palmchip Corp. (San Jose, Calif.).

http://www.eet.com