How co-verification speeds firmware development

In this manner, we probably cut our firmware development and verification time in half. We can send our customers working, tested, reference firmware along with the hardware prototype, and get them going much earlier on their development. Three years ago, when we weren't using this methodology, it would take six to nine months to generate even a skeleton firmware that would allow us to test out the processor interface in simulatio n. Now, the more sophisticated firmware may take even longer, but we do most of the verification of the hardware functionality and firmware controllability before the prototypes go out the door.

Our flow had to change somewhat from what we were doing previously. Before, we would not even attempt to test system level functionality with actual C or C++ based firmware. We would buy, license, or more likely, design our own processor model and use it only to check the register mapping and storage element accesses. This required converting the firmware into hex code and loading a RAM model of that into the RTL simulator. It's a very laborious process.

To give you an example, if we ran a simulation and found a problem with the firmware, it would take hours to track down the simplest problem and determine where the problem in the firmware occurred. After a change was made it would require maybe another hour to change the firmware, recompile, regenerate the hex code and kick off the process to get to the p oint where we could look at it again. Most "real" functionality checks were done using RTL test benches and RTL-based "firmware."

Today we get our processor model, say an ARM or Intel core, to which we add our own synthesizable Verilog model of the IC and other parts of the system. For example, we are currently using an in-house SAS Initiator model and are performing actual verification of the SAS compliance of the part using real firmware. We can do three to five significant simulation runs in an hour.

Our verification platform includes a software execution environment that runs our embedded system software as if it were running on the target CPU. This is coupled with a logic simulation of the embedded system hardware, which responds to bus cycles as if they were initiated by the target CPU. The target processor is replaced by the interaction of a bus-functional model (BFM) of the processor (in the hardware simulator) and a virtual processor (software side of co-verification) running the as a na tive-compiled executable on the host workstation.

Figure 1 -- Hardware/software co-verification methodology using Summit Design's V-CPU product

The software side can run in host-code execution mode in a workstation process or in target-code execution mode within an Instruction Set Simulator (ISS). The advantages over the alternative — substituting a full-functional processor model for the target processor — are that it provides a higher performance and gives our designers greater ability to observe and control the executing software.

Our designers model the embedded-system hardware in Verilog, and the software in C. We then compile or assemble to run each as a separate workstation process. The software runs on the workstation and accesses user-defined address ranges via the BFM, which mimics the processor interface.

The algorithmic portion of the program executes on the virtual processor, and we can use existing tools for software and hardware debugging. We swap models or configure C software functional models for modeling external environments, peripheral devices or portions of the hardware design that are not completed.

Because our embedded system ASICs are so incredibly complex, it has become expedient for us to supply our customers with sample firmware that they can use as a reference for their own firmware development. Using this methodology allows us to develop working firmware using a high-level language, such as C. We can then provide this firmware to the customer at the same time as the prototypes of our ASIC. The learning curve for the part is dramatically decreased, cutting several months off our customer's development schedule.

Another goal that we can achieve is the development of embedded system products that are easier to use. As our firmware developers work on verifying the part as a Verilog database, we can suggest changes to the hardware. Many of the suggested changes have to do with simplifyi ng the firmware, increasing the speed of the firmware, or decreasing the size of the firmware.

A final goal that we have achieved is better, more correct specifications. Before the customer ever sees the prototypes, several in-house LSI firmware developers have gone through the specification with a fine-toothed comb. Problems or inaccuracies in the specification are discovered through actual use, as opposed to the previous method of attempting to ensure correctness by inspection. You might say the specification is verified along with the actual hardware design. This is a unique capability for ASIC designs, where often the specification used by the customer is delivered in the form of a rough, only partially verified, draft.

In general, we use Verilog and third-party memory models to develop the system model. We get the processor model, and we develop a pseudorandom testbench using third-party tool. We use gcc and other GNU tools to compile and debug the C-code. Depending upon personal preferenc e, the firmware developers use either Xemacs or CodeWright for C-code development.

As mentioned earlier, originally we did everything in Verilog, but the effort to generate even a simple processor model, such as the 8051, was prohibitive. This also required us to run the firmware by compiling, converting to hex files, and loading into memory in the RTL simulation before finally running the tests. This meant that turn times from C-code modification to simulation were very slow. Additionally, we had to develop obscure methodologies to display program trace information in order to track what was happening in the firmware.

The ability to allow firmware to peek and poke hardware through "back door" API routines was very interesting to us. This capability allows the firmware to, for example, set Verilog events to signal the testbench about certain occurrences. It also allows firmware to view the hardware registers or memory locations "on the fly," without utilizing the processor bus and, thus, without affecting that actual operation of the chip. This has been invaluable in the debugging effort. The fact that firmware can display text to the NC Verilog listing was another factor that helped us make our decision.

In the past, we tried full RTL simulations with RTL bus functional models. These ran much faster but were painful to develop or debug. We also investigated various hardware modeling products that used FPGAs to obtain faster simulations, but these could not handle even minor RTL code changes with any degree of efficiency.

In fact, before, the verification engineers had to delve so deeply into the Verilog to test the part, that it was impossible to keep any distance between (RTL-based) firmware and hardware development. Firmware engineers now can develop firmware while “understanding” the ASIC by using just the hardware specification, much as a customer would. This means that our hardware developers receive extensive feedback regarding the specification and "firmware friendliness" of the design long before the customer has to deal with these issues.

We have truly achieved first time success with our methodology and verification platform. We have also received reports from customers indicating that they have achieved working firmware at their site in record time. That boon occurs because our own firmware engineers have checked the specifications and because of the sample firmware that we supply.

The methodology itself is fantastic. We could never go back to the old way of doing things at this point; however, nothing is perfect and we'd still like to see a number of improvements. Among them are run-time-only capabilities for use with regression testing, faster simulations and better first-time accuracy with new processor models.

Dave Fechser is a verification engineer at LSI Logic, Ft. Collins, Colorado.