Closing the ESL gap

By Donald Cramb, EVE -- 6/16/2009

Taken literally, the meaning of the acronym ESL—also known as electronic system level—is pretty clear. However, in the EDA world, it means different things to different people and different things to different design teams. For example, these could include:

• Architectural and performance analysis, both in terms of abstract system modeling and component selection and configuration;
• Presilicon hardware/software integration and development; or
• Presilicon system-level hardware verification.

Plenty of commentary has been written about the promise of ESL and how it remains unfulfilled. Still, the truth is that if you look at this list, engineers have been successfully designing with ESL tools for years. For instance, system architects have been using everything from Excel spreadsheets to MATLAB to architectural workbenches such as Cossap and SPW to architect extremely complex systems.

Software developers are using an array of high-level functional models or virtual platforms, both internally developed and also from a number of companies such as CoWare, Virtutech, and Synopsys, for presilicon software development and integration. Imperas is making these platforms even more widely available by making its offerings, in part at least, open source and free. Pure open-source platforms are available, as well.

Traditional emulation approaches, such as in-circuit emulation (ICE), have provided the ability to accelerate register transfer level (RTL) code to a point where it is possible to run in a real system.

We’re not quite where we should be with ESL. What has been missing is the link between the models used by architects, software developers, and system integrators and the actual implementation of the design under test (DUT). In the end, until software is running on the actual RTL code, there is still risk that the software and hardware will not work together properly. Similarly, until performance is analyzed at the cycle level, there is an inaccuracy that in the end may not be acceptable.

This missing link has become known as the ESL gap—that is, the gap between ESL methodologies and the RTL code.

In the past, EDA vendors have attempted to bridge this gap in a number of ways. One effort translates a functional model to RTL code. The problem here is that this addresses only the DUT translation. Running the software environment and the RTL code is still not possible.

Read more Guest Opinions

Another is ICE, where the RTL code is accelerated, but it is still not the ESL environment the developer has used prior to RTL code availability. The gap is still there and it is also not scalable.

The ESL gap still exists today. In order to bridge the gap, what is needed is the ability to integrate the RTL code with the existing ESL methodology. To meet this requirement, the RTL code must be accelerated to run billions of cycles. As well, the connection between the ESL tool and the accelerated RTL code must be well-defined and efficient so that the functional model is not throttled by the interface.

One approach gaining heading in the battle to eliminate the ESL gap is hardware emulation. Emulation, such as ZeBu from EVE, is being used in the hardware/software codesign flow as hardware engineers and software developers share system and design representations and work together to debug hardware/software interactions.

With more design teams moving to ESL, emulation is becoming a popular and effective verification tool, and helping to eliminate the ESL gap.

Author Information

Donald Cramb is director of the Consulting Services Division of EVE-USA in San Jose, California, and is responsible for customer services, applications, and design solutions to support specific customer requests. Previously, he was a partner at ArchSilc Design Automation, a company focused on system-level verification solutions. Earlier in his career, Cramb was director of Services at Quickturn, where he helped expand its offerings into key target markets, including wireless, graphics, multimedia, and networking. He went on to become vice president of technical services for three years at Virtio and held a similar position at Tharas Systems. After graduating with a bachelor’s degree in electrical engineering from the University of Edinburgh, Cramb spent 11 years employed by Philips in the United Kingdom and Silicon Valley. He began his career as a design engineer.

© 2009, Reed Business Information, a division of Reed Elsevier Inc. All Rights Reserved.