A look inside electronic system level (ESL) design

Vincent Perrier
(03/26/2004 7:00 PM EST)

  We all know that ESL stands for Electronic System Level design, and per Gartner Dataquest's definition, it encompasses the concurrent design of the hardware and software parts of an electronic product.

However, the important word in ESL is "system." All designers probably have their own definition of what a system is, depending on the subset of the product they're working on, and at which design stage. The difficulty for them is finding the right ESL design tool adapted to their needs and their vision of what their system is.

What really is the difference between ESL tools, and what are the key questions designers should ask themselves to find the right tool that will help them do their job faster and more easily?

Rather than starting a debate on what exactly the "system" in ESL should mean and proposing my own (debatable) definition and vision, I would like to take the opposite approach and start from the designer's needs. First, we all have to acknowledge that there are many sorts of ESL design tools targeting different visions of what a system is and thus, offering various benefits to system designers.

The problem is that ESL tool vendors all talk about the same advantages they offer to their users. These may include:

• System-level design
• HW/SW co-design
• Architecture exploration
• Virtual prototyping
• Co-simulation/co-verification

All the above may be true, but designers need to understand precisely what's behind those common terms and what is exactly achieved by the considered tools.

ESL design stages

The first thing to identify is at which stage of the design you are and what do you need ESL design tools for. For that, we need to define boundaries for ESL design.

A design activity usually starts from some sort of description of what the system does, called "specifications." The description can be of many kinds: text in natural language, schematics, algorithms, UML diagrams, SDL models, mathematical representation with tools like The MathWorks' MATLAB or Simulink, or state charts. Tools delivering such capabilities can't really be considered as ESL design tools, but rather as system-level analysis tools. Usually, the paradigm they support is specific and adapted to the application domain they target.

System design aims at describing how the system does what it's supposed to do, and at providing a solution for further implementation. ESL design ends where implementation starts, with implementation models for all software and hardware elements in the system. These include:

• Embedded software application: code in software programming language (usually C or C++).
• Custom integrated circuits: code in hardware description language (usually VHDL or Verilog.)
• Hardware platform (either components of a PCB or IP blocks of a SoC, with their interconnections): some types of models or SystemC code, for example.

Within the boundaries defined above, we can identify two main stages in ESL design:

• Functional design
• Architectural design

Functional design aims at describing the system's behavior from an internal viewpoint, including structure, communications and elementary activities/ behaviors. Two important aspects can be highlighted:

• Functional design focuses on the system's application (designers think in terms of solving their problem).
• Functional design is free of physical or technological considerations (designers don't think in terms of hardware or software yet), as well as independent from any programming language.

Architectural design aims at describing the system's architecture in terms of the required hardware platform and organization of the application deployed on this platform (HW/SW partitioning).

ESL design objectives

At this point, you can already determine at which stage in the ESL design process you are, depending on whether you're designing the application (or part of it) or only the platform. The design stages are then refined as:

• Functional design
• Application-driven architectural design
• Platform-oriented architectural design

Different design objectives and problems correspond to each stage, as described in the following table.

Table 1 — ESL design stages

At this point, another differentiation appears between design styles applied to two different design stages — top-down and bottom-up.

Functional design and application-driven architectural design typically follow a top-down design style as they start from the application. Platform-oriented architectural design (also called "platform-based design") typically follows a bottom-up design style by aggregating existing components (IP blocks) together. Top-down and bottom-up processes meet at a point called "meet-in-the-middle" that I described in a previous article.

ESL design input

A model of the system is developed at each design stage. The way the model is captured can also make a big difference, especially in terms of productivity. There are basically two types of input — graphical and textual.

Graphical entry is known for facilitating representations of organizational views: structure and communications. Textual entry is usually effective at describing detailed behaviors, such as algorithms and state machines.

It is important that an ESL design tool accepts input models of the previous design stage, as well as generates output models suitable for the next design stage. If a complete design chain is broken between two incompatible design stages, it's likely that the expected productivity gains won't be met. In addition, input formalisms should be natural and intuitive to designers for effective use.

ESL design abstraction levels

Another factor that differentiates ESL design tools is the abstraction level at which they operate. The abstraction level is largely related to the design stage and models considered for the tool. The earlier the stage in the design process, the higher the abstraction level.

Also, integrating reusable blocks of IP into a particular model requires compatible abstraction levels between the reused IP and the rest of the model, or at least bridges between levels. Most of today's IP blocks are available either at the register transfer or transaction level for hardware, and either source or object code for software.

The abstraction level at which ESL design tools operate is crucial as it defines the following:

• Granularity level of models, especially how HW components (processors, buses) of the platform are described.
• Type of technology that is required for simulating models.

In turn, granularity of models and simulation technology have a great influence on the capacities of ESL design tools for architecture exploration and performance analysis.

The following table highlights the main differences for each abstraction level.

Table 2 — Abstraction levels

Each abstraction level proposes a tradeoff between the architecture exploration cycle period (defined by the simulation speed and time to make changes in the architectural model) and the level of details obtained.

A prospective architecture exploration cycle aims at trying various HW platforms (5 or 10 processors? FPGA or not? Bus or network?) very quickly (in minutes), without writing a line of code or modeling new HW components. It is possible only if the HW platform is described at a high level of abstraction, without too many details, using generic components (processor, bus, memory) characterized by universal properties (speed, concurrency, cycle period).

Once a first "blueprint architecture" is obtained from prospective architecture exploration, confirmative exploration can help fine-tune characteristics of each HW component (CPU architecture, bus topology, cache levels). Such exploration requires specific models of each HW component at the required abstraction level, which development could take several months. Hence, most ESL design tools operating at this level come with a library of models of components.

A new generation of tool

Going back to our introductory paragraphs, we have now in our hands more information to understand what's behind some of the common terminology used in ESL design tools' data sheets.

Existing ESL design tools are basically of two sorts:

• Mainly focusing on functional design, the first come from the specifications domain to reach the embedded software application development field (top-down process).
• Mainly focusing on platform design, the second come from the EDA space and are moving up the abstraction layers, from RTL to transaction level (bottom-up process).

But what about true capabilities for HW/SW co-modeling and application-level architecture exploration, based on prospective performance analysis? It clearly appears that a new generation of tool is required to bridge the gap between exiting ESL design tools. Such tool, called an SDE (System Design Environment), should address the functional and application-driven architectural design stages, and reach both the software and hardware domains.

Using the differentiation factors we described previously, the following table summarizes what's needed for an SDE compared with what's offered by other ESL tools targeted at platform-based design.

Table 3 — How SDEs are different

Taking only the functional design activity into consideration, an SDE should offer additional capabilities compared to other ESL design tools targeted at embedded software development only. In essence, an SDE should provide a link to the hardware world and extensive architectural design capabilities that are not found in software-oriented ESL design tools.

The following diagram summarizes the system design dynamics induced by the use of an SDE. As the functional and architectural design activities tend to automate and accelerate the creation of the embedded software and hardware platform, they strongly influence the effort spent at the different steps of a project. It results in a shift of part of the effort spent in implementation up to the more productive functional and architectural design step.

Figure 1 — SDE system deisgn dynamics

In the end, it should result in shorter time-to-market and reduced NRE costs.

Vincent Perrier is co-founder and director of CoFluent Design, provider of the CoFluent Studio SDE. Vincent has 10 years experience in the embedded systems industry and with design automation tool providers. He started as software developer, and then joined Telelogic as consulting and sales engineer. Before creating CoFluent, he spent 5 years as application engineer and marketing manager with Wind River Systems.