1. technology and computing
2. hardware
3. computer components
4. chips and processors

Verification of High Performance
Embedded Systems
Sisira K. Amarasinghe, Ph.D.
Outline
 Embedded Systems
 High Performance Embedded Systems
 Verification and Validation
 Conventional Verification of Embedded
Systems
 Verification of Complex Systems
 Conclusion
 Questions and Answers
2 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
3 of
Introduction to Embedded Systems (2/4)
Designed for some specific tasks
Subjected to real time performance
constraints that must be met
 Feature tightly integrated combinations
of hardware and software
4 of
Introduction to Embedded Systems (3/4)
Typical embedded software components:
Embedded Application Code
Device Drivers
A Real-Time Operating System (RTOS)
Hardware abstraction layer(s)
System initialization routines
5 of
User Interface
Analog i/p
Digital i/p
Analog
Front End
Digital
i/p Ports
User Interface
Modules
interrupts
D/A,
Isolation..
Digital
o/p Ports
Support:
Timers
Watchdog
INPUTS
CPU
Data Bus
Analog o/p
Digital o/p
OUTPUTS
Comms:
ASC, SSC,
USB, IIC,
IrDA, etc.
Address Bus
Data
Memory
Program
Memory
Links to Other Systems
6 of
Outline
 Embedded Systems
 High Performance Embedded Systems
 Verification and Validation
 Conventional Verification of Embedded
Systems
 Verification of Complex Systems
 Conclusion
 Questions and Answers
7 of
High Performance Embedded Systems (1/10)
Massive computational resources with
requirements of
– Small size
– Low Weight
– Very low power consumption.
Need to employ innovative, advanced
system architectures
8 of
High Performance Embedded Systems (2/10)
Architectures typically feature
– Multiple processor cores
– Tiered memory structures with multi-level
memory caching
– Multi-layer bus structures.
– Super-pipelining and/or super-scaling
9 of
High Performance Embedded Systems (3/10)
The current state-of-the-art:
Multiple computational and dataprocessing engines, memory, and
peripherals, all constructed on a single
silicon chip called a System-on-Chip
(SoC).
Designs to feature multiple generalpurpose central processing unit (CPU)
cores as well as special-purpose digital
signal processor (DSP) cores
10 of
High Performance Embedded Systems (4/10)
32-Bit MCU
RISC Strengths
 Register Based Architecture
 Reduced Instruction Set
 Instruction Pipeline
 C/C++ language support
 Memory Protection
32-Bit RISC
Core
16-Bit FP DSP Core
MCU Strengths




Tricore
Real Time Control
High System Integration
Range of On-Chip Peripherals
Dedicated Bit Manipulation unit
TriCore
32-Bit MCUDSP
Unified
MCU-DSP
DSP Strengths
 Zero Overhead Loop
 Dedicated Hardware Multipliers
 Powerful Multi-Operation Instructions
 Addressing Modes
 Data Formats
11 of
High Performance Embedded Systems (5/10)
 Embedded designs to include multiple
general-purpose central processing unit
(CPU) cores as well as special-purpose
digital signal processor (DSP) cores
Firmware
Peripherals
Core 1
Core 2
Memory
Core 3
12 of
High Performance Embedded Systems (6/10)
 Multilayer Bus Structures
– CPU and DSP cores can have separate
buses for control, instructions, and data,
– DMA buses along with one or more
dedicated peripheral buses.
– Both the CPUs and DSPs can have
tightly-coupled memory buses, external
memory buses, and shared memory
buses.
13 of
High Performance Embedded Systems (7/10)
Increasing software content
– The software content of embedded systems
is increasing at a phenomenal rate
– software development and test often
dominate the costs, timelines, and risks
associated with today's embedded system
designs.
14 of
High Performance Embedded Systems (8/10)
15 of
High Performance Embedded Systems (9/10)
Decreasing design cycles
– Market windows are continually narrowing
– Competition gets more and more aggressive
– Consumer electronics markets are extremely
sensitive to time-to-market pressures
16 of
High Performance Embedded Systems (10/10)
17 of
Outline
 Embedded Systems
 High Performance Embedded Systems
 Verification and Validation
 Conventional Verification of Embedded
Systems
 Verification of Complex Systems
 Conclusion
 Questions and Answers
18 of
Verification and Validation (1/7)
 What is Verification and Validation?
– Verification
Verification confirms that work products
properly reflect the requirements
specified for them. In other words,
verification ensures that ‘the product has
been built right’.
19 of
Verification and Validation (2/7)
– Validation
Validation confirms that the product, as
provided, will fulfill its intended use. In
other words, validation ensures that ‘you
built the right thing’”.
20 of
Verification and Validation (3/7)
 Why Verification and Validation?
– Business considerations
•Legal
•Refutation
•Warranty / Recall
– Regulatory issues
•FDA
•FAA
•DoD
21 of
Verification and Validation (4/7)
– Safety considerations
•Life sciences
•Mission critical
•Automotive examples:
–Drive by wire
»Electronic throttle control
»Electronic steering
–ABS
–Airbag Systems
22 of
Verification and Validation (5/7)
23 of
Verification and Validation (6/7)
Abstraction Levels of Design Under Verification
 Behavioral Model
– Example: c <= a * b
– May not include timing information
– Verification examines the basic operation and interactions among
the systems’ components
 RTL (Register-Transfer-Level) Model
– VHDL/Verilog commonly used to model RTL
– Accurate cycle-level information (no
propagation delays)
– Verification of exact cycle behavior
 Gate-Level Model
– Specifies each individual logic element and their interconnections
– Verification at this level is time-consuming but necessary for
clock boundaries and reset conditions
24 of
Verification and Validation (7/7)
Importance of Verification in Early Design Stages
Revenue loss
due to delay in
Time-To-Market
Behavioral
RTL
Gate Level Transistor
Ease of verification
Remove as many bugs as possible in early designs stages
Source: Verification Methodology Manual, 2000 - TransEDA
25 of
Outline
 Embedded Systems
 High Performance Embedded Systems
 Verification and Validation
 Conventional Verification of Embedded
Systems
 Verification of Complex Systems
 Conclusion
 Questions and Answers
26 of
Conventional Verification of Embedded Systems
(1/13)
Determine the overall system
architecture
Design System Hardware
Construct hardware prototype
Install and test OS and/or
middleware
Develop, port, integrate, and
debug embedded software
27 of
Conventional Verification of Embedded Systems
(2/13)
 Conventional verification drawback (mainly
due to shorter design cycles)
– SoC to be fabricated before developing
the software
– Having to wait for the implementationlevel representation of the design
(specified RTL) to become available
before developing the embedded
software.
28 of
Conventional Verification of Embedded Systems
(3/13)
 Physical Prototypes as primary
verification mechanism
– Typically involves a circuit board and the
SoC in the form of working silicon.
•The hardware portion of the design is
now almost 100 percent tied down
•Not much useful in the context of
exploring and evaluating alternative
architectures
29 of
Conventional Verification of Embedded Systems
(4/13)
– Important hardware/software tradeoffs
can’t be made before the design
partitioning is locked down and the chips
are manufactured
•System design must be largely based
on experience and intuition, as opposed
to hard data.
•Unacceptable in today's complex
algorithms, multi-core systems, tiered
memory systems, and multi-layered
bus structures.
30 of
Conventional Verification of Embedded Systems
(5/13)
 Hardware acceleration and emulation
as verification mechanism
– These typically involve arrays of fieldprogrammable gate arrays (FPGAs) or
processors.
– These solutions accept RTL
representations of the design and
translate them into an equivalent suitable
for hardware acceleration.
– The verification can get very costly
31 of
Conventional Verification of Embedded Systems
(6/13)
– Issues in multi-processor designs
– Emulators also have problems with
limited visibility into the design
– Software development cannot commence
until a long way into the design cycle.
(The hardware design is largely
established  limitations with regard to
exploring and evaluating alternative
architectures)
32 of
Conventional Verification of Embedded Systems
(7/13)
 RTL-based simulation as verification
mechanism
– An RTL simulation solution requires RTL
representations of the hardware 
Delays in meaningful software
development until the RTL becomes
available
– It simply isn't possible to use software
simulation to determine how well the
architecture performs on real software
workloads
33 of
Conventional Verification of Embedded Systems
(8/13)
– A software simulation running on a on
very high-end (and correspondingly
expensive) machine would hardly achieve
equivalent simulation speeds of more
than a few Hz
• That is, a few cycles of embedded system
clock for each second in real time
• Detailed simulations can be performed on only
small portions of the software.
34 of
Conventional Verification of Embedded Systems
(9/13)
 ISS-based simulation as verification
mechanism
 Verify and debug chips using software models that can
execute the same binary code as the actual processors
 Limitations:
– Only processor cores can be modeled
– Accuracy is compromised for high performance
verification (typically not cycle accurate)
– Lack of synchronization support for multi-processor
based systems
35 of
Outline
 Embedded Systems
 High Performance Embedded Systems
 Verification and Validation
 Conventional Verification of Embedded
Systems
 Verification of Complex Systems
 Conclusion
 Questions and Answers
36 of
Verification of Complex Systems (1/15)
 System-On-Chip (SoC) designs increasingly
become the driving force of a number of
modern electronics systems
 A number of key technologies integrate
together in forming the highly complex
embedded platform
 Verification need to account for integration
of a number of different IPs into new
designs, the coupling of embedded software
into designs, and the verification flow from
core to the design, etc.
37 of
Verification of Complex Systems (2/15)
 IP Core Verification and System Level
Verification both need to be addressed
adequately
 On top of structural complexities, further
bottlenecks are introduced by:
– Time to market pressures
– Increasing software content
– Other stringent design constraints such as
size, weight, low power levels, etc.
38 of
Verification of Complex Systems (3/15)
 The system level design strategies should
be considered together with the complex
task of verification
 Hardware , first, then software, is no longer
a viable theme
 Appropriate verification strategies need to
be employed from the outset to minimize
downstream defects including SoC re-spins
 Concurrent hardware and software
development would mandatory.
39 of
Verification of Complex Systems (4/15)
 SoC architects to employ a broad system
level design strategy that will allow:
– Explore and evaluate system level
architectural choices
– Concurrent hardware-software design
– Easily evaluate and integrate a number of
different technologies
– Adequate verification at every level of the
design cycle
40 of
Verification of Complex Systems (5/15)
– Carry out an architecture level power
analysis
– Drive requirements for executable
specifications
– Provide visibility into designs
– Easily handle regression testing
How do we achieve all this
with such complexity?
41 of
Verification of Complex Systems (6/15)
 The answer to all above is to employ a
Unified System Model without committing
to any pre-conceived hardware / software
partitioning.
 This will be a type of electronic systems
level (ESL) prototype
 The form of these models can be anywhere
from a cycle-accurate RTL model and to a
time-efficient ISS model, or a hybrid
42 of
Verification of Complex Systems (7/15)
Source: “Mixed-Abstraction Virtual System Prototypes
Close SOC Design Gaps”, Carbon Design Systems, Inc.
43 of
Verification of Complex Systems (8/15)
Running Speed
100MHz
Ideal Verification
10MHz
Solution
Make it faster
Real Silicon
Rapid Prototype
1MHz
100KHz
Make it cheaper
HW Emulator
10KHz
1KHz
HW Accelerator
100Hz
SW Simulator
10Hz
Investment
44 of
Verification of Complex Systems (9/15)
 The basis for a unified system model is
Transaction Level Modeling (TLM).
 Transactions
 Basic representation for exchange of information between
two blocks
 Improve efficiency and performance of verification by
raising the level of abstractions from the signal level
 Can be as simple as a single data write operation or
linked together to form a complex IP packet transfer
45 of
Verification of Complex Systems (10/15)
Transactions:
Source: Cadence white paper, “The Unified Verification Methodology”
46 of
Verification of Complex Systems (11/15)
 Transactor provides a level of abstraction between the pins of
the model and the test code
– Encapsulation: Test code does not need knowledge about the bus
protocols
– Abstraction: Allows test to be written in an abstract fashion that
specifies the required transactions, instead of the operation
execution details
– Re-use: Transactor provides a standard set of routines that the
test can call
– Modularity: Verification environment can be built from a set of
parts
Stimulus Generation: Transactions
Transactor
Write
Operation
Test Code
Write (Addr, data)
Test
Interface
Read
Operation
Data = Read (Addr)
Bus
Driver
Processor
Bus
DESIGN
UNDER
VERIFICATION
Others
Operations
47 of
Verification of Complex Systems (12/15)
 Support functional design and verification at various
abstraction levels
 Advantages
– Enhance reusability in the test-benches
– Improve debugging and coverage analysis
C to HDL
HW part
model
SW part
model
Synthesis
C
HDL
EDIF
Transactor
Transactor
Transactor
Transactor
Transactor
C
ISS
Cross-compiler
Processor
Transaction Level Models (TLM)
Source: Chong-Min Kyung, “Current Status and Challenges of SoC Verification for Embedded Systems Market”, IEEE International
48 of
SOC Conference, 2003
Verification of Complex Systems (13/15)
Unified System Model: Functional Prototype






Unambiguous executable specification
Golden top-level verification environment and integration vehicle
Reference for defining transaction coverage requirements
Model for performing architectural trade-offs
Early handoff vehicle to system development teams
Fast executable model for early embedded software development
Source: Cadence white paper, “The Unified Verification Methodology”
49 of
Verification of Complex Systems (14/15)
Functional Level to Implementation Level Prototype
Source: Cadence white paper, “The Unified Verification Methodology”
50 of
Verification of Complex Systems (15/15)
 Unified System Model with the highest desirable abstraction






is created early in the design process by the SoC verification
team working closely with the architects
A test suite is included with the Functional Prototype
Each subsystem has its own TLM (Transaction Level Model)
defined at the SoC partition
Individual subsystem teams proceed to develop the
implementation level of the subsystem
The test suite is run on the FVP as each subsystem
implementation is integrated into the FVP
The process of integration is facilitated by transactors, which
translate information between the transaction and signal level
Once all the transaction-level models are replaced, the
implementation level prototype is complete
51 of
Outline
 Embedded Systems
 High Performance Embedded Systems
 Verification and Validation
 Conventional Verification of Embedded
Systems
 Verification of Complex Systems
 Conclusion
 Questions and Answers
52 of
Conclusion
Embedded systems tend to contain tens
of processor cores with multi-layered
busses and bus-bridges.
Hardware and software development a
mandatory design methodology.
Existing embedded system verification
strategies do not offer enough
sophistication for today's complex
systems.
53 of
Conclusion
TLM based Unified System Models
provide a means to carry out design and
verification hand in hand while
promoting hardware / software codevelopment.
Source: DSP Design Line
54 of
End of Presentation
Thank you!
Any Questions ?
55 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
56 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
57 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
58 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
59 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
60 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
61 of
Introduction to Embedded Systems (1/4)
An application specific electronic sub-
system which is completely encapsulated
by the main system it belongs to.
The main systems can range from
household appliances, home automation,
consumer electronics, ATMs, network
routers, automobiles, aircrafts, etc.
62 of
High Performance Embedded Systems (3/10)
The current state-of-the-art:
Multiple computational and dataprocessing engines, memory, and
peripherals, all constructed on a single
silicon chip called a System-on-Chip
(SoC).
Designs to feature multiple generalpurpose central processing unit (CPU)
cores as well as special-purpose digital
signal processor (DSP) cores
63 of
Conventional Verification of Embedded Systems
(7/13)
 RTL-based simulation as verification
mechanism
Testbench
DUV
a = 1;
#20 b = 1;
$display (“status is = %d”,c);
...
Source: Chong-Min Kyung, “Current Status and Challenges of SoC Verification for Embedded
Systems Market”, IEEE International SOC Conference, 2003
64 of
Conventional Verification of Embedded Systems
(5/13)
 Hardware acceleration and emulation
as verification mechanism
– These typically involve arrays of fieldprogrammable gate arrays (FPGAs) or
processors.
Simulation environment
Hardware
Accelerator
Testbench
Module
0
Module
1
Module 2
Module 2 is
synthesized &
compiled into
FPGAs
Source: Chong-Min Kyung,
“Current Status and
Challenges of SoC
Verification for Embedded
Systems Market”, IEEE
International SOC
Conference, 2003
65 of
Conventional Verification of Embedded Systems
(5/13)
 Hardware acceleration and emulation
as verification mechanism
Emulation hardware with multiple FPGAs
Logic design
Design
mapping
&
FPGA 0
>
&
FPGA 1
Crossbar
(Switch)
+
FPGA 2
FPGA 3
Source: Chong-Min Kyung,
“Current Status and
Challenges of SoC
Verification for Embedded
Systems Market”, IEEE
International SOC
Conference, 2003
External pins
66 of
Verification of Complex Systems (4/15)
Specification
Meet
Specifications?
 SoC architects
employ a broad system
Behavioralto
Model
DESIGN
VERIFICATION
level design strategy
that
Implement
Behavior?will allow:
RTL Model
– Explore and
evaluate system level
architectural choices
Equivalent?
Gate-Level
Model
– Concurrent
hardware-software
design
– Easily evaluate Equivalent?
and integrate a number of
Transistor-Level
Model
different
technologies
– Adequate verification at every level of the
design cycle
67 of
Verification of Complex Systems (1/15)
 System-On-Chip (SoC)
68 of
Brief Introduction
 Graduated with First Class Honors in Electronic and
Telecommunication Eng (1986)
 Won the Presidential Scholarship (Sri Lanka) and a
Fulbright Fellowship (USEF), and undertook
graduate studies leading to M.Sc. (Microprocessor
Eng and Digital Electronics) (1989), Ph.D.
(Information Systems Engineering) (1992), at U.
of Manchester Inst of Sc and Tech, UK.
 Employed as a faculty member (Information
Engineering) at Nanyang Technological University,
Singapore (1992-1999)
 Served the industry in USA at senior technical and
management positions (1999 – To date)
69 of
Center for High Performance Embedded
Systems (CHiPES), NTU, Singapore
CHiPES was established by the Nanyang
Technological University in April 1998 to
promote research and development in
embedded systems engineering using
state-of-the-art VLSI CAD tools and
technology.
70
Selected Research Projects
FPGA Based High Performance
Architecture for Move Generation in
Computer Chess
71
Selected Research Projects
Multiple Sequence Families with
Efficient Hardware Architecture for
use in Spread Spectrum
Watermarking for Multimedia
Game Tree Search on a Massively
Parallel SIMD Machine
Massively Parallel Implementation of
a Pattern Based Evaluation Function
for Computer Chess
72
Technology Comparison
Application
Slide - 73
Specific
Time to Market: Design Cycle
ASIC design cycle is longer compared to FPGA because
more time has to be spent on verification, timing closure
and prototyping.
Application
Slide - 74
Specific
Development Costs: Process Geometry
 ASIC NRE cost is rapidly increasing with process improvements
while NRE is almost non-existent in FPGAs.
 However, ASIC remains the preferred option only for very high
volume productions.
Application
Slide - 75
Specific
Time to Market: A Hybrid Approach
 FPGAs can be used for a quick entry into the market
(FPGA-to-ASIC conversion can be done later)
– The convergence of the ASIC and FPGA design methodology
makes it easy to adopt an ‘FPGA first ASIC later’ approach.
– RTL coding should be done with future FPGA-to-ASIC
transition in mind.
Application
Slide - 76
Specific
Upgradability
 With FPGAs, it is possible to extend product life by
adding new features
– Quick response to changing standards
– Apply bug fixes by just downloading a new configuration
file to the device.
Application
Slide - 77
Specific
Application
Slide - 78
Specific
Typical
ASIC
Flow
Application
Slide - 79
Specific
Convergence of ASIC & FPGA Design Flows
Application
Slide - 80
Specific
Design Cycle Time
Source: NEC
Application
Slide - 82
Specific