Electronic System-Level Design Tools:System-Level Design Tools.

Introduction

Electronic System-Level (ESL) design covers most of the whole electronic product. ESL includes the integrated circuits, power, and electrical and human interfaces.

A single IC can now contain most of the system electronics. Therefore, system-level design is often a part of the IC design. Software now resides on the IC as well, so we include embedded software as part of ESL design.

Let us join Nora as she learns about ESL design tools from Sam. He is a system engineer at SysComInc.

Nora:

Thanks for helping me prepare for tomorrow's product meeting, Sam. Will one of our Sandbox tools help you design your planned product?

Sam:

Yes, but actually it is our customer who is planning a new product. We are going to help their team define what they really want and need.

Nora:

Don't they already know what they need?

Specification Guidelines

Sam:

Yes and no—they have some ideas, but are unclear as to what can and cannot be done in a reasonable time and cost. There are usually several ways to solve a problem, and we can help them there. We follow guidelines to produce a useful requirements document. The requirements specification process is usually iterative.

Sometimes we discover constraints which no one mentioned or implied. These might be factors such as budget, time, management approval, existing environment, or user preferences.

Ideally, a knowledgeable customer, a knowledgeable marketing person, and a knowledgeable engineer can learn from each other. (Although that is admittedly an unlikely trio.)

There are some tools to help with the generation of requirements analyses and documentation.

Nora:

So an early meeting is important. After you get the specification well-defined—what next?

System-Level Design Tools

Sam:

I think Andrea showed you a table of major design tools. Let me show you that table again, with the system-level tools highlighted. (See Table 5.1.)

Engineers use programming languages or graphical block design tools to enter design ideas into the computer. They use modeling tools to help make design trade-offs and try out ideas and different approaches to the problems. Test benches provide a test environment for easier design verification. Initial timing analysis helps predict the system performance.

Table 5.1. Major ESL Tools

ELECTRONIC SYSTEM-LEVEL (ESL) DESIGN

Users

Tools

Architect

ESL Design Entry

System Engineer

ESL Modeling

IC System Engineer

ESL Verification (Bench Test)

ESL Timing Analysis

FRONT-END (FE) DESIGN

REGISTER LEVEL

Users

Tools

RTL Entry

System Engineer

Test Bench

Logic Designer

RTL Simulation

ASIC Designer

Formal Verification

Test Engineer

Design for Test

Timing Design

Thermal Design

Power Design

Signal Integrity Design

Synthesis to Gates

GATE LEVEL

Users

Tools

Schematic Capture

Logic Designer

Gate-Level Simulation

ASIC Designer

BACK-END (BE) DESIGN

Users

Tools

Floorplanning

Layout—Place & Route

Layout Designer

Electrical Rules Check

Logic Designer

Physical Rules Check

ASIC Designer

Extractors & Delay Calculators

Test Engineer

Timing Analysis

Power Analysis

Thermal Analysis

Other Analyses

High-Level Modeling

Sam:

High-level modeling tools help estimate interactions between factors such as performance, power, weight, cost, and so forth. Problems such as traffic congestion on a highway or an inter-processor data bus are often modeled. Modeling helps ensure that the design can handle the traffic and avoid bottlenecks.

An architect makes sketches of different house plans to see how they meet the customer's needs. An interior decorator may experiment with several color combinations for a room. Similarly, the system designer may modelparts of the design on the computer.

Nora:

What tools do they use?

Sam:

Design architects usually model suspected problem areas using whatever software language they know best. Many use a variant of the general-purpose C language.

Other languages are useful for specific areas such as communications and multiprocessor systems. Usually, only the major unknown areas are modeled or estimated (e.g., power, performance, bottlenecks, or area).

Nora:

They don't model the whole system?

Did You Know?

Computer modeling is widely used to test ideas before building the actual bridge, building, airplane, spacecraft, or electronic system. Almost any characteristic or situation can be modeled: power, speed, traffic flow, or catastrophes.

System-Level Design Languages

Sam:

Not usually, because the modeling effort would take too long. Sometimes, the whole system may be modeled at a very high level for interface or demonstration purposes. Often though, there are just a few areas which the engineers are not sure will work.

We need a single design language to describe the whole system, both hardware and software. Programmers want it to be compatible with the design software languages they use. Hardware designers want it to be compatible with the hardware design description languages they use. System architects want it to capture all the constraints of the system. They also want to be able to model the whole system or just parts.

Nora:

So is there a common system description language now?

Sam:

Not yet. Neither the basic C programming language nor a hardware description language has enough of the necessary features. Different new constructs have been added to both. These are competing forms and extensions of the C language and C++. Extensions of hardware description languages used for FE design (Chapter 6) are also competing. Several groups are trying to standardize one or more of these (complementary or competing) system description languages.

Nora:

So a system-level language is coming, someday?

Sam:

Yes, they are making progress.

Design Space Exploration and Trade-offs

Sam:

There are always several approaches to addressing the project goals, with many conflicting or interacting constraints. System design evaluates these interactions. The system engineer must make trade-offs based on the evaluations.

Nora:

Can you give me a few examples of trade-offs?

Sam:

Trade-off factors may include size, cost, power, performance, development risk, beating the competition, or time to market. Many of these factors interact. The designer may trade off (evaluate) designing a slower IC in order to reduce the power for longer battery life. The goal is to achieve the best balance, satisfy all the requirements, and reduce the design risks.

Increasingly, the system functions are done with on-chip software. Therefore, a key decision is which functions to do in hardware and which in software. Implementation in hardware runs much faster but costs more and is harder to change. Modeling the design both as hardware and as software helps the system engineer make the decision. The result is a partition of the design into hardware functions and software functions.

Let me sketch you an example of the multilevel balancing of trade-offs. (See Figure 5.1.)

This shows only a few of the trade-off comparisons needed. For instance, I show cost against product volume and time-to-market. However, cost is also a trade-off with features such as speed and power. Furthermore, speed depends on power and chip size.

At another level, you have the hardware/software trade-off to make. This also impacts development time and time-to-market. Note also the trade-off decision between using in-house expertise and outside consulting.

Another trade-off decision involves what design pieces already exist that can be re-used and what portions must be a new design. Using existing portions of hardware or software already known to work reduces the design risk.

The high-level, fuzzy aspects include project costs, development time, market needs and risk. These all interact with detailed factors such as speed, power, size, and functional features. So trade-off decisions are more complex and intertwined than they first appear.

In addition, we also have all kinds of constraints, legal restrictions, and design rules. For an electronic system or integrated circuit, the constraints include chip size, cost, and power. Others are clock speed (performance), and TTM. Sometimes they are rigid constraints, sometimes only preferences. The constraints form a series of fences or boundaries. We use EDA tools to work within the area or design space defined by the constraint boundaries.

A system engineer may model several trial designs to make intelligent trade-offs within the design space. What happens to the chip power and cost if we design for performance? Is 25% lower power more important for the application than 10% higher speed? This what-if process is known as design exploration, and may affect the final specification.

Nora:

I see that a lot of hard choices get made, Sam. How do the engineers know if their final design choices will work?

Did You Know?

The more standard parts one can use in a chip design, the easier and faster it is to implement. Chip designers can choose from large libraries of standard parts. They try to minimize the amount of custom design work, particularly on large chips.

Predesigned blocks of memory, processors, I/O controllers, and so forth are called Intellectual Property (IP), cores, macros, or virtual components (VCs). (These may be able to be dropped into a design as complete units.)

Test Bench Creation

Sam:

That's an excellent question. The ESL design team must develop system-level tests which verify that the design works as designed. The tools must also validate that the system does what the customer expected.

It takes a lot of work to develop an environment for testing a system design. Test bench creation (automatic or semi-automatic) is another kind of system-level tool.

A test bench is a model of the external world within which the system (or subsystem or chip) is used. It can generate the inputs to stimulate the system under test, and measure or display the outputs of the system. It assists the designer in verifying and validating the system design.

Testing or troubleshooting identifies the causes of design or test problems. Removing or fixing the problems or bugs is called debugging. And retesting after fixing a bug is important to ensure that the fix did not create a new problem.

Nora:

So an EDA tool helps create a test bench?

Sam:

Yes, the tool helps both create and operate it. Test bench tools are getting more intelligent all the time. The earlier a problem is identified in the design process, the lower the cost to go back and fix it.

The data volume, tool cost, and people cost are highest in the back-end. Most labor (and design problems and bug-fixing) historically takes place in the back-end design.

Nora:

I've even heard about bugs on the news, especially when they involve Intel or Microsoft.

Sam:

Yes, even large companies cannot check everything. Reporting on bugs can be worldwide news items, not just a local embarrassment.

Nora:

You mentioned predicting chip performance. How do you do that?

Sam:

We do that using static and dynamic timing analyzers. These EDA tools are used at several levels in the design sequence. Static analyzers add up all the block, gate, and wire delays to uncover obvious timing problems.

Dynamic analyzers calculate delays while simulating the actual chip operation. Both help identify potential timing bottlenecks. Engineers need to know about timing problems as early as possible to ensure system performance (speed).

Nora:

What other system-level tools are there?

Did You Know?

Verification and validation of chips is a very difficult and time-consuming process. A chip may have hundreds of inputs and outputs and perform dozens of operations. It could take many years to test all possible sequences. For example, a computer chip must handle all kinds of data (numbers, text, pixels, etc.) It must handle many possible errors (caused by noise, failed connections, misroutings, and the like).

Just adding a long series of numbers in every conceivable order could take hours. In practice, one cannot test everything. The designer must select a reasonable set of test cases that covers all the common situations. However, it must not take a ridiculously long time to check. Usually, the designers check only typical values and boundary cases (values at the minimum or maximum points).

Other System-Level Tools

Sam:

We have many complementary EDA tools to assist the system engineer. A few of them are:

• Editors, compilers, debuggers, and other tools for high-level design languages

• System-level timing and throughput analysis tools

• Special tools for specific applications such as Digital Signal Processing (DSP) design, communications system design, embedded system design, or multimedia chip design

• Special tools for FPGA design and other specific hardware implementations

• Analog, mixed-signal, and RF design tools

Nora:

What are the last three?

Sam:

Wireless products use radio frequency (RF) circuits. Analog circuits work with continuously varying signals found in the real world (non-digital). Analog signals may be from voice, temperature, pressure, sound, or light sensors. Mixed-signal circuits convert analog signals to digital and vice versa. (See also Appendix C.)

Did You Know?

Analog portions of a system IC are typically only 5% of the total chip. However, they are often the limiting factor in the system performance.