Embedded system design modeling synthesis and verification

Embedded System Design


Daniel D. Gajski • Samar Abdi
Andreas Gerstlauer • Gunar Schirner

Embedded System Design
Modeling, Synthesis and Verification


Daniel D. Gajski
Center for Embedded Computer Systems
University of California, Irvine
2010, AIR Bldg.
Irvine, CA 92697-2620
USA


Samar Abdi
Center for Embedded Computer Systems
University of California, Irvine
2010, AIR Bldg.
Irvine, CA 92697-2620
USA


Andreas Gerstlauer
Department of Electrical &
Computer Engineering
University of Texas at Austin
1 University Station C0803

Austin, TX 78712
USA


Gunar Schirner
Center for Embedded Computer Systems
University of California, Irvine
2010, AIR Bldg.
Irvine, CA 92697-2620
USA


ISBN 978-1-4419-0503-1
e-ISBN 978-1-4419-0504-8
DOI 10.1007/978-1-4419-0504-8
Springer Dordrecht Heidelberg London New York
Library of Congress Control Number: 20099931042
© Springer Science+Business Media, LLC 2009
All rights reserved. This work may not be translated or copied in whole or in part without the written
permission of the publisher (Springer Science+Business Media, LLC, 233 Spring Street, New York, NY
10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection
with any form of information storage and retrieval, electronic adaptation, computer software, or by similar
or dissimilar methodology now known or hereafter developed is forbidden.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are
not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject
to proprietary rights.

Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)

Preface

RATIONALE
In the last twenty five years, design technology, and the EDA industry in particular, have been very successful, enjoying an exceptional growth that has been
paralleled only by advances in semiconductor fabrication. Since the design
problems at the lower levels of abstraction became humanly intractable and
time consuming earlier then those at higher abstraction levels, researchers and
the industry alike were forced to devote their attention first to problems such
as circuit simulation, placement, routing and floorplanning. As these problems become more manageable, CAD tools for logic simulation and synthesis
were developed successfully and introduced into the design process. As design complexities have grown and time-to-market have shrunk drastically, both
industry and academia have begun to focus on levels of design that are even
higher then layout and logic. Since higher levels of abstraction reduce by an
order of magnitude the number of objects that a designer needs to consider, they
have allowed industry to design and manufacture complex application-oriented
integrated circuits in shorter periods of time.
Following in the footsteps of logic synthesis, register-transfer and high-level
synthesis have contributed to raising abstraction levels in the design methodology to the processor level. However, they are used for the design of a single custom processor, an application-specific or communication component or
an interface component. These components, along with standard processors
and memories, are used as components in systems whose design methodology requires even higher levels of abstraction: system level. A system-level
design focuses on the specification of the systems in terms of some models
of computations using some abstract data types, as well as the transformation
or refinement of that specification into a system platform consisting of a set
of processor-level components, including generation of custom software and
hardware components. To this point, however, in spite of the fact that sys-


vi

EMBEDDED SYSTEM DESIGN:

tems have been manufactured for years, industry and academia have not been
sufficiently focused on developing and formalizing a system-level design technology and methodology, even though there was a clear need for it. This need
has been magnified by appearance of embedded systems, which can be used
anywhere and everywhere, in plains, trains, houses, humans, environment, and
manufacturing and in any possible infrastructure. They are application specific
and tightly constrained by different requirements emanating from the environment they operate in. Together with ever increasing complexities and market
pressures, this makes their design a tremendous challenge and the development
of a clear and well-defined system-level design technology unavoidable.
There are two reasons for emphasizing more abstract, system-level methodologies. The first is the fact that high-level abstractions are closer to a designer’s
usual way of reasoning. It would be difficult to imagine, for example, how a
designer could specify, model and communicate a system design by means of
a schematic or hundred thousand lines of VHDL or Verilog code. The more
complex the design, the more difficult it is for the designer to comprehend its
functionality when it is specified on register-transfer level of abstraction. On
the other hand, when a system is described with an application-oriented model
of computation as a set of processes that operate on abstract data types and
communicate results through abstract channels, the designer will find it much
easier to specify and verify proper functionality and to evaluate various implementations using different technologies. The second reason is that embedded
system are usually defined by the experts in application domain who understand
application very well, but have only basic knowledge of design technology and
practice. System-level design technology allows them to specify, explore and
verify their embedded system products without expert knowledge of system
engineering and manufacturing.
It must be acknowledged that research on system design did start many years
ago; at the time, however, it remained rather focused to specific domains and
communities. For example, the computer architecture community has considered ways of partitioning and mapping computations to different architectures,
such as hypercubes, multiprocessors, massively parallel or heterogeneous processors. The software engineering community has been developing methods
for specifying and generating software code. The CAD community has focused
on system issues such as specification capture, languages, and modeling. However, simulation languages and models are not synthesizable or verifiable for

lack of proper design meaning and formalism. That resulted in proliferation
of models and modeling styles that are not useful beyond the modeler’s team.
By introduction of well-defined model semantics, and corresponding model
transformations for different design decision, it is possible to generate models
automatically. Such models are also synthesizable and verifiable. Furthermore,
model automation relieves designers from error-prone model coding and even


PREFACE

vii

learning the modeling language. This approach is appealing to application experts since they need to know only the application and experiment with a set of
design decisions. Unfortunately, a universally accepted theoretical framework
and CAD environments that support system design methodologies based on
these concepts are not commercially available yet, although some experimental
versions demonstrated several orders of magnitude productivity gain. On the
other hand, embedded-system design-technology based on these concepts has
matured to the point that a book summarizing the basic ideas and results developed so far will help students and practitioners in embedded system design.
In this book, we have tried to include ideas and results from a wide variety
of sources and research projects. However, due to the relative youth of this
field, we may have overlooked certain interesting and useful projects; for this
we apologize in advance, and hope to hear about those projects so they may
be incorporated into future editions. Also, there are several important systemlevel topics that, for various reasons, we have not been able to cover in detail
here, such as testing and design for test. Nevertheless, we believe that a book
on embedded system techniques and technology will help upgrade computer
science and engineering education toward system-level and toward application
oriented embedded systems, stimulate design automation community to move
beyond system level simulation and develop system-level synthesis and verification tools and support the new emerging embedded application community
to become more innovative and self-sustaining.

AUDIENCE
This book is intended for four different groups within the embedded system
community. First, it should be an introductory book for application-product
designers and engineers in the field of mechanical, civil, bio-medical, electrical, and environmental, energy, communication, entertainment and other application fields. This book may help them understand and design embedded
systems in their application domain without an expert knowledge of system
design methods bellow system-level. Second, this book should also appeal to
system designers and system managers, who may be interested in embedded
system methodology, software-hardware co-design and design process management. They may use this book to create a new system level methodology or
to upgrade one existing in their company. Third, this book can also be used by
CAD-tool developers, who may want to use some of its concepts in existing or
future tools for specification capture, design exploration and system modeling,
synthesis and verification. Finally, since the book surveys the basic concepts
and principles of system-design techniques and methodologies, including software and hardware, it could be valuable to advanced teachers and academic


viii

EMBEDDED SYSTEM DESIGN:

programs that want to teach software and hardware concepts together instead
of in non-related courses. That is particularly needed in today’s embedded
systems where software and hardware are interchangeable. From this point,
the book would also be valuable for an advanced undergraduate or graduate
course targeting students who want to specialize in embedded system, design
automation and system design and engineering. Since the book covers multiple aspects of system design, it would be very useful reference for any senior
project course in which students design a real prototype or for graduate project
for system-level tool development.

ORGANIZATION

This book has been organized into eight chapters that can be divided into four
parts. Chapter 1 and 2 present the basic issues in embedded system design
and discuss various system-design methodologies that can be used in capturing
system behavior and refining it into system implementation. Chapter 3 and 4
deal with different models of computations and system modeling at different
levels of abstraction as well as system synthesis from those models. Chapter 5,
6, and 7 deal with issues and possible solutions in synthesis and verification
of software and hardware component needed in a embedded system platform.
Finally, Chapter 8 reviews the key developments and selected current academic
and commercial tools in the field of system design, system software and system
hardware as well as case study of embedded system environments.
Given an understanding of the basic concepts defined in Chapter 1 and 2,
each chapter should be self-contained and can be read independently. We have
used the same writing style and organization in each chapter of the book. A
typical chapter includes an introductory example, defines the basic concepts, it
describes the main problems to be solved. It contains a description of several
possible solutions, methods or algorithms to the problems that have been posed,
and explains the advantages and disadvantages of each approach. Each chapter
also includes relationship to previously published work in the field and discusses
some open problems in each topic.
This book could be used in several different courses. One course would be
for application experts with only a basic knowledge of computers engineering.
It would emphasize application issues, system specification in application oriented models of computation, system modeling and exploration as presented
in Chapter 1 - 4. The second course for embedded system designers would
emphasize system languages, specification capture, system synthesis and verification with emphasis on Chapter 3, Chapter 4, and Chapter 7. The third course
may emphasize system development with component synthesis and tools as described in Chapter 5 - Chapter 8. In which ever it is used, though, we feel that


PREFACE

ix

this book will help to fill the vacuum in computer science and engineering curriculum where there is need and demand for emphasis on teaching embedded
system design techniques in addition to supporting lower levels of abstraction
dealing with circuit, logic and architecture design.
We hope that the material selection and the writing style will approach your
expectations; we welcome your suggestions and comments.
Daniel Gajski, Andreas Gerstlauer, Samar Abdi, Gunar Schirner


Acknowledgments

This book was in the making for many years: from concepts to methodologies
to experiments. Many generations of researchers at the Center for Embedded
Systems at UCI participated in finding and proving what works and what does
not. We would like to thank the members of the first generation that established
basic principles of embedded systems: Frank Vahid, Sanjiv Narayan, Jie Gong
and Smita Bakshi. We would also like to acknowledge the second generation
that brought us SpecC and System on Chip Environment: Jianwen Zhu, Rainer
Doemer, Lukai Cai, Haobo Yu, Sequin Zhao, Dongwan Shin, and Jerry Peng.
And the third generation that made Embedded System Environment available:
Lochi Yu, Hansu Cho, Yongyun Hwang, Ines Viskic. In addition, we would like
to acknowledge the NISC team: Mehrdad Reshadi, Bita Gorjiara and Jelena
Trajkovic for their high-level synthesis contributions and Pramod Chandraria
for his work on design drivers.
We would also like to thank Quoc-Viet Dang, who helped us with book
formatting, figure creation, generation, and without whom this book would not
be possible. We also want to thank our editors Matt Nelson and Brian Thill
who made the sentences readable and ideas flow without interruptions. We also
want to thank Simone Lacina from grafikdesign-lacina.de for an excellent and

artistic cover.
However, the highest credits go to Grace Wu and Melanie Kilian for making
our center work flawlessly while we were working and thinking about the book.
Last but not the least, we would like to thank Carl Harris from Springer
for encouragement and asking at every conference in the last 5 years the same
question: "When is the Orange book coming?"


Contents

Preface
Acknowledgments
List of Figures
List of Tables

v
xi
xix
xxv

1. INTRODUCTION
1.1 System-Design Challenges
1.2 Abstraction Levels
1.2.1 Y-Chart
1.2.2 Processor-Level Behavioral Model
1.2.3 Processor-level structural model
1.2.4 Processor-level synthesis
1.2.5 System-Level Behavioral Model
1.2.6 System Structural Model
1.2.7 System Synthesis

1.3 System Design Methodology
1.3.1 Missing semantics
1.3.2 Model Algebra
1.4 System-Level Models
1.5 Platform Design
1.6 System Design Tools
1.7 Summary

1
1
3
3
5
7
10
13
14
14
18
20
21
23
27
29
32

2. SYSTEM DESIGN METHODOLOGIES
2.1 Bottom-up Methodology
2.2 Top-down Methodology
2.3 Meet-in-the-middle Methodology

35
35
37
38


xiv

EMBEDDED SYSTEM DESIGN:

2.4
2.5
2.6
2.7
2.8

Platform Methodology
FPGA Methodology
System-level Synthesis
Processor Synthesis
Summary

3. MODELING
3.1 Models of Computation
3.1.1 Process-Based Models
3.1.2 State-Based Models
3.2 System Design Languages
3.2.1 Netlists and Schematics
3.2.2 Hardware-Description Languages

3.2.3 System-Level Design Languages
3.3 System Modeling
3.3.1 Design Process
3.3.2 Abstraction Levels
3.4 Processor Modeling
3.4.1 Application Layer
3.4.2 Operating System Layer
3.4.3 Hardware Abstraction Layer
3.4.4 Hardware Layer
3.5 Communication Modeling
3.5.1 Application Layer
3.5.2 Presentation Layer
3.5.3 Session Layer
3.5.4 Network Layer
3.5.5 Transport Layer
3.5.6 Link Layer
3.5.7 Stream Layer
3.5.8 Media Access Layer
3.5.9 Protocol and Physical Layers
3.6 System Models
3.6.1 Specification Model
3.6.2 Network TLM
3.6.3 Protocol TLM
3.6.4 Bus Cycle-Accurate Model (BCAM)
3.6.5 Cycle-Accurate Model (CAM)

40
43
44
45

47
49
50
52
58
65
66
66
68
68
69
71
72
73
75
78
80
83
84
88
90
92
93
94
98
99
100
102
103
104

106
107
108


Contents

3.7 Summary

xv
109

4. SYSTEM SYNTHESIS
4.1 System Design Trends
4.2 TLM Based Design
4.3 Automatic TLM Generation
4.3.1 Application Modeling
4.3.2 Platform Definition
4.3.3 Application to Platform Mapping
4.3.4 TLM Based Performance Estimation
4.3.5 TLM Semantics
4.4 Automatic Mapping
4.4.1 GSM Encoder Application
4.4.2 Application Profiling
4.4.3 Load Balancing Algorithm
4.4.4 Longest Processing Time Algorithm
4.5 Platform Synthesis
4.5.1 Component data models
4.5.2 Platform Generation Algorithm
4.5.3 Cycle Accurate Model Generation

4.5.4 Summary

113
114
117
120
122
123
124
126
130
132
134
135
138
142
146
147
148
151
152

5. SOFTWARE SYNTHESIS
5.1 Preliminaries
5.1.1 Target Languages for Embedded Systems
5.1.2 RTOS
5.2 Software Synthesis Overview
5.2.1 Example Input TLM
5.2.2 Target Architecture
5.3 Code Generation

5.4 Multi-Task Synthesis
5.4.1 RTOS-based Multi-Tasking
5.4.2 Interrupt-based Multi-Tasking
5.5 Internal Communication
5.6 External Communication
5.6.1 Data Formatting
5.6.2 Packetization
5.6.3 Synchronization
5.6.4 Media Access Control

155
156
157
159
162
164
166
167
173
173
176
181
182
183
185
186
191


xvi

EMBEDDED SYSTEM DESIGN:

5.7 Startup Code
5.8 Binary Image Generation
5.9 Execution
5.10Summary

193
194
195
196

6. HARDWARE SYNTHESIS
6.1 RTL Architecture
6.2 Input Models
6.2.1 C-code specification
6.2.2 Control-Data Flow Graph specification
6.2.3 Finite State Machine with Data specification
6.2.4 RTL specification
6.2.5 HDL specification
6.3 Estimation and Optimization
6.4 Register Sharing
6.5 Functional Unit Sharing
6.6 Connection Sharing
6.7 Register Merging
6.8 Chaining and Multi-Cycling
6.9 Functional-Unit Pipelining
6.10Datapath Pipelining
6.11Control and Datapath Pipelining

6.12Scheduling
6.12.1RC scheduling
6.12.2TC scheduling
6.13Interface Synthesis
6.14Summary

199
201
204
204
205
207
208
209
211
216
220
224
227
229
232
235
237
240
243
244
248
253

7. VERIFICATION

7.1 Simulation Based Methods
7.1.1 Stimulus Optimization
7.1.2 Monitor Optimization
7.1.3 SpeedUp Techniques
7.1.4 Modeling Techniques
7.2 Formal Verification Methods
7.2.1 Logic Equivalence Checking
7.2.2 FSM Equivalence Checking

255
257
260
262
263
264
265
266
268


Contents

7.2.3 Model Checking
7.2.4 Theorem Proving
7.2.5 Drawbacks of Formal Verification
7.2.6 Improvements to Formal Verification Methods
7.2.7 Semi-formal Methods: Symbolic Simulation
7.3 Comparative Analysis of Verification Methods
7.4 System Level Verification
7.4.1 Formal Modeling

7.4.2 Model Algebra
7.4.3 Verification by Correct Refinement
7.5 Summary

xvii
270
273
275
275
276
276
278
280
282
283
285

8. EMBEDDED DESIGN PRACTICE
8.1 System Level Design Tools
8.1.1 Academic Tools
8.1.2 Commercial Tools
8.1.3 Outlook
8.2 Embedded Software Design Tools
8.2.1 Academic Tools
8.2.2 Commercial Tools
8.2.3 Outlook
8.3 Hardware Design Tools
8.3.1 Academic Tools
8.3.2 Commercial Tools
8.3.3 Outlook

8.4 Case Study
8.4.1 Embedded System Environment
8.4.2 Design Driver: MP3 Decoder
8.4.3 Results
8.5 Summary

287
287
289
296
299
300
301
303
305
306
308
314
319
319
320
324
327
333

References

335

Index

349


List of Figures

1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
2.1
2.2
2.3
2.4
2.5
2.6

2.7

Y-Chart
FSMD model
CDFG model
Instruction-set flow chart
Processor structural model
Processor synthesis
System behavioral model
System structural model
System synthesis
Evolution of design flow over the past 50 years
Missing semantics
Model equivalence
SER Methodology
System TLM
System CAM
Platform architecture
General system environment
System tools
Bottom-up methodology
Top-down methodology
Meet-in-the-middle methodology (option 1)
Meet-in-the-middle methodology (option 2)
Platform methodology
System methodology
FPGA methodology

3
5

6
8
9
11
13
15
16
17
20
22
23
25
26
28
29
31
36
37
39
40
41
42
43


xx

List of Figures

2.8

2.9
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.24
3.25
3.26
3.27
3.28

3.29
3.30
3.31
3.32
3.33

System-level synthesis
44
Processor synthesis
46
Kahn Process Network (KPN) example
54
Synchronous Data Flow (SDF) example
56
Finite State Machine with Data (FSMD) example
60
Hierarchical, Concurrent Finite State Machine (HCFSM) example 61
Process State Machine (PSM) example
64
System design and modeling flow
69
Model granularities
71
Processor modeling layers
73
Application layer
74
Operating system layer
75
Operating system modeling

76
Task scheduling
77
Hardware abstraction layer
79
Interrupt scheduling
80
Hardware layer
81
Application layer synchronization
86
Application layer storage
87
Application layer channels
88
Presentation layer
89
Session layer
91
Network layer
92
Communication elements
93
Link layer
95
Link layer synchronization
96
Link layer synchronization (con’t)
97
Media access layer

99
Protocol layer
100
Physical layer
101
System models
102
Specification model
104
Network TLM
105
Protocol TLM
106
Bus Cycle-Accurate Model (BCAM)
107
Cycle-Accurate Model (CAM)
108


List of Figures

3.34
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8

4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8

Modeling results
A traditional board-based system design process.

A virtual platform based development environment.
A model based development flow of the future.
TLM based design flow.
Modeling layers for TLM.
System synthesis flow with given platform and mapping.
A simple application expressed in PSM model of computation.
A multicore platform specification.
Mapping from application model to platform.
Computation timing estimation.
Communication timing estimation.
Synchronization Modeling with Flags and Events.
Automatically Generated TLM from system specification.
System synthesis with fixed platform.
Application example: GSM Encoder
Application profiling steps.
Profiled statistics of GSM encoder.
Abstraction of profiled statistics into an application graph.
Creation of platform graph.
Flowchart of load balancing algorithm for mapping generation.
Platform graph with communication costs.
LPT cost function computation.
Flowchart of LPT algorithm for mapping generation.
System synthesis from application and constraints.
Flowchart of a greedy algorithm for platform generation.
Illustration of platform generation on a GSM Encoder example.
Cycle accurate model generation from TLM.
Synthesis overview
Software synthesis flow
Input system TLM example
Generic target architecture

Task specification
Software execution stack for RTOS-based multi-tasking
Multi-task example model
Software execution stack for interrupt-based multi-tasking

xxi
110
114
115
116
117
118
120
122
123
124
125
128
128
131
133
134
135
137
138
139
140
142
143
145

146
149
150
152
155
163
164
166
169
173
175
177


xxii
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
6.1
6.2
6.3

6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24

List of Figures

Interrupt-based multi-tasking example
Internal communication
External communication
Marshalling example
Packetization
Chain for interrupt-based synchronization

Events in interrupt-based synchronization
Polling-based synchronization
Events in polling-based synchronization
Transferring a packet using bus primitives
Binary image generation
ISS-based Virtual platform
HW synthesis design flow
High-level block diagram
RTL diagram with FSM controller
RTL diagram with programmable controller
CDFG for Ones counter
FSMD specification
RTL Specification
Square-root algorithm (SRA)
Gain in register sharing
General partitioning algorithm
Variable merging for SRA example
SRA datapath with register sharing
Gain in functional unit sharing
Functional unit merging for SRA
SRA design after register and unit merging
SRA Datapath with labeled connections
Connection merging for SRA
SRA Datapath after connection merging
Register merging
Datapath schematic after register merging
Modified FSMD models for SRA algorithm
Datapath with chained functional units
SRA datapath with chained and multi-cycle functional units
Functional unit pipelining

178
181
183
184
185
187
188
190
190
191
195
196
199
201
202
203
206
207
208
212
217
218
219
220
221
222
224
225
227

227
228
229
230
231
232
234


List of Figures

6.25
6.26
6.27
6.28
6.29
6.30
6.31
6.32
6.33
6.34
6.35
6.36
6.37
7.1
7.2
7.3
7.4
7.5
7.6

7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
8.1
8.2

xxiii

Datapath pipelining
236
Control and datapath pipelining
239
C and CDFG
241
ASAP, ALAP, and RC schedules for SRA
243
RC algorithm
245

TC algorithm
245
ASAP, ALAP, and RC schedules for SRA
246
Distribution graphs for TC scheduling of the SRA example
247
HW Synthesis timing constraints
249
FSMD for MAC driver
250
Custom HW component with bus interface
251
A typical bus protocol
252
Transducer structure
253
A typical simulation environment
257
A test case that covers only part of the design.
261
Coverage analysis results in a more useful test case.
262
Graphical visualization of the design helps debugging.
263
A typical emulation setup.
263
Logic equivalence checking by matching of cones.
266
DeMorgan’s law illustrated by ROBDD equivalence.
267

Equivalence checking of sequential design using product FSMs. 269
Product FSM for with a reachable error state.
270
A typical model checking scenario.
270
A computation tree derived from a state transition diagram.
271
Various temporal properties shown on the computation tree.
272
Proof generation process using a theorem prover.
273
Associativity of parallel behavior composition.
273
Basic laws for a theory of system models.
274
Symbolic simulation of Boolean circuits.
277
System level models.
279
A simple hierarchical specification model.
280
Behavior partitioning and the equivalence of models.
280
Equivalence of models resulting from channel mapping.
281
Model refinement using functionality preserving transformations.284
Metropolis framework
289
SystemCoDesigner tool flow
290

xxiv
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18

List of Figures

Daedalus tool flow
PeaCE tool flow
SCE tool flow
NISC technology tools
The SPARK Synthesis Methodology
xPilot Synthesis System
ESE tool flow
System level design with ESE front end

SW-HW synthesis with ESE back end
MP3 decoder application model
MP3 decoder platform SW+4
Execution speed and accuracy trade-offs for embedded system models
MP3 manual design quality
Automatically generated MP3 design quality
Development productivity gains from model automation
Validation productivity gain from using TLM vs. CAM

292
293
295
310
311
313
320
321
323
324
326
328
329
330
331
332


List of Tables

3.1

3.2
4.1
6.1
6.2
6.3
6.4
6.5
6.6
7.1

Processor models
Communication layers
A sample capacity table of platform components.
Input logic table
Output logic table
Variable usage
Operation usage
SRA connectivity
Connection usage table
A comparison of various verification schemes.

82
84
147
209
209
213
214
215
226

278


Chapter 1
INTRODUCTION

In this chapter we will look at the emergence of system design theory, practice and tools. We will first look into the needs of system-level design and the
driving force behind its emergence: increase in design complexity and widening of productivity gap. In order to find an answer to these challenges and find a
systematic approach for system design, we must first define design-abstraction
levels; this will allow us to talk about design-flow needs on processor and systems levels of abstraction. An efficient design-flow will employ clear and clean
semantics in its languages and modeling, which is also, required by synthesis
and verification tools. We will then analyze the system-level design flow and
define necessary models, define each model separately and its use in the system design flow. We will also discuss the components and tools necessary for
system design. We will finish with prediction on future directions in system
design and the prospects for system design practice and tools.

1.1

SYSTEM-DESIGN CHALLENGES

Driven by ever-increasing market demands for new applications and by technological advances that allow designers to put complete many-processor systems on a single chip (MPSoCs), system complexities are growing at an almost
exponential rate. Together with the challenges inherent in the embedded-system
design process with its very tight constraints and market pressures, not the least
of which is reliability, we are finding that traditional design methods, in which
systems are designed directly at the low hardware or software levels, are fast
becoming infeasible. This leads us to the well-known productivity gap generated by the disparity between the rapid paces at which design complexity has
increased in comparison to that of design productivity [99].
D.D. Gajski et al., Embedded System Design: Modeling, Synthesis and Verification,
DOI: 10.1007/978-1-4419-0504-8_1,
© Springer Science + Business Media, LLC 2009

1


2

Introduction

One of the commonly-accepted solutions for closing the productivity gap as
proposed by all major semiconductor roadmaps is to raise the level of abstraction in the design process. In order to achieve the acceptable productivity gains
and to bridge the semantic gap between higher abstraction levels and low-level
implementations, the goal now is to automate the system-design process as
much as possible. We must apply design-automation techniques for modeling,
simulation, synthesis, and verification to the system-design process. However,
automation is not easy if a system-abstraction level is not well-defined, if components on any particular abstraction level are not well-known, if system-design
languages do not have clear semantics, or if the design rules and modeling styles
are not clear and simple. In the following chapters, we will show how to answer
for those challenges through sound system-design theories, practices, and tools.
On the modeling and simulation side, several approaches exist for the virtual prototyping of complete systems. These approaches are typically based
on some variant of C-based description, such as C-based System-Level Design Languages (SLDLs) like SystemC [150] or SpecC [171]. These virtual
prototypes can be assembled at various levels of detail and abstraction.
The most common approach in the system design of a many-processor
platform is to perform co-simulation of software (SW) and hardware (HW)
components. Both standard and application-specific processors are simulated
on nstruction-set level with an Instruction Set Simulator (ISS). The custom
HW components or Intellectual Property (IP) components are modeled with a
timed functional model and integrated together with the processor models into
a Transaction-Level Model (TLM) representing the platform communication
between components.
In algorithmic-level approaches in designing MPSoCs, we use domainspecific application modeling, which is based on more formalized models of

computation, such as process networks or process state machines. These modeling approaches are often supported by graphical capture of models in terms
of block diagrams, which hide the details of any underlying internal language.
On the other hand, the code can be generated in a specific target language such
as C by model-based-design tools from such graphical input.
Such simulation-centric approaches enable the horizontal integration of various components in different application domains. However, approaches for
the vertical integration for system synthesis and verification across component
or domain boundaries are limited. At best, there are some solutions for the Cbased synthesis of single custom hardware units. But no commercial solutions
for synthesis and verification at the system level, across hardware and software
boundaries, currently exist.
In order to understand system-level possibilities more fully, however, we
must step back and explain the different abstraction levels involved in system
design.


3

Abstraction Levels
Behavior
(Function)

System

Processor
Logic
Circuit

Structure
(Netlist)

F(...)

F(...)

F(...)

Physical

F(...)

(Layout)

FIGURE 1.1 Y-Chart

1.2

ABSTRACTION LEVELS

The growing capabilities of silicon technology over the previous decades has
forced design methodologies and tools to move to higher levels of abstraction.
In order to explain the relationship between different design methodologies on
different abstraction levels, we will use the Y-Chart, which was developed in
1983 in order to explain differences between different design tools and different
design methodologies in which these tools were used [60].

1.2.1

Y-CHART

The Y-Chart makes the assumption that each design, no matter how complex,
can be modeled in three basic ways, which emphasize different properties of

the same design. As shown in Figure 1.1, the Y-Chart has three axes representing three aspects of every design: behavior (sometimes called functionality
or specification), design structure (also called netlist or a block diagram), and
physical design (usually called layout or board design). Behavior represents a
design as a black box and describes its outputs in terms of its inputs over time.
The black-box behavior does not indicate in any way how to build the black
box or what its structure is. That is given on the structure axis, where the black
box is represented as a set of components and connections. Naturally, the behavior of the black box can be derived from its component behaviors and their
connectivity. However, such a derived behavior may be difficult to understand
since it is obscured by the details of each component and connection. Physical


4

Introduction

design adds dimensionality to the structure. It specifies the size (height and
width) of each component, the position of each component, as well as each port
and connection on the silicon chip, printed circuit board, or any other container.
The Y-Chart can also represent design on different abstraction levels, which
are identified by concentric circles around the origin. Typically, four levels are
used: circuit, logic, processor, and system levels. The name of each abstraction
level is derived from the types of the components generated on that abstraction
level. Thus the components generated on the circuit level are standard cells
which consist of N-type or P-type transistors, while on the logic level we use
logic gates and flip-flops to generate register-transfer components. These are
represented by storage components such as registers and register files and by
functional units such as ALUs and multipliers. On the processor level, we generate standard and custom processors, or special-hardware components such
as memory controllers, arbiters, bridges, routers, and various interface components. On the system level, we design standard or embedded systems consisting
of processors, memories, buses, and other processor components.
On each abstraction level, we also need a database of components to be used in

building the structure for a given behavior. This process of converting the given
behavior into a structure on each abstraction level is called synthesis. Once a
structure is defined and verified, we can proceed to the next lower abstraction
level by further synthesizing each of the components in the structure. On the
other hand, if each component in the database is given with its structure and
physical dimensions, we can proceed with physical design, which consists of
floorplanning, placement, and routing on the chip or PC board. Thus each
component in the database may have up to three different models representing
three different axes in the Y-Chart: behavior or function; structure, which
contains the components from the lower level of abstraction; and the physical
layout of its structure.
Fortunately, all three models for each component are not typically needed
most of the time. Most of the methodologies presently in use perform design or
synthesis on the system and processor levels, where every system component
except standard processors and memories is synthesized to the logic level, before
the physical design is performed on the logic level. Therefore, for the top three
abstraction levels, we only need a functional model of each component with
estimates of the key metrics such as performance, delay, power, cost, size,
reliability, testability, etc. Once the design is represented in terms of logic
gates and flip-flops, we can use standard cells for each logic component and
perform layout placement and routing. On the other hand, some components
on the processor-and-system levels may be obtained as IPs and not synthesized.
Therefore, their structure and physical design are known, at least partially, on
the level higher than logic level. In that case, the physical design then may
contain components of different sizes and from different levels of abstraction.