It's only a matter of time before software engineers and hardware designers working on embedded systems will learn to work together in an efficient and seamless manner, which is not the case today. They currently speak different languages, work in different domains and don't understand the synergies between the two disciplines.

Here's a classic scenario, the case of a software engineer debugging a device driver. At cycle 10 million, some peripheral bus has a deadlock, and the chip freezes. This software engineer goes to see the hardware designer and announces: "You have a bug in the hardware!" Of course, the software engineer is going to assume the bug is in hardware, not the software.

The hardware designer says: "Sure, I'll be happy to fix the bug, just give me some waveforms."

The software engineer responds: "Sorry, I don't have waveforms." Instead, he was using a field programmable gate array (FPGA) platform connected through Joint Test Action Group (JTAG), an IEEE standard for boundary scan technology, to a software debugger.

Now, the hardware designer has to try to reproduce the problem. He starts a register-transfer level (RTL) simulation, which creates a variety of problems and added complexities.

The first problem: Reaching cycle 10 million will take a while with RTL simulation, even using acceleration.

Problem number two: How does he reproduce the exact test case that created the bug? That sends him back to the software engineer, where he asks: Can you tell me how the bug occurred?"

Responds the software engineer: "Sure, I was in function such and such, then I single-stepped a few times, and then the chip froze."

The hardware designer replies: "Here's the logic simulator. Can you reproduce the problem in simulation?" To which the software engineer gasped and said: "No way! I don't know how to use an RTL simulator. All I know is gdb."

While this may seem like a Laurel and Hardy comedy skit, in reality, it's a typical example of the incomprehension between software and hardware teams when doing debugging. They waste valuable project delivery time going between the two worlds to identify and fix problems in different domains.

Let's take a closer look at the problem. Now a days, system-on-chip (SOC) designs include one or more 32-bit embedded microprocessors, running significant numbers of applications, often totaling hundreds of thousands of lines of code. The chip also includes custom logic to accelerate processing of key data, such as image processing or packet identification and routing.

Finally, the chip connects to peripherals and physical interfaces appropriate to the SOC's target application. Verification of each of these hardware blocks and validation of the embedded software impose specific requirements on the tools and methodologies used by designers.

Microprocessors, processing vast amount of embedded software, require speed, as billions of cycles become necessary to obtain meaningful results from complex applications. Embedded software development mandates the use of software debuggers. Custom logic blocks need accurate RTL simulation with access to waveforms. Peripherals also require accurate simulation to verify the interaction between device drivers and peripherals, as well as efficient transfer of data in and out of the chip.

Today, all of these problems are solved separately, using one of three independent technologies.

Hardware emulators provide the desired level of accuracy, speed and visibility to RTL simulation, albeit at an exorbitant cost. Full visibility of internal signals and embedded logic analyzers make them the tool of choice for hardware engineers. Alas, they don't interface well with embedded software and their price tag restricts their usage to a few high-end chip projects.

Traditionally, software developers validate their code using Instruction Set Simulators (ISS). However, and despite their popularity, they suffer from a few limitations.

First, they are not cycle-accurate. And second, they don't fully support interfaces to custom RTL blocks, if at all. That is why more and more software developers turn to FPGA prototypes that use JTAG to connect to a software debugger.

On an FPGA prototype, cycle-accurate code runs at speeds that are orders of magnitude faster than an ISS. Once manufactured in small quantities, thus amortizing the engineering cost, FPGA prototypes are fairly cheap to build, making them ideal vehicles for adoption by large software development teams.

Regrettably, debugging hardware on an FPGA prototype can be difficult, particularly for complex SoCs that are larger than one million ASIC Gates, leading to late availability of the FPGA prototype for software developers.

By merging advantages of a hardware emulator, such as accuracy and internal visibility, with those of the FPGA prototype, which include speed and low cost, a verification vehicle could be offered for both hardware design and software development.

A third technology, called transactors, can play a pivotal role in the above verification/validation tasks. By raising the level of abstraction of physical interfaces from the cycle/bit-level to the transaction level, transactors can simplify the description of data exchange between an SOC and its peripherals or physical interfaces.

However, when transactors are executed in the software domain and called software transactors they do not alleviate the performance bottleneck that afflicts the verification task. But, by creating synthesizable transactors as defined in the upcoming SCE-MI standard and mapping them inside an emulator to execute at emulation speed or hardware transactors they can significantly speed-up the stimulation/monitoring of peripherals.

Hardware transactors can become a viable alternative to the traditional in-circuit-emulation (ICE) driven by a target system. Unlike ICE, hardware transactors benefit from being controlled by software, which allows for building a smart verification environment distinguished by a level of flexibility and by the ability to be re-used impossible in ICE. For example, a designer can capture and replay traffic from live hosts, mimic in-circuit connections by forwarding transactions immediately between the device and the chip, or apply transformations to the transaction stream to exercise hard to reach corner cases.

The time has come to merge all of these technologies into one platform that solves the hardware/software co-verification gap and makes the opening dialogue a story of the past. A platform that retains the hardware debugging environment of the high-end hardware emulator, but not its excessive cost, performs at the speed of the software development board, and can be controlled in software via the transaction-based technology. Let's call it the "Transactional Emulation Prototype," a prototype in the sense that it contains an actual implementation of the hardware design that connects to live interfaces. At the same time, it's a software development environment that maximizes flexibility, analysis and reuse, and sells at a cost of a perpetual software simulation license.

Such a platform will offer a common ground for Intellectual Property (IP) vendors and users, with the potential to dramatically reduce the cost of developing SOCs and get hardware and software engineers to work together.

Alain Raynaud (alain@eve-team.com) is Technology Center Director at Emulation and Verification Engineering (EVE), San Jose, Calif.