Table of Contents

System-on-a-Chip (SoC) Drives Need for Hardware/Software Co-Verification
Benefits of Performing Hardware/Software Co-Verification
Meeting the Needs of Both Hardware and Software Engineers
The Ideal Hardware/Software Co-Verification Environment
Xpert Delivers Performance Required for Effective Co-Verification
Model Availability and Accuracy
Xpert Provides Performance without Sacrificing System Level Accuracy
Integration to Software Debugging
Conclusion

System-on-a-Chip (SoC) Drives Need for Hardware/Software Co-Verification

One of the most critical steps of embedded system design is the integration of software with hardware. Traditionally, this important step has been performed in a lab environment by constructing hardware prototype and running the embedded system software on that prototype. Debugging was done using equipment such as in-circuit emulators (ICE), logic analyzers, and oscilloscopes. Integration and debug late in the design cycle, when the pressure of the project schedule is the greatest, is a tedious, risky, and stressful task.

The advent of system-on-a-chip (SoC) forced the development of new techniques so that chips could be adequately tested in a simulation environment before silicon fabrication. This created a need for Hardware/Software Co-Verification. Hardware/Software (HW/SW) Co-Verification tools enable designers to execute embedded system software on a representation of the hardware design before prototypes are available. This allows early testing of software and augments the verification done by hardware engineers, leading to shorter project schedules and increased confidence in a completed design.

However, many complex SoC designs are still using nothing more than a full-functional simulation model of a microprocessor, using waveforms to debug complex hardware and software. The key to a successful HW/SW Co-Verification solution is to avoid hardware-centric verification methods and meet the needs of the software engineers.

Benefits of Performing Hardware/Software Co-Verification

The ultimate goal of co-verification is to get the entire system -- hardware and software -- working prior to prototype by providing better visibility into the behavior of both hardware and software. Co-verification achieves this by providing two primary benefits:

1. Software engineers have much earlier access to the hardware design. This allows software designers to develop code and test it concurrently with hardware design and verification. Performing these activities in parallel shaves time from the project schedule compared to the serial method of waiting for the prototype to begin software testing.
2. Co-verification provides additional stimulus for the hardware design. In fact, it can provide the true stimulus that will occur in the embedded system. This improves hardware verification when compared to using a contrived testbench that may or may not represent real system conditions.

By running Hardware/Software Co-Verification, a wide range of problems can be found and fixed such as register map discrepancies, problems in the boot code, errors in DMA controller programming, RTOS boot and configuration errors, bus pipelining problems, and cache coherency mishaps. As expected, some of the errors are software problems and some are hardware related. Most projects have a surprising number of specification misinterpretations. It is also common for a system in the lab to appear to be working, when in reality it has programming errors that are causing the system to run at sub optimal performance. A simple example is a system that uses caching. Incorrect cache setup may allow the system to function, but not running as fast as possible.

Performing this integration of hardware and software as early as possible allows designers to identify errors and fixed them when the cost of fixing them is minimal. This not only saves development costs, but also reduces the overall project schedule.

Meeting the Needs of Both Hardware and Software Engineers

Performance
One of the major reasons co-verification has not been more widely accepted is the chasm that exists between hardware and software engineers' expectations of runtime performance. 

Running logic simulation jobs for a few hours or even overnight is common for hardware engineers. Software engineers are accustomed to running on real hardware at speeds of 50 or 100 MHz. Hardware verification is mostly a batch operation that uses post-processing tools for debugging. In contrast, software testing is an interactive process where the system is reset again and again and breakpoints are moved to stop at just the right place to identify problems. At full speed, the penalty for flicking the reset switch is minimal. When a simulation runs overnight, having to start over from the beginning can be fatal to the project schedule.

Model Accuracy
Another difference between hardware and software engineering is the required level of detail. Hardware verification requires a very high level of detail to be successful. All the simulation in the world is of no use if the conditions being simulated are not correct. Conversely, software functionality does not usually require a great detail to test that algorithms work correctly. Behavior at each clock cycle of a microprocessor is far too detailed for software engineers to even care about.

Debugging Loop
Another area of concern is the debugging loop. Typically, three groups of engineers are involved in debugging hardware and software designs: software engineers, verification engineers, and hardware engineers.

The debugging process starts when software engineers compile code and prepare memory image files for execution. Because they are unfamiliar with logic simulation and emulation tools, they pass memory image files to the verification engineers who run the test. If the test fails, the verification engineer has to isolate the problems and present the result to a design engineer who is familiar with the specific part of the design that has a problem.

Once the hardware engineer studies the problem, he or she may make a hardware change and try the test again. Or he or she may decide that the hardware is just fine, and the problem is in the software. The software engineer must be called in to inspect the problem, but needs help from a verification engineer to study the waveforms, debug the software, and verify that it is working correctly in the simulation environment.

Finally, the software engineer generates a fix, and the process starts all over. This cycle of throwing results over the wall among the three groups requires multiple people working together, and can really slow down the project. Co-Verification tools must tighten this debugging loop and allow software engineers to find and fix problems with less intervention by verification and hardware design engineers.

The Ideal Hardware/Software Co-Verification Environment

An ideal solution for Hardware/Software Co-Verification addresses all the key requirements: runtime performance, access to accurate models, ease of use for both hardware and software engineers, and affordability. Many verification approaches have addressed one or more of these requirements, but none has been able to meet all of the needs.

Requirements such as in-circuit emulation performance, access to all model types, setup and debug environment that is easy to use, and a solution that can verify the entire system, are critical to the success of HW/SW Co-Verification.

Axis' solution, Xpert, combines patented, breakthrough ReConfigurable Computing (RCC) technology with a new technology that specifically addresses software debugging needs. Xpert works in conjunction with Axis' existing Xcite® and Xtreme® products to provide a single system with the fastest co-verification and debugging capabilities that meet the needs of both hardware and software designers

Xpert Delivers Performance Required for Effective Co-Verification

The performance level attained when running large amounts of RTL code in a traditional logic simulator is unacceptable. Not only does this method have trouble filling the gap between hardware and software engineers, it is even too slow for hardware engineers. A solution that executes RTL code orders of magnitude faster is a must.

Model Availability and Accuracy

Any solution that requires software model creation is not feasible. Today's microprocessors are too complex for software modeling methods because the time to create the models is so long that the solution will miss the project window. Also, because of the fragmentation of the embedded systems market, it is difficult to sell a lot of copies of the same solution. But the models are only as good as the number of users and the number of hours of simulation time they have been used.

The ideal solution for model availability is a golden representation of the processor, preferably the RTL code. RTL encryption methods can be used to protect the IP when necessary. If RTL is not possible then device silicon can be used as a simulation model.


Xpert supports three types of models:

• RTL models
• IP Builder models
• Certified ISS models and bus models

The ideal model for Xpert is the synthesizable RTL code of the processor. Many of the microprocessors used are available in this form. RTL models can easily be mapped to RCC and deliver maximum performance and accuracy. RTL models also provide full visibility into the processors' register set.

In the case of processor cores that exists in RTL but cannot be distributed, Axis provides IP Builder, a tool that allows IP vendors to protect their core and still provide a model that can be accelerated by the RCC technology. IP Builder provides a secure method for integrating IP cores and allows visibility to only the registers that are defined by the IP vendor.

Another type of model used by Xpert is a certified instruction set simulation (ISS) and a bus functional model (BFM). Some IP vendors have chosen to produce cycle-accurate instruction set models and bus functional models instead of using the RTL code for the processor.

Whatever modeling methods are deployed, Axis' co-verification solutions will support the greatest accuracy models available to ensure that software model creation does not hinder customers. All models are obtained directly from the semiconductor vendors and are certified accurate for co-verification.

Xpert Provides Performance without Sacrificing System Level Accuracy

Many co-verification solutions have tried to improve performance by "optimizing" logic simulation cycles. On the surface, improving performance by not simulating the "uninteresting" aspects of the system, such as fetching instructions from a boot read-only-memory (ROM), may seem reasonable. After all, if you have seen one fetch, you've seen them all. However, these optimizations can lead to synchronization issues between the software execution time domain and the logic simulation time domain. For operations such as timers and DMA transfers, special tweaking may be required just to obtain proper functionality for the software. This will result in decreased design confidence and an environment that is difficult to use. 

Because RCC provides performance that is orders of magnitude faster than logic simulation, these "optimizations" are not necessary. It is not necessary to tradeoff simulation detail to raise the performance to an acceptable level. Axis provides solutions with system level accuracy, simulation detail, and performance, without compromise.

Integration to Software Debugging

Emulation platforms that provide the needed performance levels have suffered from software debugger integration issues. Emulation systems use silicon components as the microprocessor model and deploy JTAG based debugging techniques. These interfaces do not require any special engineering, but even at a speed of 1 MHz they do not provide the necessary response time to satisfy software engineers. JTAG commands can require long scan sequences for complex debugging operations.

Another limitation in debugging software using an emulation platform is the controllability of the system. Unlike logic simulation, the entire system does not stop when the software execution stops. When debugging in a lab environment, repeatability of errors has long been an issue for embedded systems. Many software engineers are familiar with timing problems where even adding some print statements to debug can change timing and hide errors. This issue becomes even more challenging when verifying embedded software for a multi-processor system.

The ideal co-verification solution provides performance levels that approach emulation, while providing the trigger and breakpoint capabilities of a software simulator. In a software simulator, when the software hits a breakpoint everything can be stopped. Problems are now deterministic and the simulation time can be advanced clock by clock to study detailed behavior.

Xpert provides all of the performance benefits of emulation with all of the control of a software simulator. Its support for RTL modeling methods provides full visibility to all registers and memories from the software debugger. Unlike JTAG methods, debugger integration to RTL models does not require long sequences to scan commands in and out of a processor model. It requires only a small amount of interface software to connect the debug command set to the RTL model registers and memory. When debugging a multi-processor system, Xpert provides a correlated view of each processor.

Finally, a co-verification solution should support direct access to the memory data. With emulation platforms or prototypes, the only way to read and write memory is by executing bus cycles on the CPU bus. These debugger-generated transactions are artificial and will not occur when the system is running normally. Even at 1 MHz it could take a long time to dump large amounts of memory needed for common debugging tasks such as software disassembly or filling a memory window to view complex data structures.

Ideally a software debugger should be able to read and write memory, either logic simulation models or hardware memory, without simulation time elapsing at very fast speeds. Xpert provides this direct interface to both logic simulation memories and RCC hardware memories. The debugger accesses "optimize" memory to maintain simulation accuracy while quickly providing large amounts of memory data.

Conclusion

Axis Systems is uniquely positioned to deliver co-verification solutions that exceed nearly every desirable trait of the ideal co-verification environment. Realizing that no product can minimize performance, ease-of-use, and cost, Axis is creating the Xpert family of co-verification solutions that balance these trade-offs better than any other products in the co-verification market. The technology of a single system for logic simulation, simulation acceleration, and system emulation along with a co-verification environment for both hardware and software designers will deliver the verification solution needed for the next generation of designs.