Optimizing Emulator Utilization

The growing pressures of market schedules, design complexity and the ever-increasing amount of embedded software in today’s SoCs has put verification in the hot-seat. Now that new emulation tools can link hardware and software verification, SoC designers are turning to emulation more than ever before to debug embedded software. The standard method for debugging software with an emulator is with a JTAG probe, but designers have discovered some important limitations with JTAG probe-based debug. In particular, the emulator must stop during software debug, tying up a shared resource that other design teams could be using. A better approach is trace-based, running the entire job on the emulator in batch mode so that all the software debug can be done off-line after the job is completed.

What’s wrong with probe-based debug? Traditional probe-based debug requires the entire debug infrastructure to be in place before it is functional. That means you can’t emulate a work in progress or do incremental emulation runs earlier in the design cycle. Another limitation is how probe-based debug gets information about black-box cores. The JTAG probe interface often runs on a slower clock than the main processor clock to avoid clock domain crossing issues. This slows the speed at which the emulator can execute instructions through the JTAG interface.

As a consequence, you can’t see timing-related problems because the JTAG interface stops the processor as it performs its debug operations. If the processor is stopped, the timing of subsequent software operations also changes, affecting the symptoms of timing-related bugs. Because the JTAG interface is on a different and asynchronous clock, software operations will not occur at exactly the same time from run to run.

Ultimately, emulation is valued for its high speed, which enables higher overall debug throughput. But with probe-based debugging, the emulator stops to let the programmer examine the source code and the state of the system at various points. You can optimize the emulator somewhat with solutions like LSF or SunGrid queues, but the ideal solution is to be able to run the emulator without stopping and then do all the debug work afterward.

Mentor developed its trace-based Codelink replay system to address all these problems with probe-based debug. It takes advantage of the emulator’s ability to access the state of any signal or register in the design at any time, logs signals during emulation and conveys them to the host for processing, then uses them after the emulation run to reconstruct the state of the processor at any time during the emulation. Even though it records a log of the processor’s activity, the developer’s view is not a processor trace but a full-featured software debugger view. The key difference is that while the developer is debugging the software, the emulator is free for other jobs.

By using this with emulation, design teams can eliminate almost all of the waiting that is a normal part of probe-based software debugging. The emulation runs straight through without stopping. The developer interacts with a virtual target that can run on the same host as the debugger, which eliminates the data delays. The virtual target is also processing much less data than the original emulation, so it runs up to 50 times faster.

Both the emulator and the developer are used more efficiently. There are trade-offs to any method of course. You can’t change the execution of the software and then continue a run. But it has significant benefits too. The virtual target can run backward as well as forward, which makes bug hunting, particularly finding non-deterministic problems, easier. The trace is also non-intrusive, provides a more responsive debug environment, and you can run it earlier in the design cycle. Still, the largest benefit is being able to run emulation and debugging separately so a single emulation license can support many more software developers.

Learn more about how Codelink optimizes emulation and the software debugging process in the Mentor whitepaper Optimizing Emulator Utilization.