A Low-cost Emulation System for Fast Co-verification and Debug J. Lagos-Benites, M. Grosso, L. Sterpone, M. Sonza Reorda

G. Audisio, M. Pipponzi, M. Sabatini

Dip. Automatica e Informatica – Politecnico di Torino Torino, Italy {jorge.lagos, michelangelo.grosso, luca.sterpone, matteo.sonzareorda}@polito.it

Pirelli Tyres S.p.A. Milano, Italy {giorgio.audisio, mauro.pipponzi.ex, marco.sabatini}@pirelli.com

Abstract— Nowadays, Systems-on-Chips (SoCs) are employed in an ever-increasing range of embedded applications and environments. Their complexity can be quite high, as they can be composed of many different functional cores including microprocessors and different layers of software can be present. To verify the correctness of the hardware and software implementations and the overall system performance at early stages of the design flow is crucial for reducing the time-tomarket. To this purpose, several methodologies are available, based on simulation and/or emulation, which accomplish different compromises between model detail and speed. We propose a new low-cost, flexible system for SoC co-verification which provides improved controllability and observability in a fast self-contained FPGA-based emulation environment. In addition, software debug is supported by advanced features enabling observation of critical signals, breakpoint setting and step-by-step execution with total memory accessibility. Experimental results in an industrial case of study confirms the effectiveness of the approach for validating the noise immunity of a Digital Baseband (DBB) communication system over a wireless channel by means of noise injection, and for debugging the system software. Keywords-System-on-Chip; co-verification; debug; FPGA.

I.

INTRODUCTION

Embedded systems are present in almost all aspects of today’s life, from entertainment to industrial fields, from telecommunications to transportation, to medical applications. For instance, inside a typical car dozens of microprocessorbased systems are present, devoted to a range of purposes such as infotainment (e.g., CD or DVD players, GPS) and engine and body system control (e.g., ignition, stability, steering), and their number is continuously rising. Systems-on-Chip (SoCs) play a principal role in the embedded system field when high performance, low power consumption and small size are required. These devices integrate on a single silicon die a large number of components (cores) such as Digital Signal Processors (DSPs), memories, I/O peripherals, networks and analog parts. Hardware SoC design is made easier and faster through the reuse of in-house available or third-party cores that can be integrated and suitably assembled with newly developed ones. However, guaranteeing the implementation correctness of a complete system, which could also include several software layers, is becoming a daunting task. Finding design or implementation bugs requires activating the devices in

functional mode while feeding them with suitable input data and control signals, replicating complex and possible long operating sequences, and observing critical signals. Single hardware modules and small low-level code segments can be efficiently reproduced and analyzed in simulation, employing specific testbenches, or verified through formal techniques, but when larger and more complex system compositions are concerned, simulative methodologies can hardly be employed. The main issue is in the huge requirements in terms of computational power and time needed to simulate a complete system, possibly running an operative system and facing a wide range of operating situations. Emulation can represent a valid alternative, enabling faster system behavior reproduction, but often with reduced system observability. Many methodologies have been proposed by academia and industry to tackle the hardware and software co-verification and debug issues, resorting to simulation at different levels of abstraction, often combined with emulation platforms. Commercial environments are available based on simulation, as well as emulators, or programmable hardware, each one offering a specific set of features and possibly introducing a significant setup cost in the design flow. This work proposes a co-verification and debug environment for SoC designs, implemented on a low-cost FPGA board. Thanks to an embedded microprocessor mapped on the FPGA and used as interface to the design under verification, the emulation environment is self-contained and can run at high speed. Complete controllability on the inspected device is achieved, including I/O signals, clocks and memories, so as to perform hardware validation/verification and supporting software debug, while the development of tests relies on writing high-level code routines. In addition, the adaption to different circuits takes minimal redesign effort, making the system particularly suitable to follow the different development steps of a new complex device. In our previous work [1], we presented an FPGA-based emulation platform for embedded system verification that employs a soft processor (called Infrastructure Microprocessor or IM) to implement different verification flows supported by a suitable software environment. The work presented herein extends the capabilities of the platform by adding additional control and observation features in order to interact more deeply with the emulated system. Also, we demonstrate the possibility of

adding purpose-specific verification support modules to the emulation platform in order to perform specific tasks, such as bus protocol conversions or noise injection. The management of the verification and debug operations is performed by means of software running on the IM, exploiting automaticallydeveloped communication libraries. Hardware and software debug operations are described in detail, as well as validation performed through noise and fault injection modules. The proposed platform is currently being employed for coverification and debug of an innovative automotive system under development by Pirelli Tyres. The main integrated device, located inside a car’s tire, is intended to acquire accelerometric data from the tire inner liner and transmit them to the main car body. Such data will then be elaborated and employed for improving braking and stability control systems. The in-tire device performs preliminary data elaboration and wireless data packet transmission, synchronizing itself with the wheel round. To guarantee the behavior correctness in all possible operating conditions is fundamental for this kind of product, and the verification process needs to follow each development stage. The proposed platform has proven its effectiveness in verifying the implementation of a digital signal processor [1] and in validating the noise immunity of the digital baseband channels and the correctness of the system assembly and coordination. This paper is organized as follows. Section II reviews the state-of-the-art of SoC co-verification and debug. Section III describes the proposed approach, while Section IV details the supported verification and debug flows. Section V describes the system implementation, whose automation is outlined in Section VI. The experimental case study is presented in Section VII, while Section VIII concludes the paper. II.

BACKGROUND AND RELATED WORK

The design flow of today’s SoCs is based on the integration of cores of different origin. The final device needs to comply with the specifications, which include functional requirements but also timing/performance and power constraints. Even if all the single composing modules are guaranteed to be design error-free, the resulting system needs to be thoroughly tested to check the correct interaction and synchronization of all composing elements, taking into consideration a complete enough range of stimuli and environmental conditions. The earlier these testing operations are performed, the less expensive any required design corrections are: any possible undesired behavior found can then be corrected through hardware modifications, or through software update, or both. Several approaches can be found in literature for hardware/software co-verification and debug for SoCs. The author in [3] divides the approaches for system co-verification in four categories: (a) using an HDL model of the processor and memory and putting the compiled software into a ROM; (b) using an Instruction Set Simulator (ISS), a connection interface and a logic simulator; (c) using an ISS, a connection interface and an emulator; (d) using an emulator, a target system, and a standard software debug emulator interface. A suitable trade-off usually needs to be found between the accuracy and the observability of system signals given by the model and the achievable simulation and/or emulation speed.

Mixed simulation-emulation methodologies, such as the one described in [4] for embedded software verification, offer promising possibilities, but are inherently limited by the communication channel between the host simulator and the hardware accelerator. The authors in [7] built a microprocessor-based coverification and debug platform on an FPGA, without hardware or software system modifications, which helps in tracing system operations and checking overall timing, but does not allow control of the system execution. An emulator environment based on an FPGA prototyping board is presented in [6], giving to the developers the possibility of observing system signals and programming breakpoints; anyway, the functional I/O system interface is limited to a PCI port, since the addressed system under verification only owns that interface. The authors in [5] developed a highly efficient methodology for tracing the system behavior in FPGA emulation and reconstructing interesting parts of the execution flow in simulation, but do not directly address the I/O interaction with the system and different clock domain management. In [8] co-verification and debug are supported by a customizable unit to be embedded into the SoC, and a flexible external FPGA platform interacts with it. The addition of a new module into the design may change the final behavior and impact on area and power. The authors in [1] propose the use of hardcoded breakpoint instrumentation accessible with JTAG for debugging microprocessors: in this case the breakpoint programming flexibility is limited by design. In [1], partial reconfiguration is introduced for modifying the observation infrastructures in FPGA designs, but this is only applicable when modifications have to be applied in specific design areas, and may have an effect on area, power and speed optimization. III.

THE PROPOSED APPROACH

We propose a co-verification and debug system based on full FPGA emulation of the circuit design and on a dedicated microprocessor-based interface. This enables the early validation and debug of the hardware design and also of any software running into it. Moreover, the emulated system is as close as possible to the final implementation in hardware and software. No debug-related software routines are needed to be run into the system under verification to increase observability, and no hardware modifications are applied, thus avoiding that the system itself operates differently from mission time. The basic set of functionalities offered by the proposed platform to design and verification engineers and to software developers are the following:      

Synchronized pattern application on the Device Under Verification (DUV) input ports and results readback on output ports Separate clock domain management Embedded memory read/write operations Observation of critical internal DUV signals Breakpoint setting applying complex logical conditions based on signal observation Interactive step-by-step execution.

Such operations are managed by an IM, which is also mapped on the FPGA and provides a powerful and flexible interface between the DUV and the host computer (see Fig. 1). The use of a microprocessor provides an easy way to develop customized verification and debug flows, requiring only the writing of high-level code. A library of general, automatically generated supporting functions to be run by the IM is used to further simplify procedure development: the basic functionalities deal with feeding patterns and reading output ports or other signals, applying a series of clock cycles, and reading and writing any DUV memory core. More complex functions can be developed to apply specific protocols on a subset of the DUV I/O signals. As an example, if a subset of the DUV input ports is a PCI interface, a specific function implementing the PCI protocol can be developed and run on the IM to perform the required data transfers by activating the proper control signals. Breakpoints, which are highly desirable when performing the debug of extended system emulation runs, can be programmed exploiting the complete flexibility of a high-level language, correlating different observed signal conditions through logical functions and software counters. Input/output, clock management and breakpointing tasks have to work in parallel on the IM to correctly stimulate the DUV and apply the desired flows. The coordinating tasks are delegated to a suitably developed software scheduler which introduces a minimum time overhead on the application of the flow, by keeping track of the elapsed clock cycles and determining clock-by-clock the low-level operations that need to be performed. The infrastructure microprocessor controls the clocks feeding the DUV in order to apply the input stimuli and sample the output results at accurate time intervals in spite of the unsteady flow determined by the concurrent execution of the coordination procedures. Therefore, the DUV emulation is clock-accurate and orders of magnitude faster than simulation. IV.

VERIFICATION AND DEBUG FLOWS

Co-verification and debug flows to be applied to the DUV can be composed of predetermined sequences of operations, or support user interaction through external communication channels. As an example, a system can be programmed to run, while patterns and clocks are suitably fed, for a certain number of clock cycles or until a specific event happens in the system, detected by the breakpoint logic. Then, signal or memory area readings, or step-by-step DUV execution, can be interactively requested by the user. To enable effective co-verification and debug across the various development phases of complex integrated systems, a supporting software environment was developed, ranging from HDL simulators up to high-level system models. A preliminary verification methodology is aimed at the verification of single computational devices in configurable data processing units (e.g., DSP cores) or less complex subsystems. For these cases, the verification process is based on simulation templates that provide control signals for configuration and management of DUV operations. The input data patterns and expected results are computed with higherlevel bit-true models (e.g., MATLAB routines) which are

suitably applied in combination with the simulation templates. This methodology saves RTL simulation time and checks the circuit computation correctness in application-like situations. An advanced verification methodology exploits data patterns and expected results generated off-line through highlevel models, while the correct communication protocols to be reproduced on the ports of the DUV are implemented through suitable programming of the IM. Input data patterns, which have to be stored on an available memory on the development board, are fed concurrently. Similarly, all outputs are sampled and compared with the expected responses through interaction with the DUV output ports by means of suitable protocols. The final verification strategy enabled by the proposed environment utilizes a closed-loop with high-level models running on the host PC. Similarly to the previously described one, with this technique I/O operations with the DUV are managed by specific procedures running on the infrastructure microprocessor mimicking appropriate protocols. Input data patterns are elaborated by the host PC, while results are stored in the on-board memory and consecutively sent back to the host PC for analysis. This technique allows setting up an optimization loop for pattern generation by analyzing the DUV responses and suitably modifying the patterns to be fed to the DUV, so as to explore the widest range of application cases and/or maximize suitable coverage metrics. V.

PLATFORM IMPLEMENTATION

The proposed low-cost, flexible platform for system coverification and debug is intended to be implemented on a lowcost FPGA development board. The main platform components, whose architecture is sketched in Fig. 1, are the following: 

the Infrastructure Microprocessor (IM), which manages the verification and debug operations and interacts with the host PC;



the IN_ and OUT_interface registers, connecting the IM to the DUV I/O signals and to the verification support IPs;



the Observation registers: in addition to the interface registers, other IM-accessible registers can be connected to critical system signals to provide increased information during debug; in this way the logic values of these signals can be used for setting breakpoints;



the clock control module, in charge of feeding the highest frequency DUV clock, so as to synchronize the system;



the Shared memories, which are effective components of the DUV, and are made accessible by the IM;



the Verification support IPs, which may be added to support verification operations (e.g., for operating bus protocol conversions, injecting noise or faults) and which usually derive from HDL testbench processes; they are controlled by IM-accessible interface registers.

In addition, the IM is in charge of reading and writing any DUV shared memory cores and of interacting with any verification support IPs. Finally, it communicates with the host PC to visualize results and to perform interactive operations, by exploiting available interfaces, such as serial ports or Ethernet channels.

Device Under  Verification Shared RAM

OUT_interface

IN_interface

External direct I/O

All verification and debug operations are programmed by writing suitable high-level software routines for the IM.

main clk Observation  registers

Support  IP(s)

Infrastructure Microprocessor

Clock control

FPGA FPGA development board

DRAM UART

Host PC JTAG

Figure 1. The proposed FPGA-based co-verification and debug platform.

The most important feature of the proposed platform is the possibility of managing the whole verification and debug process through a single microprocessor, which resides into the same FPGA chip where the DUV is implemented. In this way, a self-contained platform with a single standard interface is made available to the verification and debug engineers. The emulation can run at high frequency with no limitations in the number of I/O channels and without requesting high-speed, expensive connections to the host system. Nonetheless, external direct I/O can be routed to the FPGA board ports in order to connect the DUV to other chips for composing a wider system under verification, possibly including analog devices. The following paragraphs provide details about the different components of the proposed platform. A. Infrastructure Microprocessor A dedicated microprocessor, either hardcoded on the FPGA chip or mapped as soft core, is employed to manage the verification and debug flows. It fetches code and data from a memory area (named DRAM in Fig. 1) available on the FPGA development board, which has to be preliminarily filled through a suitable connection (e.g., JTAG) from the host PC. The IM main purpose is providing patterns to the DUV using the memory-mapped IN_interface registers, either by applying precomputed bit sequences, or by generating on-thefly the stimuli needed to interact with the DUV ports in their specific protocols. Then, the IM samples, by means of the OUT_interface registers, the DUV primary outputs and, through the observation registers, suitable additional internal points to check the correct system behavior. The read data values can be employed to activate breakpoints to stop the system execution when specific conditions happen. In such cases, debug operations can be applied, e.g., reading memory locations or step-by-step instruction execution in the DUV.

B. IN_ and OUT_interface registers The interface registers are connected to the primary I/O ports of the device under verification and are also accessible as memory-mapped devices by the IM. By means of them, I/O operations are performed on the DUV for verification and debug purposes. C. Observation registers Similarly to the interface registers, observation registers are accessible as memory-mapped devices by the IM. Instead of being connected to primary I/O DUV signals, they can be used to monitor critical internal signals of the DUV, such as state variables, address and data buses. In conjunction with the data sampled by the OUT_interface registers, the observation registers’ contents can be used to setup breakpoint conditions. Such conditions are described in high-level software routines run by the IM, so they can be as complex as needed by the specific verification or debug flow. D. Clock control module The system clocks are managed by the IM in the following fashion, where we assume that the various clocks have different frequencies that are submultiples of the fastest clock. The fastest one is activated by programming the clock control module to apply the number of clock cycles that occur before the next primary-input signal change, slower clock transition, or output sampling operation. The other clocks are treated similarly to normal input signals, and are applied through the IN_interface registers while the fastest clock is held inactive. In this way, the DUV operations are not performed at a steady pace, since each operation requires the execution of one or more IM instructions, but the general bit-true system behavior is preserved. Fig. 2 shows an example of the adopted clocking scheme. In this figure, IM_clk is the main free-running platform synchronization signal feeding the IM; fast_clk is the highest frequency DUV clock, whose bursts are applied by the clock control module, while in_data and slow_clk represent, respectively, the input data and slower clocks to be managed directly by the IM by means the IM_interface registers, during periods when the fast_clk is stopped to let the IM execute the required instructions. E. Shared memories The device under verification can be a complex microprocessor-based system, including different logic and memory cores. Program or data memory areas can be made accessible by the IM (e.g., during software debug) by making them shared, by adding an additional port to the addressed core and suitably connecting it.

For verification purposes, HDL simulation is performed using the Cadence Incisive suite, while mathematical processing and analog models are developed in MATLAB, running on a PC equipped with an Intel E6750 processor and 2 GB RAM. Adhoc software tools have been developed for data conversion and interfacing between the simulation environments and the emulation platform.

IM operations

fast_clk in_data slow_clk IM_clk t

Figure 2. Timing graph showing clocks and input signal operations.

F. Verification support IPs To reduce the computational charge on the IM, the proposed platform enables the integration of customized logic blocks able to perform different kinds of operations. Such modules, called verification support IPs, simplify the tasks of the IM and accelerate specific I/O processes. They include registers that can be programmed by the IM and then autonomously manage the required signals. Examples of such modules will be provided in Section VII. VI.

FLOW AUTOMATION

The costs deriving from the adaption of the co-verification and debug system to a new DUV are minimized as a result of using an automated flow. The HDL RTL description of the DUV is taken as input and, after specifying I/O signals groups, clocks, memories and any appropriate additional internal signals to be observed, a wrapper including the interface and observation registers is automatically produced, together with a customized set of basic library of I/O functions for the IM. The wrapper is imported in the FPGA development environment together with the IM and then synthesis, mapping and routing are performed. Finally, the FPGA is programmed. VII. CASE STUDY The proposed co-verification and debug platform has been employed in the development phases of a new integrated sensor system by Pirelli Tyres S.p.A. The system is intended to be placed within the tire and communicates with the on-board car computing system. An architectural description of the system can be found in [2]. Its general behavior is the following: tri-axial accelerometric data are sampled, filtered and conditioned by means of suitable analog and digital sections, while a bidirectional radio channel is used to transmit pre-processed data to and receive status information and commands from a remote host device. A microprocessor subsystem is in charge of managing the flows of data and synchronizing the operations so as to optimize data computation and power performance. A preliminary version of the proposed platform was employed to verify the hardware implementations of the DSP filtering module alone, and then in interaction with the microprocessor subsystem, as described in [1]. The improved platform presented herein allowed us to validate the noise immunity of the digital baseband channels and to address software debug issues. It has been implemented on a Xilinx Virtex-5 LX development board, and the IM processor selected for the current realization is the Xilinx MicroBlaze soft core.

The first performed task aims at proving the correct implementation of digital baseband transmission and reception modules, working in both directions. Such devices are highly configurable, allowing the use of different encoding algorithms, error correction policies and packet sizes. The validation goal consists in checking the correct transmission of data packets in all possible configurations, also in the presence of noise. To this purpose, for each one-way channel (uplink and downlink), transmission and reception DBB modules have been connected directly, bypassing analog/RF parts and antennas, and a digital channel model has been built. Fig. 3 presents a conceptual schema of the architecture built to validate one of the DBB modules (in this particular case, the downlink ISM channel, where the RX circuit is in the sensor module within the tire, while the TX is in the car body). In this case, two verification support IPs are used. The first one constitutes the digital channel model: it is equipped with a memory core storing noise samples, and is accessible by the IM, which writes the required contents, and by an address manager module, which can be programmed to control the injection of the noise samples on the transmitted data when the transmission is initiated. The second IP is a bus protocol converter, needed to get simple and fast access to the TX module, which features a standard SPI interface. The Parallel/SPI converter receives parallel data from the IM and implements the necessary data serialization and control signal management. The RX module’s parallel interface is accessed through canonical interface registers (omitted in the figure). Channel model DBB TX

Parallel/SPI

Noise adder

Address  manager

DBB RX

Dual port  RAM

Infrastructure  Microprocessor FPGA Host PC Figure 3. Downlink channel validation environment.

Different types of experiments can be performed resorting to the proposed platform, from noiseless data transmissions, aimed at checking the concordance of the configurations in the TX and RX modules, to noisy transmission, useful to validate the implemented error correction techniques. Complex noise samples mimicking real-world conditions can be computed offline (e.g., using MATLAB), and then applied to different module configurations.

1.0 0.9 0.8

C1

C2

C3

C4

C5

C6

C7

C8

C9

C10

C11

C12

C13

C14

0.7

PER

0.6 0.5 0.4 0.3 0.2 0.1 0.0 0.0

2.0

4.0

6.0

8.0

10.0

SNR (dB)

Table II presents FPGA resource occupation figures, showing that the proposed infrastructure requires a moderate amount of the available resources. TABLE II. FPGA RESOURCE OCCUPATION Module LUT [#] Registers [#] DUV Microprocessor Subsystem 1,751 1,325 DSP 5,952 4,111 ISM DBB TX module (downlink) 493 596 UWB DBB RX module (uplink) 2,130 1,328 Infrastructure Microprocessor 1,605 1,342 IN/OUT interfaces 1,634 726 Available resources on Virtex 5 FPGA 28,800 28,800

Figure 4. Packet Error Rate (PER) for the ISM downlink channel in noisy conditions, computed on a set of configurations (C1-C14). TABLE I. EMULATION VS. SIMULATION TIME FOR C10 PACKETS Transmitted packets [#] 100 200 500 1,000

Emu. time [s] 3.72 7.28 17.98 35.86

Sim. time [s] 148 291 724 1448

Speedup 39.8x 40.0x 40.3x 40.4x

Fig. 4 presents the results of a validation experiment based on the injection of Additive White Gaussian Noise (AWGN), conducted to assess the correct behavior of the transmission system when applying different configurations. In the average, a 40x speedup was achieved with the proposed emulation platform with respect to the RTL simulation of the same system. Table I reports the timing figures and the achieved speedup for the transmission of a varying number of packets for a particular configuration (C10). The advantage becomes even more significant when considering the need of repeating the validation flow after each design iteration. Another goal achieved by means of the proposed platform is hardware/software co-verification and debug, for checking the correct system timing and the interaction between the system embedded processor and the peripherals. In this case, a wider system, including the embedded microprocessor, the DSP filtering unit and all the memories, has been mapped on the FPGA. Observation points have been added on the processor bus, so as to enable breakpoint programming based on the fetched instructions and on interrupt signals. In order to debug the synchronization and management routines running in the addressed system, a sequence of operations have to be executed using the IM: 1. Uploading of the embedded microprocessor code in the program memory 2. System activation, with the DUV microprocessor configuring the other system elements 3. System operation, by feeding a stream of accelerometric data to the input channels and reading back the results. To verify the correctness of the synchronization software, different operating conditions had to be checked, while sending various commands to the DUV microprocessor (e.g., on-line changing DSP configuration, going into and out of sleep mode). In this case the complete emulation is about 100x faster than the RTL simulation. The need for additional observation and debug programming increases the IM workload, since additional periodic read operations have to be performed on the interface and observation registers. In such cases, the observed acceleration factor dropped down to about 60x.

VIII. CONCLUSIONS The hardware and software complexity of today’s integrated systems poses serious issues in terms of coverification and debug. In-depth behavior and performance analysis of SoCs is a requirement for guaranteeing product quality, while the verification and debug processes can severely influence development costs and time-to-market. A low-cost system for SoC co-verification and debug has been proposed to tackle these issues, based on emulation over reconfigurable hardware. Together with the device to be inspected, an Infrastructure Microprocessor and other dedicated IPs are mapped on an FPGA and employed as a powerful interface to implement the desired flows. Complete controllability is thus achieved, along with observability of the circuit outputs and of a selection of critical internal nets. To support interactive debug operations, a programmable breakpointing mechanism has been set up, as well as a clock control system enabling step-by-step operations. The required verification and debug flow operations are programmed in high-level software code, exploiting libraries that are automatically adapted to any new targeted device. Hence, low adaption costs and high flexibility are achieved. Experimental results on an industrial case study demonstrate the effectiveness of the approach when applied to different steps of SoC development. REFERENCES [1]

M. Di Marzio et al. “A novel scalable and reconfigurable emulation platform for embedded systems verification”, IEEE International Symposium on Circuits and Systems, 2010, pp. 865-868. [2] S.C. Ergen et al., “The tire as an intelligent sensor”, IEEE Transactions on CAD, Vol. 28, N. 7, 2009, pp. 941-955. [3] R. Turner, “System-level verification – a comparison of approaches”, IEEE Int.’l Workshop on Rapid System Prototyping, 1999, pp. 154-159. [4] Y. Nakamura, “Software verification for system on a chip using a C/C++ simulator and FPGA emulator”, IEEE International Symposium on VLSI Design, Automation and Test, 2006, pp. 1-4. [5] C. Chuang, W. Cheng, C. Liu, D. Lu, “Hybrid approach to faster functional verification for full visibility”, IEEE Design & Test of Computers, Vol. 24, N. 2, March-April 2007, pp. 154-162. [6] K. Oh, S. Yoon, S. Chae, “Emulator environment based on an FPGA prototyping board”, IEEE International Workshop on Rapid System Prototyping, 2000, pp. 72-77. [7] J. Langer et al., “Debug-Tool for Embedded Real Time Systems”, IEEE EUROCON Int.’l Conference on Computer as a Tool, 2005, pp. 599-602 [8] J. Liu, M. Zhu, J. Bian, H. Xue, “A debug sub-system for embeddedsystem co-verification”, IEEE Int.’l Conf. on ASIC, 2001, pp. 777-780. [9] D. Wang, D. Gao, T. Li, “Breakpoint debugging mechanism for microprocessor design”, IEEE Int.’l Conf. on ASIC, 2003, pp. 456-458. [10] J. Lach, W.H. Mangione-Smith, M. Potkonjak, “Efficient error detection, localization and correction for FPGA-based debugging”, IEEE Design Automation Conference, 2000, pp. 207-212.