Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Exploring an approach for improving emulation

Posted: 09 Apr 2015 ?? ?Print Version ?Bookmark and Share

Keywords:SoC? emulation? Internet of Things? IoT? validation?

A good case can be made that SoC-level integration would have been impossible without emulation. We would have no smart phones, no home automation, no smart grid, and no bright future in the Internet of Things (IoT). If you doubt me, consider what large design companies now invest in emulation farms. These rival some server farms in capital, power, cooling, and maintenance costs; depreciation alone of $100k/week is not unusual. But the return in rapid system-level validation and debug amply justifies the investmentuntil it doesn't.

Debug on an emulator is supported by a capability similar to a logic analyser. You select a set of triggers, a set of monitors, and a time window to watch on a trigger event. The emulator architecture can't allow for unbounded triggers and monitors, or for an unbounded window. That would make emulation either impossibly slow or impossibly expensive or both. These factors are limited to what will cover most reasonable debug needs. Capacities ranging from a few million to a few tens of millions of samples are typical. If you know roughly what you are looking for and that the problem occurs within, say a million cycles after a trigger, debug can be very effective. But real functional problems are not always so accommodating. Consider a system failure that appears a couple of trillion cycles after whatever bug caused the problem; andworse yetone that manifests randomly in the system software. This is not a hypothetical concern. A real case we have seen was triggered by a cache-coherency check happening at the same time as a read request to a page set to a non-cacheable purge mode. The detected problem was software-dependent, data-dependent, history-dependent, and far removed in time from the original bug. Issues of this nature might be relatively rare, but a rare event in emulation might happen within days or even hours in real-time usage, making the device impractical for most applications.

We probably can't expect a million-fold increase in emulator debug capacity in the near future, so a more imaginative approach is needed. An obvious solution is to embed assertions, which can be synthesised along with the design and allow emulation to run at very nearly full speed. Assertions can get you closer in space and time to the source of a bug; if one triggers, you immediately have a likely starting point for more comprehensive debug through the logic analyser.

The traditional way to generate assertions has been to create them manually. We tend to think of complex protocol and exception checks needing correspondingly complex assertions. For the emulation need we are talking about here, there are two problems with that approach. First, it takes a long time to think about and debug that kind of assertion, so at the end of the day you don't create very many; assertion density won't be very high and you won't make a large dent in debugging these difficult problems. Second, the assertions you create are unavoidably biased towards what you think might go wrong. To paraphrase a well-known expression, you write assertions for the known unknowns, but not for the unknown unknowns. But it is the unknown unknowns that are most likely to lie behind those long-delayed random failures.

1???2?Next Page?Last Page

Article Comments - Exploring an approach for improving ...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top