Doing ESL design: the earlier, the better

The increasing complexity of systems, demand for better device feature sets, shorter time-to-market, rising global competition and growing cost pressures have combined to make quality systems design more difficult than ever. Moving from the application idea to its realization in silicon is less a rigorous and formal methodology than an art form driven by engineering savvy.

Electronic-system-level design is about scientifically finding the optimal way to map an application onto an architectural target. Implementation takes many forms-from system-on-chip to programmable platform-depending on production volume and revisions.

ESL design representation layers and the role they typically assume have been formalized, as in the documented abstraction layers of SystemC.

At the top, application functionality is captured with an untimed, often executable description in a high-level language. This description is soon constrained by high-level requirements, like timing estimates to form a timed functional representation. Guided by architectural considerations, abstraction refinement continues with transactional, transfer, bus-accurate and cycle-accurate tuning.

These layers sustain adequate design characterization from coarse to more-refined. ESL is a distilled collection of experiences, spanning years and a wealth of designs, all formed into a loose methodology comprising well-understood practices that leverage the abstraction layers.

Do

• Design and verify simultaneously, starting at the highest available abstraction layer and refining from application to target. A functional decision at the top casts a large shadow on choices that come later, so an educated and correct refinement is key for minimizing fruitless design iterations.
• Run system-level simulation as early as possible. Transaction-level simulation is one to two orders of magnitude faster than the traditional "instruction set simulator with bus-functional model" approach. This high-level model can also be used later, where blocks can be swapped gradually with their RTL implementation or purchased intellectual-property function or interface, thereby prolonging the fast evaluation speed before the full implementation simulation.
• Identify and record system transactions as early as possible in the design process, to reap the benefits of the design and verification speedup. If the design process starts with a high-level language that supports transaction-level modeling natively, such as SystemC, then writing transactions can be done easily from the interfaces between the design blocks, and the transaction recording is done implicitly by tools that support the language.
• Use the transaction level as a means for cross-team cooperation on the common development goal. Transaction-level modeling is remarkably suited for bringing system architects and implementation designers together to explore various computation/communication alternatives and to fine-tune matching of the implementation capabilities to the application.
• Perform high-level transaction-based design trade-off analysis.

Don't

• Ignore recording transactions from within hardware verification languages tasked with stimulus generation. Transactions can be recorded from the test scenario generators themselves or from the data items in the design-under-test. Many HVLs, such as Vera and e, have built-in recording facilities as well as a means for calling external third-party routines to do the recording.
• Overlook the ability to record transactions from the software modeling or implementation language, such as C/C++. Designers can expend a one-time development effort to create the classes and method or function calls to a third-party applications programming interface that understands transactions and can record them in its database.
• Forget to use transactions within the implementation hardware description languages, such as VHDL and Verilog. Transactions can also be recorded with system task calls, whether standard (such as in the proposed Verilog 2005 extensions), vendor-provided, or user-written (one-time effort). Moreover, transactions can be recovered from the HDL in an automated fashion through the use of monitor transactors.
• Use IP blocks that do not rely on standard interfaces or that do not come with transaction-level interfaces intended to support an IP-reuse and communication refinement design approach.
• Use tool-interfacing mechanisms- for example, between simulator and emulator-that do not employ transactions to encapsulate data communication. High signal-level activity is the single most serious performance limiter.

Dr. Bassam Tabbara (bassam@novas.com), research and development architect at Novas Software Inc. (San Jose, Calif.).