[Design Application]
Verify Hardware In A Logic Simulation Environment
Coverification Overcomes Problems Associated With Integrating Hardware And Software
Engineers assigned to integrate hardware and software early in the design process confront several less-than-optimal alternatives. They can write software models of the hardware in C or C++ to start software testing; they can approximate software behavior in the hardware simulation environment with a bus functional model; or, for single-chip designs that contain a microprocessor and other custom logic, they can use a fully functional model.
But, while running actual software in the hardware simulation environment works well, the price of simulating a full-hardware model of a processor (usually a known-good element) can sometimes be too high to pay. This choice also forces the programmer to debug in an unfamiliar environment using hardware simulation tools like waveform viewers.
Despite these and other drawbacks associated with the three different approaches, designers must start integrating hardware and software before they have silicon. The ideal solution would allow engineers to use existing tools and models with minimal modifications. This would enable developers to work in familiar development and debug environments.
The same software tools could be used for both the simulation environment and the target system, allowing the programmer to have the same view of the hardware, and ensuring a smooth transition from simulation to integration. This approach, which can be done without special modifications to the embedded software for the cosimulation environment, is employed by the Virtual-CPU (V-CPU) environment (see the figure).
Coverification In Use In the coverification environment, hardware simulation uses existing logic simulation and debug tools. Early simulation may take place in an event-driven simulator using either Verilog or VHDL. Later in the design flow, cycle-based simulation, acceleration, or hardware emulation may provide the hardware execution environment. Using this simulated representation of the hardware, the embedded system software can be run in two modes, host-code or target-code. Host-code mode uses the native workstation tools to compile and debug the software, while target-code mode uses the tools for the target processor.
The embedded system memory map is the underlying control structure that translates software accesses to hardware simulation or software functional models. When hardware models of peripherals are not yet available, or have already been fully tested, software functional models allow for higher performance by handling transactions in the software environment instead of the hardware simulation environment.
The coverification environment is complete when the software and hardware models are interfaced via an application programming interface (API). Host-code software uses the API to initialize the environment and to interface instruction set simulators (ISSs) for target code execution. The hardware simulation interface can be used to translate software instructions from the coverification environment to the design-specific bus functional model (BFM). The BFM then becomes the interface to the hardware simulation.
Each interface has a common transaction model—the set of primitive actions that decide how software interacts with hardware. These are bus-oriented transactions, and include instruction fetches, reads, writes, and interrupt checks. The transactions are broadly defined to allow a wide range of buses to be modeled. They include varying size accesses, cache line reads and writes, and user-defined options.
As an extension of the bus functional model and testbench approach, this methodology uses the same BFMs, and replaces the testbench with embedded system software that generates bus transactions. In addition to the read, write, and interrupt transaction model, a "back-door" interface is provided. This interface allows the user to develop hardware-side tasks to perform functions outside those possible with bus protocols. Typical uses of the back-door interface include loading HDL memories, injecting signal stimulus to the design, and controlling hardware-side debug tracing.
The Environment This coverification environment was used to develop device drivers for a design based on the Advanced RISC Machines', Cambridge, U.K. architecture. The ARM7TDMI is a 32-bit RISC microprocessor used for a wide range of applications, including digital cell phones and pagers, set-top boxes, printers, and hard disk drives. These are high-performance and cost-sensitive embedded-control applications with particular emphasis on reduced system power consumption.
Features of the ARM architecture include both the 32-bit ARM instruction set and the 16-bit Thumb instruction set; a three-stage execution pipeline that remains hidden from application software; single-cycle instruction execution for most instructions; two cycle branches and memory access instructions; support for byte, half word, and word accesses; fast and normal interrupt support; on-chip emulation support; and a fully static design for minimizing power consumption.
Integrating the ARM7TDMI with the coverification environment was straightforward. For the core bus, there was an existing bus functional model available, developed by ARM. This model was produced using the same tools used by ARM for all of the fully functional design simulation models (DSMs). The model runs with both Verilog and VHDL simulators, and integrates seamlessly into the logic simulation environment. No additional HDL modules need to be instantiated in the design. And, for some logic simulators, only a simple environment variable change is needed to switch from the fully functional DSM to the bus-functional DSM.
A popular instruction-set simulator was also integrated for running native ARM code. This simulator, called the ARMulator, employs a memory interface that maps address spaces into a C API. Code was developed to interface this API to the V-CPU API. The combination of the ARM bus-functional model, the ARMulator integration, and the V-CPU API provided the programmer with a means of using both host-code and target-code modes for fast development and debugging of diagnostics and drivers.
This methodology was used in a device driver for a serial interface that can be used to connect to peripherals using a small number of signals. The serial interface was part of a highly integrated chip that was still in development. The device driver was developed employing the system specification, and simulated with a coverification environment using the hardware models and the RTL code for the design. This allowed early access to the hardware for the software engineers, and provided real-world stimulus to the hardware design.
Reprints
