How ESL becomes a business imperative

Jon McDonald
(01/17/2005 4:00 PM EST)

  Nearly 70% of embedded system designs fail to meet performance expectations by 10% or more, and about one-third miss by 50% or more, according to a recent survey of designers by research firm Embedded Market Forecasters¹. Moreover, about 30% of designs miss the functional specification by more than 50%, and about one-third of designs are completed behind schedule by an average of about four months.

These failure statistics represent not only a technical challenge, but also a business opportunity. Companies that can improve significantly upon these statistics will establish a competitive edge. Adopting a design methodology to fix these problems is therefore not just a technical decision, it is a business imperative.

In 65% of the cases of missed targets, the reason for failure was given as "limited visibility into the complete system". This is the key to identifying the solution.

Electronic system level (ESL) design is often presented as system-on-chip (SoC) design performed at a level of abstraction above RTL. It is much more than that. It unites the historically separate hardware and software design flows into one integrated embedded system design flow, and it applies as much to board-level systems, boxes and networks as it does to chips.

ESL design enables the performance analysis and functional verification of complex architectures and protocols very early in system development. At this high level of abstraction, the designer can run large numbers of test cases to identify and fix the corner case problems that are all too often discovered only at system integration and bring-up — and often too late for effective corrective action. ESL design thus affords the designer that vital "visibility into the complete system".

Summit has compiled a list of the symptoms that indicate that adoption of an ESL design methodology is necessary, based upon observations of its customers' decisions.

Indicator #1 is obvious. If your company is suffering the kind of hit-and-miss performance and functionality statistics outlined above, it's time to change to an ESL design methodology.

Of course, many system designers have for years used C/C++ ESL hardware modeling to evaluate system traffic and storage characteristics. This offers some confidence that the system has the hardware resources to deliver the requisite functionality. However, C/C++ models do not capture the timing data or system concurrency characteristics necessary to model and evaluate the performance of real hardware.

The SystemC language was developed to capture such system attributes. SystemC models can be equipped with the parametric data that enables the analysis of system performance characteristics, such as data throughput, datapath latencies, and power consumption, as well as the utilization of processing units, memory and system buses.

Using SystemC, the designer can model the entire system hardware in terms of both functionality and timing — up front — and make the architectural modifications and optimizations necessary to deliver the requisite performance. These architectural models are simulated using system-type transactions — function calls and packet transfers — and are thus called transaction-level models (TLM). The system level functional testbench developed in this process is used to verify the hardware implementation.

As an example of the power of ESL design, one of our customers used ESL to analyze the trade-offs involved in designing a highly scalable router. These included definition, analysis and optimization of the scaling algorithm, scheduling, traffic and storage management, redundancy and performance. The company saved 24 engineer-months of effort — and the design was right, first time.

Indicator #2 is also performance-related. At system integration and bring-up, the design team discovers that system performance is limited by the sheer volume and complexity of the embedded software. This is not unusual in the case of a legacy design to which more software has been added, but it happens in new designs, too.

Incremental performance improvements may be achieved by optimizing the software and/or increasing the processor clock frequency, the latter at the cost of increased power consumption. However, to significantly accelerate software execution often requires a time consuming re-architecture of the system, possibly including processor upgrades and the deployment of coprocessors.

Such an approach is particularly problematic when the system design is targeted at an SoC implementation. There may not be a higher performance version of the SoC platform's central processor unit, or such an upgrade may be prohibitively expensive. Worse, the requisite algorithm acceleration may be possible only with the use of dedicated non-programmable hardware engines, which changes the original HW/SW partitioning, and can affect other parts of the design.

With an ESL design methodology, HW/SW partitioning is determined with the use of up-front performance analysis that identifies the bottlenecks long before implementation. The need for additional processing capacity and/or the deployment of dedicated hardware accelerators is identified while there is still time available to satisfy the need.

Indicator #3 is a time to market issue. Some of the software code is still in debug long after the hardware design is completed, and increases the elapsed design time.

Generally speaking, software development can begin as soon as the algorithms and target processor(s) are defined, enabling parallel hardware and software design. Also, extensive re-use of legacy software significantly increases productivity and reduces the bug count.

Nonetheless, each product generation requires the development of at least some new software — and, often, a lot. This is the "known unknown" that causes no surprises when it malfunctions at system bring-up.

The use of an ESL design methodology enables the co-design and co-verification of hardware and software earlier in the flow. The SystemC TLM of the system architecture is used as the software development platform. Timing-independent co-verification ensures that the algorithms are correct and executed correctly, while cycle-accurate co-verification ensures that they are executed with the requisite performance. Software malfunctions are identified and debugged before system hardware implementation is complete.

Indicator #4 pertains to SoC design. Your latest SoC design, based upon an RTL integration platform methodology, is in trouble, it has happened before, and it is happening at an increasing rate.

SoC "gate count" is many times greater than it was even only three or four years ago. But much of the additional "gate count" is due to the deployment of multiple processors, memories and third party "black box" intellectual property (IP) blocks.

However, RTL design is a logic implementation methodology — it is simply not capable of designing a multi-processor system with complex protocols, and its low level of abstraction makes its use as an IP integration and evaluation methodology tedious. Consequently, the RTL design methodology applies to an ever-decreasing proportion of the chip, and designing an SoC with an RTL integration platform will result in an increasing design failure rate.

An ESL design methodology is targeted at precisely the problem that RTL design methodology cannot solve — the multi-processor system and complex protocol design challenge. Moreover, SystemC models of third party "black box" IP may be integrated into the SoC's TLM platform, and performance analysis executed much more quickly than at RTL. Consequently, third party IP providers are increasingly supplying SystemC models of IP.

The system-level testbench developed during architectural design and optimization is used to verify the upper-level functionality of RTL blocks. This does not necessarily eliminate the need to verify those blocks with established RTL verification methodologies, but it does ensure that they conform functionally to the system specification.

Very importantly, ESL verification executes multiple orders of magnitude faster than RTL verification, which executes at the lower, logic level of abstraction. Consequently, SoC designers can rapidly design, analyze and verify multiple candidate SoC architectures to identify the optimum solution.

ESL design and verification is thus the system design front-end for the SoC, and the TLM model of the SoC is the new integration platform for derivative design, while RTL design is the logic implementation design back-end for some of the SoC.

A further example of the power of ESL design: yet another router design company migrated to an ESL design methodology after its established C/C++ performance modeling and hardware-accelerated functional verification flow failed to detect network performance shortfalls and identify their source(s). Modeling the entire system at the system level, the company characterized the performance problem, identified the source as an architectural limitation of the SoC design, and solved it with a new SoC architecture — designed, analyzed and optimized within the ESL environment.

In summary, ESL is not just about designing a chip at a higher level of abstraction. The main driver for adopting a SystemC-enabled ESL design and verification methodology is that it solves the performance, functionality and schedule predictability problems of embedded system design — whether the product is an SoC, a board, a box or a network. This is what makes a proven complete ESL environment a business imperative that you cannot afford to overlook.

[1] Embedded Software Development: Issues and Challenges. July 2003.

Jon McDonald is technical director of ESL provider Summit Design Inc.

All material on this site Copyright © 2005 CMP Media LLC. All rights reserved.
Privacy Statement | Your California Privacy Rights | Terms of Service