Digital Systems Design

TECHNISCHE
UNIVERSITÄT
ILMENAU
Digital Systems Design

Integrated Hard- and Software Systems
http://www.tu-ilmenau.de/ihs
Andreas Mitschele-Thiel
Dieter Wuttke
Part I
IQtroduction
2
Motivation for the Course – Why is this important?
What are „Integrated HW/SW-Systems“?
Any computer system consists of hardware and software!
But: HW is often hidden and not considered important by SW developers
Indicators that HW is important:
 capacity Systems where HW/SW relation is obvious:

 responsiveness and delay  embedded systems
 predictability  real-time systems
 reliability  reliable systems
 safety  safety-critical systems
 power consumption
 cost
 ...
=> Knowledge of HW/SW interaction is required!
3
Embedded programming without knowledge of HW/SW integration
Image “borrowed” from an Iomega advertisement for Y2K software and disk drives,
Scientific American, September 1999.
4
Information Technology Scenario
According to the International Data Corporation
 1997: 96% of all Internet-access devices shipped in the United

States were PCs
 End of 2002: less than 50% of them were PCs

Instead, digital set-top boxes, cell phones, and personal digital
assistants are sold
 Today: the most selling Internet-access devices are mobile phones
5
Objectives
Let’s assume you are employed as a system architect with some company and
faced with the following task:
Given is some problem to be solved by some kind of computer system, e.g. an

ABS system for a car, a fly-by-wire system for a new Airbus, the control of a
microwave oven, a mobile phone, a corporate IP router, or the control unit of
some medical x-ray equipment.
The different systems have very different requirements, including real-time
constraints, reliability, cost, etc.
Your task is to select the most appropriate system design including HW

and SW, as well as the selection of the most appropriate design method and
tools.
The goal of the course is to provide the knowledge to make these kind of
decisions.
6
Content IHS 2
 Motivation and overview
 Development process and tasks
 System requirements
 Behavioral models overview
 FSM, NDFSM, FSM composition
 PN, DFG, CFG, CDFG
 Specification languages details
 Statecharts
 SDL
 VHDL
 SystemC
 Functional validation
 Performance/temporal validation
 Optimization
7
Organisational Stuff
Course prerequisites:
 Basics of digital systems
 Basics of computer architecture and computer design
Slides and additional information will be provided at

http://www.tu-ilmenau.de/ics
Instructor contact:
Andreas Mitschele-Thiel Dr. Dieter Wuttke
Office: Zusebau, Room 1032 Office: Zusebau, Room 1067
Email: mitsch@tu-ilmenau.de Email: dieter.wuttke@tu-ilmenau.de
Phone: 03677-69-2819 Phone: 03677-69-2820
Dr. Karsten Henke

Office: Zusebau, Room 2078
Email: karsten.henke@tu-ilmenau.de
Phone: 03677-69-1443
10
Introduction
 Integrated HW/SW systems by example

 Issues of HW/SW systems development
11
Some Examples of Systems with Tight HW/SW Interaction
Communication systems
 GSM/UMTS network elements
 IP router (QoS support)
 ATM switch
 GSM/UMTS mobile
Safety-critical systems
 fly-by-wire system
 ABS, ASR, ESP, etc.
 train control
 control of physical and chemical processes
Embedded systems (not user-programable)

 every-day-appliances (microwave oven, vending machine, mobile phone, ...)
 ABS
 ticket machine
 ...
12
Example: UMTS Network
UTRAN CN
RNS
CS Domain
User Node B
Equipment
(UE)
MSC/VLR GMSC
RNC
Node B Iub Registers

Iur
RNS HLR/AuC/EIR
Node B
SGSN Gn GGSN
RNC
PS Domain
UE Iub
Node B
Uu Iu
13
Example: Digital Wireless Platform
Dedicated Logic uC core

and Memory (ARM)
Java
phone
Keypad,
Logic Accelerators book

VM Display
(bit level)
Control ARQ
A
Timing
D recovery
Equalizers MUD
Analog RF Adaptive
Filters Antenna
Algorithm
analog digital
DSP core
14Source: Berkeley Wireless Research Center

Example: Car Electronics
• More than 30% of the cost of a car is now in electronics
• 90% of all innovations will be based on electronic systems
15
Example: Modern Vehicles, an Electronic System
IVHS Infrastructure Safety-critical System
Cellular Body
Phone Control
Navigation Info/Comms/ Stereo/CD Suspension Vehicle Transmission

AV Bus CAN Bus
GPS Display ECU ABS
Electronic Toll Collection

Collision Avoidance
Wireless Communications/
Vehicle ID Tracking
Data Global Positioning
SW Architecture Performance Modeling

Network Design/Analysis Function/Protocol Validation
Supplier Chain Integration
IVHS: Intelligent Vehicle Highway Systems

16ECU: Electronic Control Unit (Bordcomputer)
Example: Vehicles, a Consumer Electronic System
Cellular
Phone Vehicle Web Site
Technology
Navigation Info/Comms/ Stereo/CD
AV Bus
GPS Display Comms
SW Shell
GSM/GPRS
Windows CE,
UMTS, Paging
NT, MAC, BIOS
Compression
User I/F
Output & I/F SW Apps
Voice Synthesis
Serial, Ethernet Browser,
Challenges Diagnostics
Voice Control
Comms, User Apps
Stylus, ETC
• Minimum Technology to
Satisfy User Requirements
• Usability Display
Processor
Heads Up,
• Integrate with Other Vehicle RISC, PowerPC
Flat Panel
Systems X86, Hitachi RISC
Graphics
• Add Functions Without
Adding the Cost
17
Example: Smart Buildings
Dense wireless network of sensor,

monitor, and actuator nodes
• Disaster mitigation, traffic management and control
• Integrated patient monitoring, diagnostics, and drug administration
• Automated manufacturing and intelligent assembly
• Toys, Interactive Musea
• Task: ambient conditioning systems allow thermal conditioning in small, localized

zones, to be individually controlled by building occupants, creating “micro-
climates within a building”
• Other functions: security, identification and personalization, object tagging,
18 seismic monitoring
Example: Home Networking Application (Subnet) Clusters
Stereo
Web-TV
Voice Video STB TV
Phone Phone
Entertainment
DVD Based Cam
PDA Telecom Player Corder
Based
PC-1
PC-2 laptop VCR
Still
Camera
Intercom Video
PC/Data Game
Printer Based Internet

Access
Door Sprinklers
Motion Sensors
Detectors Window Utility Toasters
Sensors Customization
Appliance
Security Based
Based
Video
surveillance
Light
Control Ovens
Climate
Control
Smoke Audio
Detectors Alarms
Clocks
19
Example: Smart Dust Components
Laser diode
III-V process
Passive CCR comm.

MEMS/polysilicon
Active beam steering laser comm.
MEMS/optical quality polysilicon
Analog I/O, DSP, Control

Sensor COTS CMOS
MEMS/bulk, surface, ... Power capacitor
Multi-layer ceramic
Solar cell
CMOS or III-V
Thick film battery

Sol/gel V2O5
20 1-2 mm
Example: Airborne Dust
Mapleseed solar cell 1-5 cm

MEMS/Hexsil/SOI
Controlled auto-rotator
Rocket dust MEMS/Hexsil/SOI
MEMS/Hexsil/SOI
21
Example: Synthetic Insects
Source: R. Yeh, K. Pister, UCB/BSAC

22
Definition of Embedded Systems
An embedded system
 employs a combination of hardware & software (a “computational engine”)
to perform a specific function
 is part of a larger system that may not be a “computer”
 works in a reactive and time-constrained environment
 Software is used for providing features and flexibility

 Hardware = {Processors, ASICs, Memory,...} is used for performance (&
sometimes security)
=> Integrated HW/SW system
Typical characteristics:
 perform a small set of highly specific functions (not "general purpose”)
 increasingly high-performance & real-time constrained
 power, cost and reliability are often important issues
23
What is a System Anyway?
environment
sensor
sensor
sensor
sensor actor
sensor
processing
 Environment to environment
 Sensors + Information Processing + Actuators
 Computer is a system
 Microprocessor (ASCI, memory) is not
24
Design Process: Behavior vs. Structure
Performance models:
Models of emb. SW, comm. and
computation comp. resources
Requirements
System System
Validation Behavior Architecture
HW/SW
Behavior partitioning,
Mapping
Simulation scheduling
Performance
Simulation
SW
Synthesi Communication estimation
s Refinement
Flow To Implementation
25
Will the system solution match the original system spec?
• Limited synergies between HW & SW

teams
• Long complex flows in which teams do
not reconcile efforts until the end
• High degree of risk that devices will be
Concept fully functional
Software
? Hardware
• HW or IP Selection
• Design
• Verification
• System Test
Clock
VCXO
Select
Tx Synth/ STM
Optics MUX I/F
Line STS
OHP Cell/
Rx CDR/ I/F STS XC SPE Data Packet
Optics DeMUX PP Map Framer
I/F
mP
26
Important Lessons
 Embedded systems market has surpassed the PC market
 Communication is everywhere
 Systems differ in many aspects (functionality, time constraints,

reliability, safety, cost, power consumption, …)
 Design methodologies are important to handle complexity

(behavioural and structural descriptions and verification)
 Methods for HW design align with modern SW design

but: HW knowledge is essential to optimize solutions
(cost, capacity, response time, reliability, safety, power, ...)
27
Part II
Development Process
2
System Development – Poor Process
Poor common infrastructure. Weak specialization of functions.

Poor resource management. Poor planning.
3
System Development – Ordered Process
Good planning.
Good common infrastructure.
Specialization of functions.
Good resource management.
4
General Development Tasks
Analysis
 of the requirements of the environment to the system
Modelling
 the system to be designed and experimenting with algorithms involved
Refining (or partitioning)

 the function to be implemented into smaller, interacting pieces
HW/SW partitioning
 allocating elements in the refined model to either HW units or SW running on
custom hardware or general microprocessors
Scheduling
 the times at which the functions are executed (this is important when several
modules in the partition share a single hardware unit)
5
System Development Process – The Theory
Waterfall model
Analysis
Design
Implementation
Development is not a pure top-down process Integration

 use of subcomponents from the shelf
=> bottom-up Maintenance
 lack of accurate estimation in early phases
=> feedback
 lack of confidence in feasibility
=> feasibility studies, prototyping
=> in practice the development process is a mixture of

6 bottom-up and top-down design
Analysis Phase and Subphases
Analysis
Problem
analysis
Feasibility
study
Requirements
analysis
The goals of the analysis phase are

 to identify the purpose, merit and risks of developing the product, and
 to identify the purpose of the product and to understand its exact requirements
7
Problem Analysis
 Preliminary study to analyse important needs of the environment to be
supported by the system
 discuss principal solution strategies
Analysis
Problem
analysis
Feasibility
study
Requirements
analysis
=> Problem definition (German: Lastenheft)

• project goals (business objectives)
• product goals, scope and major directions of the development
• specifies variables and constants of the product to be developed
• identifies resources necessary to conduct the development (capital

investments, human resources)
8
Feasibility Study
Check the feasibility of the product development and the product
 technical feasibility (availability of efficient algorithms, ...)
 economic feasibility (time-to-market,
market window, investment, pay-off) Analysis
Problem
analysis
Feasibility
Focus of the feasibility study are study
Requirements
critical issues of the system analysis
in order to
improve confidence in the successful
completion of the project
=> Output (depends on exact focus of feasibility study)

• info on expected cost and benefits of the project
• info on technological and financial risks of project
• needed resources for development and/or marketing
• evaluation of possible technical alternatives

9
Requirements Analysis
Detailed study of the requirements of the system as seen from its environment
 Identify, analyze and classify the specific requirements of the product to be
developed
The solution, i.e. the question of how the Analysis
Problem
requirements are met is typically left open analysis
Feasibility
study
Requirements
analysis
=> Requirements specification (German: Pflichtenheft)

• Complete and correct
• Defines output of the development process (deliverables)
• Definition of the interfaces to the environment
• Definition of overall functionality of the product
• Performance requirements
• Contraints on SW, operating system and HW
• Possibly guidelines for internal structure of the product
10
Requirements Definition: Contents
 Identification of the system (interfaces to the environment)
 Functional requirements (functionality provided at the interfaces)
 Temporal and performance requirements (throughput, response time, delay,
jitter)
 Fault-tolerance and reliability
 Quality (absence of errors)
 Safety
 Operating platform (OS, general HW)
 Power consumption
 Heat disipation
 Operating environment (operating temperature, shock-, dust-resistance, etc.)
 Size
 Mechanical construction
 EMC (Tx/Rx) We will see methods to ensure that
 Maintainability
the requirements are met in the
 Extendability
 Support design section
 Documentation
 Cost (development, deployment and operation)
 Date of completion
11 ...
Design and Subphases
Design
Architectural
design
Detailed
design
Implementation
design
Purpose:
 decide how the system meets the requirements -> inside view
 focus on the solution
12
Design and Subphases
Architectural Design (Top-level Design) Design

 define the modules of the system and
Architectural
their interfaces design
 goal: maximize internal coherence and
Detailed
minimize intermodule coordination design
 modules are typically functional entities Implementation
but may be structural entities as well design
(structural vs. behavioral modularization)
Detailed Design (Module Design)

 define the functional/behavioral details of
each module independent of the
implementation technique, e.g. its
algorithms When is the behavior of
the system decided and
Implementation Design when the structure?
 take into account the details of the used
implementation technique, e.g. interfaces
to operating systems and hardware
13
The Design Space: A Complex Optimization Problem
 System architecture – overall architecture (structural model, or mapping of

functions on HW, etc.)
 Design methods (design tools and specification languages)
 HW selection (System-on-Chip, ASIC, FPGA, DSP, NP, uC, uP)
 HW design methods (languages, HL-Synthesis, RTL-Synthesis, …)
 HW description (algorithms and implementation)
 HW mapping and scheduling
 SW description (programming languages, algorithms and implementation)
 SW mapping and scheduling
 HW/SW interfacing
 Interfacing with environment (embedding)
 Operating system (OS) support
 Make or buy (HW, SW, OS)
 Available human resources and know-how
 ...
14
Design Models and Views – An Overview
Different modeling approaches focus on different aspects of the system

&
&
&
structural
view
msc data_transfer
application transport network medium network transport application
data-oriented functional
system
view view
behavioral
view
15
Behavioral Models
Behavioral models describe the behavior of the system or parts hereof
Implementation of behaviroal models may be in SW or HW

– however some models are better suited for HW design others better for SW
Examples: C program, Petri net, state diagram, data flow graph
KEY_ON => START_TIMER WAIT

o(n) = c1 * i(n) + c2 * i(n-1)
KEY_OFF or END_TIMER_5 =>
OFF
BELT _ON => ALARM_ON
END_TIMER_10 or
BELT_ON or
ALARM
KEY_OFF => ALARM_OFF
Send msg
Process 1 Process 2
Send Ack
Receive Ack
16
Structural Models
Structural models focus on the structure of the system, i.e. its components,
modules, etc., rather than its behavior
Structural blocks may be

 abstract (ALUs, processors, memory, busses, chipsets, boards) or
 detailed (flip-flops, gatter)
Examples: netlist, architectural

block diagram
&
&
&
17
Behavior and Structure
Models of Structural model

computation Requirements
System System
Validation Behavior Architecture
HW/SW
Behavior partitioning
Mapping
Simulation ,
scheduling
Performance
Simulation
Communication
Refinement
Synthesis
Flow To Implementation
18
Behavior meets Structure: The Optimization Problem
 There are numerous solutions to define
Behavioral Space the behavior consistent with the given
requirements (algorithms, data structures)
 There are numerous ways to model the
defined behavior of the system
 There are numerous solutions to define

the structure of the system
(Microcontroller, DSP, customized HW,
configurable HW, ...)
 There are multiple ways to model the
defined structure of the system
System Platform
 Design is about mapping the behavior
(including data and functions) on the
structure such that all requirements are
fulfilled (cost, time constraints, capacity,
reliability, maintainability, power
consumption, ...)
 Mapping is a very complex optimization

problem
19 Structural Space
Design: Behavior vs. Structure
Behavioral specifications describe the functionality of the system using some
modeling or programming language
 behavior specifications may be
 abstract models (state charts, UML, SDL) or
 concrete programs (C, VHDL, SystemC)
 behavioral specifications may be

 executed/implemented on real HW (C program, assembler) or
 simulated on virtual HW (VHDL, SystemC, SDL)
Behavioral specifications ensure that

 the functional requirements are met
 however there is no confidence in non-functional aspects of the system, e.g.
performance, real-time, fault tolerance, cost, power consumption, ...
Structural specifications are needed to implement the system in HW
So, when is the best point in time to decide the structure?

20
Implementation
Prerequisites:
 Functional details as algorithms, etc. are specified
 HW components are selected
 HW/SW partitioning may be decided
 ...
Tasks:
 coding of functions, algorithms, etc. in the selected implementation language
 test of the modules and components in isolation emulating the environment of
the modules/components
Notes:
 provided the design is complete and correct this is straight-forward
 the implementation phase represents a small part of the development process
(appr. 20% for pure SW projects)
21
Validation Methods
 By construction
 Property is inherent.
 By verification
 Property is provable.
 By testing
 Check behavior of (all) inputs.
 By simulation
 Check behavior in the model world.
 By intuition
 Property is true. I just know it is.
 By assertion
 Property is true. Wanna make something of it?
 By intimidation
 Don’t even try to doubt whether it is true.
It is generally better to be higher in this list!

Validation is a continuous process applied
 in different phases of the development process and
 to different models of the system
to ensure conformance with various properties/requirements of the system or its
22components (behavior, temporal requirements, shock resistance, ...)
Integration
Purpose:
 ensure compliance with system requirements
 complete the system for delivery
Tasks:
 System integration: subsequent addition of HW components and SW
modules to the system until the final system is established
 Integration testing: stepwise testing of system (requires knowledge of the
system as a whole)
 System testing: test after all parts have been integrated
Notes:
 Testing may be applied to almost all requirements or properties of systems,
system components or modules (functionality, performance, reliability, termal
resistance, shock resistance, ergonomics, man-machine interface,
documentation, ...)
 Testing is the most popular validation method in practice
23
Maintenance
 involved during the whole lifetime of a system, from delivery till removal from
service
 deal with changes due to

 changing environments,
 changing functional or
 performance requirements
 removal of errors
Note: often the maintenance cost are much greater than the development cost
24
Process Models – Overview
 Waterfall model (top-down)
 engineering approach to building a house, bridge, etc.
 no feedback assumed
 Iterative waterfall model
 validation and feedback to earlier stages
 Evolutionary model
 system development process is considered an evolution of prototypes
 requirements are subsequently added to the system
 Spiral model
 generalisation of various process models (meta model)
 multiple development cycles including validation
 V model
 continuous validation with real world/environment
 Component-based (bottom-up)
 compose the system of a set of predefined components (object-based)
25
Classic Waterfall Model & Iterative Waterfall Model
Classic waterfall model (top-down)

 engineering approach to building a
house, bridge, etc.
Analysis
 no feedback assumed
Design
Implementation
Integration
Maintenance
Iterative waterfall model

 validation and feedback to earlier stages
26
Evolutionary Model
Limits of the waterfall model
 often the requirements are
incomplete in the beginning
waterfall model is not
appropriate where requirements analysis
are not well understood or not
well defined design
 with the waterfall model,
there are no intermediate implementation
product releases modification of
product definition
test
Idea of the evolutionary model:
 provide intermediate product new prototype
releases needed y
 refine and extend n
requirements during the
development process
27
Spiral Model
Meta model supporting the flexible combination of the above approaches
define objectives, evaluate alternatives,

alternatives and identify and resolve
constraints risks
review results; develop

plan next iteration and verify
28
V Model
Extension of the waterfall model to integrate quality assurance (verification and
validation)
validation
requirements application scenarios acceptance
definition test
top-level test cases system

design test
verification
detailed test cases integration
design test
test
module cases module
implementation test
Validation: ensure the system conforms with the needs of the environment (are we
building the right system? – product quality)
Verification: ensures that the outcome of a development phase exactly conforms to
29the specification provided as input (is the system built right? – process quality)
Traditional (Early Partitioning) vs. Codesign Approach
Early Partitioning (Structure First) HW/SW Codesign (Behavior First)
system architectur system description
HW descr. SW descr. system architectur
HW impl. SW impl. HW impl. SW impl.
prototyp/product prototyp/product
+ optimized descriptions/models for + joint system description/model

HW and SW parts, respectively eases validation and integration
- lack of flexibility wrt HW/SW - joint description is not optimized for
partitioning both HW and SW
30- problems with HW/SW integration + flexibility wrt. HW/SW partitioning
Traditional vs. Codesign Approach (Polis, Cadence VCC)
Traditional System Design VCC Separation and Mapping
System System
Behavior Architecture
1 2
System System
Behavior Architecture Mapping
3
Behavior on
System System
Architecture
Implementation Performance
Refine
4 Implementation
of System
Data Sheets Executable

on paper Data Sheets
31
References
System Focus
 D. Gajski, F. Vahid, S. Narayan, J. Gong: Specification and Design of
Embedded Systems. Prentice Hall, 1994.
 A. Mitschele-Thiel: Systems Engineering with SDL – Developing Performance-
Critical Communication Systems. Wiley, 2001. (section 2.1.2)
 J. Teich: Digitale Hardware/Software Systeme. Springer, 1997.
Software Focus
 H. Balzert: Lehrbuch der Software-Technik – Band 1: Softwareentwicklung.
Spektrum-Verlag, 2001.
 R. S. Pressman: Software Engineering – A Practicioner´s Approach. Fourth
Edition, McGraw Hill, 1997.
32
Part III
Requirements
2
Requirements
 Analysis process
 Functional requirements
 Performance requirements
 Real-time requirements
 Safety and reliability
 Principles and elements of requirements analysis
3
The Importance of Requirements
Proper definition of the requirements is vital to ensure quality!

4
Review of the Development Process
Analysis
Problem
analysis
Feasibility
study
Requirements
analysis
Design
The requirements analysis is a detailed study of the
requirements of the system as seen from its environment.
Major tasks are to
 identify,
 analyze and
 classify
the requirements of the product to be built
5
Requirements Definition: Contents
 Identification of the system (interfaces to the environment)
 Functional requirements (functionality provided at the interfaces)
 Temporal and performance requirements (throughput, response time, delay,
jitter)
 Fault-tolerance and reliability
 Quality (absence of errors)
 Safety
 Operating platform (OS, general HW)
 Power consumption
 Heat disipation
 Operating environment (operating temperature, shock-, dust-resistance, etc.)
 Size
 Mechanical construction
 EMC (Tx/Rx)
 Maintainability
 Extendability
 Support
 Documentation
 Cost (development, deployment and operation)
 Date of completion => let‘s take a look at
6 ... some details
Functional Requirements
Definition of the exact behavior of the system as seen at its interfaces
Description technique highly depends on the kind of system:

 (state) control system -> state machine
 transformational system -> data flow model
=> see section on behavioral models for details
Example of control system: Example of transformational system:

seat belt control FIR filter o(n) = c1 * i(n) + c2 * i(n-1)
i(n)
i(n)
KEY_ON => START_TIMER WAIT * c1
c1 * i(n)
OFF
KEY_OFF or END_TIMER_5 => S
* c2 + o(n)
END_TIMER_10 or i(n-1) c2 * i(n-1)
BELT_ON or
ALARM
7
Performance Requirements
Important performance requirements
Capacity
response time

 Response time
 Jitter
Examples of performance requirements:

 capacity: number (and kind) of events
processed per second
 response-time: time to process an event load
(95% percentile)
The performance of the system depends on
the load imposed on it, i.e. the traffic model
The performance is highly influenced by the

design, especially
 the module/component design
 the available processing and
communication resources Performance cannot be „added on“
 the scheduling strategy to the implementation
8
Real-time (Temporal) Requirements
usefulness hard or firm real-time requirement

of result soft real-time requirement
deadline time
Definitions:
 If the result is useful even after the deadline, we call the deadline soft.
 If the result is of no use after the deadline has passed, the deadline is called firm.
 If a catastrophe could result if a strict deadline is missed, the deadline is called
hard.
 A real-time computer system that has to meet at least one hard deadline is called
a hard real-time system.
System design for hard- and soft real-time systems is fundamentally different.
9
Real-time (Temporal) Requirements
Examples:
 soft deadlines
 public transportation system
 airport luggage transport system
 firm deadlines
 audio processing
 video processing
 hard deadlines
 control of nuclear or chemical processes (chain reaction)
 railway traffic control
 air traffic control
10
Real-time Systems – Classification
 On the basis of the external requirements

 hard/firm real-time versus soft real-time
 fail safe vs. fail operational (e.g. train control system vs. fly-by-wire
system)
 On the basis of the design and implementation

 guaranteed timeliness vs. best effort
 resource adequacy vs. no resource adequacy (sufficient computational
resources to handle all specified peak loads and fault scenarios)
 event triggered vs. time triggered
11
Time Triggered (TT) vs. Event Triggered (ET) Systems
A system is Time Triggered (TT) if the control signals, such as
 sending and receiving of messages
 recognition of an external state change
are derived solely from the progression of a (global) notion of time.
A system is Event Triggered (ET) if the control signals are derived solely from
the occurrence of events, e.g.,
 termination of a task
 reception of a message
 an external interrupt.
Note that the triggering method is often an attribute of the implementation and
not necessarily a requirement.
12
Safety Requirements: Fail-Safe vs. Fail-Operational
Safety requirements define the action taken in the case of a failure.
A system is fail-safe if there is a safe state in the environment that can be

reached in case of a system failure, e.g. ABS, train signaling system.
In a fail-safe application the computer has to have a high error detection
coverage.
Fail safeness is a characteristic of the application, not the computer system.
A system is fail-operational, if no safe state can be reached in case of a system

failure, e.g. a flight control system aboard an airplane.
In fail-operational applications the computer system has to provide a minimum
level of service, even after the occurrence of a fault.
13
Reliability Requirements
Reliability denotes the probability for a failure or absence from failure of a
system
Examples of reliability figures are

 MTTF (mean time to failure)
 MTBF (mean time between failures)
 probability for up-time (e.g. 99.995%)
The reliability of the system can be estimated/calculated (in theory) from the
reliability of its components
A system that ensures that it still functions correctly even in the case of failure of
some components is called a fault tolerant system (i.e. it is able to tolerate faults
of single components of the system)
14
Predictability in Rare Event Situations
A rare event is an important event that occurs very infrequently during the
lifetime of a system, e.g. the rupture of a pipe in a nuclear reactor.
A rare event can give rise to many correlated service requests (e.g. an alarm
shower).
In a number of applications, the merit of a system depends on the predictable

performance in rare event scenarios, e.g. a flight control system.
In most cases, typical workload testing will not cover the rare event scenario.
15
Principles and Elements of the Analysis Model
Guidelines for the analysis:
 understand the problem first! (before you begin to create the analysis model)
 record origin and reason for every requirement
 use multiple views of requirements (data model, functional model, behavioral
models)
 priorize requirements
 eliminate ambiquities
Elements of the analysis model:

 data dictionary
 process specification (data-flow diagram)
 control specification (state-transition diagram)
 data object description (entity-relationship diagram)
 functional specification (sequence diagram)
Specific methods and tools for various application areas have been proposed,
e.g. real-time systems, transformational systems, control systems,
communication systems, etc.
16
References
 H. Balzert: Lehrbuch der Software-Technik – Band 1: Softwareentwicklung.
Spektrum-Verlag, 2001.
 R. S. Pressman: Software Engineering – A Practicioner´s Approach. Fourth
Edition, 1997. (Chapter 12: Analysis Modeling)
Critical Communication Systems. Wiley, 2001.
 B. Thomé (Editor): Systems Engineering – Principles and Practice of
Computer-based Systems Engineering, Wiley, 1993.
17
Part IV
Behavioral Models and
Specification Languages
1
Behavioral Models and Specification Languages
Basic Concepts
 concurrency
 hierarchy
 communication
 synchronisation
Behavioral Models  exception handling
 Finite State Machine  non-determinism
(FSM)  timing
 NDFSM
 composed FSM
 Petri Net (PN)
 Data Flow Graph (DFG)
 Control Flow Graph (CFG)
 Control/Data Flow Graph Specification Languages
(CDFG)  StateCharts
 SDL
 VHDL
 SystemC
 ...
3
Finite State Machines (FSM)
Functional decomposition into states of operation

 finite states
 transitions between states
 event triggered transitions
 neither concurrency nor time (sequential FSMs)
Typical applications:
 reactive (control) systems
 protocols (telecom, computers, ...)
4
Finite State Machines – Control Algorithms
5
Finite State Machines – Discussion
6
Moore vs. Mealy Automata
Theoretically, same computational power
In practice, different characteristics
 Moore machines:
 non-reactive
(response delayed by 1 cycle – δ n
τ a
µ
X Z Z Y
clocked change of output only)
 easy to design
(always well-defined)
 good for SW implementation
 software is always “slow”
 Mealy machines:
a
 reactive (immediate response Z
to changes of input) δ τ λ
n
 hard to compose X Z Y
 problematic SW implementation
 due to immediate response to changes of input (interrupts/polling)
 software must be “fast enough”
 may be needed in hardware, for speed
7
8
Finite State Machines – Example: state diagram (informal)
9
Advantages:
 Easy to use (graphical languages)
 Powerful algorithms for
 synthesis (SW and HW)
 verification
Disadvantages:
 Sometimes over-specify implementation
(sequencing is fully specified)

 Number of states can be unmanageable
 Numerical computations cannot be specified compactly

(need Extended FSMs)
10
Finite State Machines - Extensions
Divide and conquer
⇒ Nondeterminism
⇒ Parallel automata
⇒ Processes
⇒ Communication
⇒ Hierarchy
⇒ Graphical support
⇒ Extended formal semantic
11
NDFSM: Time Range
Special case of unspecified/unknown behavior, but so common to deserve

special treatment for efficiency
Example: nondeterministic delay (between 6 and 10 s)
START => SEC => SEC => SEC =>

1 2 3 4
SEC =>
START =>
0
SEC => END 5
SEC => END
9 SEC =>
END SEC =>
SEC =>
END 6
SEC =>
8 7 SEC =>
SEC =>
12
NDFSMs and FSMs
 Formally FSMs and NDFSMs are equivalent

(Rabin-Scott construction, Rabin ‘59)
 In practice, NDFSMs are often more compact
(exponential blowup for determinization)
Example: non-deterministic selection Equivalent deterministic FSM

of transition a in state s1
s1
c
s1 c a
a c b
a s2,s3 s3
b
s3 a b a
s2
a
s2
13
Modeling Concurrency – parallel automata
Systems are typically composed of chunks of rather independent functionalities,

e.g. seat belt control || timer || driver
Systems may be physically distributed,
e.g. peer protocol automata
Need to compose parts described by sequential FSMs
 construct a complete model of the system
 building the cartesian product results in state explosion
Approach
 Describe the system using a number of separate FSMs and interconnect them
Issue
 How do the interconnected FSMs talk to each other?
Fundamental hypothesis:
all the FSMs change state together (synchronicity)
System state = Cartesian product of component states
(state explosion may be a problem...)
14
FSM Composition – Example
Example: seat belt control || timer

Belt OFF
Timer
Control END_TIMER_10 or
BELT_ON or
ALARM
Belt control:
• 5 sec after the car key is switched on, an alarm signal should be on as long as
the belt is not locked.
• After 10 sec the alarm should be switched off
15
Example: seat belt control || timer

Belt OFF
Timer
Control END_TIMER_10 or
BELT_ON or
ALARM
START_TIMER => SEC => SEC => SEC =>

1 2 3 4 SEC =>
START_TIMER => END_TIMER_5
SEC =>
SEC => SEC => SEC => SEC =>
0 END_TIMER_10
9 8 7 6 5
16
Cartesian product
KEY_ON and START_TIMER =>

START_TIMER m ust be coherent
OFF, 0 WAIT, 1 SEC and

not (KEY_OFF or BELT_ON) =>
not SEC and

(KEY_OFF or BELT_ON) =>
WAIT, 2
SEC and
OFF, 1
(KEY_OFF or BELT_ON) =>
OFF, 2
17
Finite State Machines - Extensions: parallel automata
18
FSM Extensions – Example: user interaction > Processes
19
FSM Extensions - Communication (MSC)
20
Hierarchical FSM models – StateCharts
Problem: how to reduce the size of the representation?

Harel’s classical papers on StateCharts (language) and bounded concurrency
(model): 3 orthogonal exponential reductions
 Hierarchy:
 state a “encloses” an FSM
 being in a means FSM in a is active
 states of a are called OR states a
odd
 used to model preemption and exceptions
 Concurrency: a1 a2
 two or more FSMs are simultaneously active even
 states are called AND states

done error
 Non-determinism:
 used to abstract behavior
recovery
21
StateCharts – Basic Principles
Basic principles:
 An extension of conventional FSMs
 Conventional FSMs are inappropriate for the behavioral description of complex
control
 flat and unstructured
 inherently sequential in nature
 StateCharts support
 repeated decomposition of states into sub-states in an AND/OR fashion,
combined with a
 synchronous communication mechanism (instantaneous broadcast)
State decomposition:
 OR-States have sub-states that are related to each other by exclusive-or
 AND-States have orthogonal state components (synchronous FSM composition)
 AND-decomposition can be carried out on any level of states (more
convenient than allowing only one level of communicating FSMs)
 Basic States have no sub-states (bottom of hierarchy)
 Root State have no parent states (top of hierarchy)
22
StateCharts – OR Decomposition
State U is an abstraction of states S and T
To be in state U the system must

be either in state S or in state T
e
U
f
S
S
e f
V V
g g
T f
T
h
h
23
Part V
High-level Synthesis
1
 Motivation for high-level synthesis

 Domains of the HW design
 Levels of abstractions
 Overview on synthesis methods
 High-level synthesis tasks and models
 ASAP and ALAP
 List scheduling
 Advanced Issues
3
Motivation for High-level Synthesis
Complexity problem: millions of transistors on a single chip
=> handcrafting of each single transistor is not possible
=> handcrafting of single gates is not possible
=> cost and time of the process require to do it right the first time
=> need design automation on more abstract levels
=> high-level synthesis
 algorithm synthesis
 HW/SW (system)
synthesis
Design automation ensures:

 speed-up the design process
 do it right the first time
=> time-to-market
4
Domains of HW Design
Y chart: design domains and abstraction levels
structural domain behavioral domain

EXOR: process (A, B)
A begin
=1 Y Y <= transport A xor B after 5 ns;
B end process;
t = 5 ns
layout PowerPC 750

abstraction
levels
physical domain (layout)

5
Abstraction Levels
processors,
memories, buses CFG, algorithms
registers, ALUs, MUXs register transfers
gates, flip-flops Boolean expressions
transistors transistor functions
transistor layout
cells
chips
boards
6 physical domain (layout)

Structural Synthesis
Structural synthesis is the translation
from a behavioral description into a
structural description
processors,
transistor layout
cells
chips
boards

Circuit Synthesis
 generates a transistor schematic from a set of input-output current, voltage

and frequency characteristics or equations
 transistor schematic contains transistor types, parameters and sizes
behavioral domain
structural domain
processors,
transistor layout
cells
chips
boards

Logic Synthesis
 translation of Boolean expressions into a netlist of components from a given
library of logic gates such as NAND, NOR, EXOR, etc.
-> see logic synthesis section for details
behavioral domain
structural domain
processors,
transistor layout
cells
chips
boards

Register-transfer Synthesis
 start with a set of states and a set of register-transfers in each state
 one state typically corresponds to a clock cycle (clock-accurate description)
 register-transfer synthesis generates the corresponding structures
in two parts
(a) a data path which is a structure of storage
elements and functional units that perform the
given register transfers, and structural domain
behavioral domain
(b) a control unit that controls the sequencing

of the states in the register-transfer description
processors,
transistor layout
cells
chips
boards

High-level synthesis (also called system synthesis or algorithmic synthesis) may
cover HW as well as SW parts of the system
 starts with a set of processes communicating through either shared variables or
message passing (an un-clocked description)
 generates a structure of processors, memories, controllers
and interface adapters from a set of system components
 each component can be described
behavioral domain
by a register-transfer description structural domain
processors,
transistor layout
cells
chips
boards

Levels of Synthesis
12
High-level Synthesis – Central Tasks
High-level synthesis deals with
 the algorithmic level (behavioral viewpoint)
 the system level (structural viewpoint)
Tasks of high-level synthesis

 (system) partitioning
 partitioning of a behavioral description or design structure into
subdescriptions or substructures
 reduce the problem size
 satisfy external constraints as chip size, pins per package, power
dissipation or wire length
 allocation
 selection of the number and types of structural entities
 mapping (Gajski: allocation, Teich: Bindung)
 assignment of data to storage units (registers)
 assignment of operations to functional units (ALUs, etc.)
 assignment of communications to busses or links
 scheduling (Teich: Ablaufplanung)
 temporal assignment of data and operations
13  derivation of controller (microprogram)

High-level Synthesis: Theory
Behavioral model:
GS = (VS, ES) is a directed acyclic graph where
 each node vS ∈ Vs represents a task and
 each arc eT = (vi, vj) ∈ ES defines a data dependency (execute vi before vj)
Resource model:
GR = (VR, ER) is a bipartite graph with
 VR = (VS ∪ VT) where
 VS specifies the nodes of the behavioral model
 VT specifies the nodes representing resource types
 (vS, vT) ∈ ER with vS ∈ Vs and vT ∈ VT specifies that vS may be implemented
by a resource node of type vT
 the cost function c denoting the cost of each instance of node type vT and
 the node execution time t denoting the latency of the execution of task vS on
a resource of type vT
14
Summary of Basic Concepts of Models and Languages
State transitions Programming constructs
 events triggering a state transition  specify sequential algorithm
(simple input, complex conditions) Communication
 computation associated with  shared variables (broadcast)
transition
 message passing
Concurrency
 synchronous vs. asynchronous
 decomposition of behavior in
concurrent entities Synchronization
 different levels of concurrency (job,  control-dependent (fork-join)
task-, statement-, operation-level)  data-dependent (data, event,
 data-driven (data dependencies) vs message)
control-driven concurrency (control Exception handling
dependencies)  immediate termination of current
 reduction of states behaviror
Hierarchy Non-determinism
 structural hierarchy (system, block,  choice between multiple transitions
process, procedure)  non-deterministic ordering
 behavioral hierarchy (hierarchical Timing
transitions, fork-join)
 timeouts
15  time constraints (e.g. exec. time)
Control vs. Data Flow Applications
Rough classification: Specification, synthesis and validation
 control: methods emphasize:
 don’t know when data arrive  for control:
(quick reaction)  event/reaction relation
 time of arrival often matters  response time

more than value (real-time scheduling for
 data: deadline satisfaction)
 data arrive in regular streams  priority among events and
(samples) processes
 values matter most  for data:
 functional dependency between
Distinction is important for: input and output

 specification (language, model, ...)  memory/time efficiency
 synthesis (scheduling, (data-flow scheduling for

optimization, ...) efficient pipelining)
 validation (simulation, formal  all events and processes are
verification, ...) equal
16
Control/Data Flow Graph (CDFG)
 also called sequence graph
 mixture of control and data flow graph
 hierarchy of sequential elements
 units model data flow
 hierarchy models control flow
 special nodes (for control operations)

 start/end node: NOP (no operation) – all inputs needed (AND), all outputs
needed (AND)
 branch node (BR) – one out of many outputs selected (OR)
 iteration (LOOP) – one out of two outputs selected (OR)
 procedure call (CALL) – lower hierarchy is executed exactly once
 attributes
 nodes: execution time, cost, ...
 arcs: conditions for branches and loops
17
DFG – Example
21
CDFG – Loop
22
Review of Models, Concepts and Languages
Basic Concepts
 concurrency
 hierarchy
 communication
 synchronisation
Behavioral Models
 exception handling
 Finite State Machine (FSM)
 non-determinism
 NDFSM
 timing
 composed FSM
 Petri Net (PN)
 Control/Data Flow Graph

(CDFG)
 StateCharts
 SDL
 VHDL
 SystemC
 ...
23
Data Flow Graph (DFG)
Powerful formalism for data-dominated applications
DFG support the specification of transformational systems:

 output is a function of the input
 set of actors (nodes) connected by a set of arcs representing the data flow
 no states, no external events to trigger state changes
 unbounded FIFO queues (main data store)
 no control nodes, e.g. branch, loop
DFG represent a partial ordered model of the computation

=> specification of problem-inherent dependencies only
=> suitable for scheduling and code generation
=> there is a relation between buffer dimensioning and scheduling
(static scheduling minimizes the number of buffers required)
Languages:
 graphical: Ptolemy (UCB), GRAPE (U. Leuven), SPW (Cadence), COSSAP
(Synopsys)
 textual: Silage (UCB, Mentor), Haskell, Lucid
24
High-level Synthesis: Example
Behavioral model:
* * * * +
1 2 6 8 10
* * + <
3 7 9 11
Resource model:
- * multiplier *
4 1 2
data * *
3 6
dependency
- * *
5 7 8
Note: behavior model does not - ALU

4 -
define clocking (different from 5
RT synthesis)
may be +
implemented 9 +
on 10
<
25 11
Scheduling with unlimited resources:
=> latency 4 T
t0
* 1 * 2 * * 8
+ 10
6
t1
* 3 * + 9
< 11
7
t2
- 4
t3
- 5
t4
26
Mapping and scheduling with limited resources:
 4 multipliers
 2 ALUs
=> latency 4 T t
0
* 1 * 2 * * 8
+ 10
6
t1
* 3 * + 9
< 11
7
t2
- 4
t3
- 5
t4
27
Mapping and scheduling with
t0
limited resources:
* 1
+ 10
 1 multiplier
t1
 1 ALU
* <
=> latency 7 T 2 11
t2
* 3
t3
* - 4
6
t4
* 7
t5
* 8
- 5
t6
+ 9
t7
28
ASAP Scheduling without Resource Constraints
ASAP (as soon as possible) scheduling without resource constraints:
 algorithm: for each time slot select node which has all predecessors assigned
 problem is solvable in polynomial time
t0
assign all nodes
without predecessors * * * * +
1 2 6 8 10
t1
assign nodes with
scheduled predecessors * 3 * + 9
< 11
7
t2
dito - 4
t3
dito
- 5
t4
29
ALAP Scheduling without Resource Constraints
ALAP (as late as possible) scheduling without resource constraints:
 algorithm: complementary to ASAP; start with nodes without successors
 problem is solvable in polynomial time
t0
dito
* 1 * 2
t1
dito * *
3 6
t2
assign nodes with
scheduled successor - 4 * * +
7 8 10
t3
assign all nodes
without sucessor - + 9
< 11
5
t4
30
Scheduling with Resource Constraints: ASAP Extension
Extensions to ASAP and ALAP, respectively
 compute schedule using ASAP (or ALAP)
 if a resource constraint is violated, move respective nodes
Example: extended ASAP (2 multiplier, 2 ALUs)
t0
* 1 * 2 * * 8
+ 10
7
t1
* * + < 11
3 76 9
t2
- 4 * *
6 8
t3
- 5 + 9
t4
31
Scheduling with Resource Constraints: List Scheduling
Apply global criteria to optimize the schedule t0
 derive priority for each node based on
* 1
+ 10
 length of path to sink/source or
t1
 laxity of node (i.e. the difference
between start according to ASAP and * 2
< 11
ALAP) or t2
 number of successor nodes (fanout)
* 3
Example: 1 multiplier, 1 ALU
t3
Priority assignment (according to length to sink):
* - 4
6
4 * 1
4 * 2
3 * 2 * 8
2 + 10 t4
6
* 7
3 * 3
2 * 1 + 9
1 < 11 t5
7
* 8
- 5
2 - 4
t6
+ 9
t7
32 - 5 1
Scheduling with Resource Constraints: List Scheduling
t0
Example:
 2 combined multiplier/ALU units t1 * *
1 2
 2 time units for multiplication
 1 time unit for ALU operation

t2
t3 * 6 * 3
Priority assignment (length to sink):
t4
6 * 1
6 * 2
5 * 3 * 8
2 + 10
6
t5 * 7 * 8
4 * 3
3 * 1 + 9
1 < 11
7
t6
- 4
+ 10
2 - 4 t7
- 5
+ 9
t8
1 - 5 <
11
33 t9
Advanced Topics of High-level Synthesis
Considered so far:
 mapping and scheduling without resources constraints
 mapping and scheduling with given number (and type) of resources
Advanced topics:
 mapping and scheduling with time constraints and open number of resources
 mapping and scheduling of periodic tasks
 mapping and scheduling in the presence of multiple resources with identical
functionality but different area-latency relations
 ...
The general mapping and scheduling problem is NP hard (optimal solution is not
computable in polynomial time)
Numerous heuristic optimization algorithms have been applied to the problem
34
References
 D. Gajski, N. Dutt, A. Wu, S. Lin: High-level Synthesis – Introduction to Chip
and System Design. Kluwer Academic Publishers, 1992.
 Bleck, Goedecke, Huss, Waldschmidt: Praktikum des modernen VLSI-
Entwurfs. B.G. Teubner, 1996
35
Models, Concepts and Languages
Basic Concepts
 concurrency
 hierarchy
 communication
 synchronisation
Behavioral Models
 non-determinism
 NDFSM
 timing
 composed FSM
 Petri Net (PN)
 Control/Data Flow Graph

(CDFG)
 StateCharts
 SDL
 VHDL
 SystemC
 ...
1
Synchronous vs. Asynchronous FSMs
Synchronous FSMs (e.g. StateCharts):
 communication by shared variables that are read and written in zero time
 communication and computation happens instantaneously at discrete time
instants
 all FSMs execute a transition simultaneously (lock-step)
 may be difficult to implement
 multi-rate specifications
 distributed/heterogeneous architectures
Asynchronous FSMs (e.g. SDL, CSP) :

 free to proceed independently
 do not execute a transition at the same time (except for CSP rendezvous)
 may need to share notion of time: synchronization
 easy to implement
Multitude of commercial and non-commercial graphical languages and tools:

 StateCharts, UML, SDL, StateFlow
 tool support for design, simulation, validation, code generation, HW
synthesis, …
5
StateCharts – Basic Principles
Basic principles:
 An extension of conventional FSMs
 Conventional FSMs are inappropriate for the behavioral description of complex
control
 flat and unstructured
 inherently sequential in nature
 StateCharts support
 repeated decomposition of states into sub-states in an AND/OR fashion,
combined with a
 synchronous communication mechanism (instantaneous broadcast)
 StateCharts describe behavioral aspects, additional (but less important)

 ModuleCharts can be used for structural aspects and
 ActivityCharts for data flow and control flow description
 Source: Science of Computer Programming 8 (1987) 231-274, North-Holland

 STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS·
 DavidHAREL, Department of Applied Mathematics, The Weizmann Institute of Science,
Rehovot, Israel
6
StateCharts – Syntax
 The general syntax of an expression labeling a transition in a StateChart is E(C)/A

where S,T are states
 E is the event that triggers the transition
 C is the condition that guards the transition

(cannot be taken unless c is true when e occurs)
 A is the action that is carried out if and when the transition is taken
 For each transition label:

 condition and action are optional
 an event can be the changing of a value
 standard comparisons (e.g. x > y) are allowed as conditions
 assignment statements (e.g. x := 10) are allowed as actions
7
StateCharts – Actions and Events
 An action A on the edge leaving a state may also appear as an event triggering
a transition going into an orthogonal state:
 a state transition broadcasts an event visible immediately to all other FSMs,
that can make transitions immediately and so on
 executing the first transition will immediately cause the second transition to
be taken simultaneously (problem in reality!!!)
 Actions and events may be associated to the execution of orthogonal

components: start(A), stopped(B)
 Entry / Exit actions in states
8
StateCharts – Hierarchy
State decomposition:
 OR-States have sub-states that are related to each other by exclusive-or

 AND-States have orthogonal state components (synchronous FSM composition)
 AND-decomposition can be carried out on any level of states (more
convenient than allowing only one level of communicating FSMs)
 Basic States have no sub-states (bottom of hierarchy)
 Root State have no parent states (top of hierarchy)
 Initialization:
 Default (or initial states) can be marked in each hierarchy level

 History connector to remember states in sub-states
 Combination of default state on first start and history for further steps
9
StateCharts – OR Decomposition
State U is an abstraction of states S and T
To be in state U the system must

be either in state S or in state T
e
U
f
S
S
e f
V V
g g
T f
T
h
h
10
StateCharts – Top Down Design
State V is an abstraction of states S and U
11
StateCharts – Default State
Flat structure Hierarchical structure
12
StateCharts – Default State
Flat structure Hierarchical structure
13
StateCharts – Exit on Sub-States
Incorrect (b=c ???) correct
14
StateCharts – Default State and History
Default: “off” on first activation Same meaning

Then: history
15
StateCharts – AND State
Parallel structure: n+m states

Flat structure: ???
16
StateCharts – AND State
Flat structure: equivalent FSM ! n*m states

17
StateCharts – external transition variants to AND States
Entry of top state (e.g. caused by event “n”) activates all parallel automata
18 Leaving of sub-state (e.g. caused by “h (inS)”) deactivates the top state A
StateCharts – external transition variants to AND States
Entry of top state (e.g. caused by event “n”) activates all parallel automata
19 Leaving of sub-state (e.g. caused by “h (inS)”) deactivates the top state A
StateCharts – Action on Entry and/or Exit
20
StateCharts – Synchrony Hypothesis
21
StateCharts – Synchrony Problem
22
StateCharts – Microsteps
23
StateCharts – Example
24
StateCharts – AND Decomposition <> Composition
To be in state U the system

V,W U must be both in states S and T
k
V,Y
V,Z S T
k
e V Z
X,Y
X,Z e W
e X e
Y
k X,W
Q
Q R
R
25
StateCharts – Summary
26
Asynchronous Communication
Blocking vs. non-Blocking A B
 blocking read (receiver waits for sender)

 reading process can not test for emptiness of input
 must wait for input to arrive before proceeding
 blocking write (sender waits for receiver)
 writing process must wait for successful write before continue
Languages
 blocking write/blocking read (CSP, CCS)
 non-blocking write/blocking read (FIFO, CFSMs, SDL)
 non-blocking write/non-blocking read (shared variables)
27
Asynchronous Communication – Buffering
A B
 Buffers used to adapt when sender and receiver have different rate
 size of buffer?
 Lossless vs. lossy
 events/tokens may be lost
 bounded memory: overflow or overwriting
 need to block the sender
 Single vs. multiple read

 result of each write can be read at most once or several times
 Pure FIFO
 prioritized events
 out of order access to FIFO
28
Communication Mechanisms
 Rendez-Vous (CSP)
 No space is allocated for shared data, processes need to synchronize in
some specific points to exchange data
 Read and write occur simultaneously
 Shared memory
 Multiple non-destructive reads are possible
 Writes delete previously stored data
 Buffered (FIFO)
 Bounded (ECFSMs, CFSMs)
 Unbounded (SDL, ACFSMs, Kahn Process Networks, Petri Nets)
29
Communication Models
writer is blocked (e.g.
if buffer is full)
reader is blocked data may be

(e.g. if buffer is empty) read once only
Buffer Blocking Blocking Single

Senders Receivers Size Reads Writes Reads
Unsynchronized many many one no no no
Read-Modify-write many many one yes yes no
Unbounded FIFO one/many one unbounded yes no yes
Bounded FIFO one/many one bounded yes may be yes
Rendezvous one one one yes yes yes
30
Petri Nets (PNs)
 Model introduced by C.A. Petri in 1962

 Ph.D. Thesis: “Communication with Automata”
 Applications: distributed computing, manufacturing, control, communication

networks, transportation, …
 PNs describe explicitly and graphically:
 sequencing/causality
 conflict/non-deterministic choice
 concurrency
 Asynchronous model (partial ordering)

 Main drawback: no hierarchy
31
Petri Net
 A PN (N,M0) is a Petri Net Graph N

 places: represent distributed state by holding tokens
 marking (state) M is an n-vector (m1,m2,m3…), where mi is the non-negative
number of tokens in place pi.
 initial marking (M0) is initial state
 transitions: represent actions/events
 enabled transition: enough tokens in predecessors
 firing transition: modifies marking
 … and an initial marking M0 p2
t2
p1 t1 p4
t3
p3
32
Concurrency, causality, choice
t1
Concurrency
t2
t5
Causality, sequencing
Choice,
conflict
t3 t4
t6
33
Communication Protocol
Send msg
Process 1 Process 2
Send Ack
Receive Ack
34
Producer-Consumer Problem
Produce
Buffer
Consume
35
Summary: Control Flow Description
Properties Specification Language
⇒ Nondeterminism ⇒ NDFSM
⇒ Parallel automata ⇒ State Charts, Petri Nets
⇒ Processes ⇒ SDL
⇒ Communication ⇒ MSC
⇒ Hierarchy ⇒ State Charts
⇒ Graphical support ⇒ All
⇒ Semantic ⇒ Different ;-(
37
Control vs. Data Flow Applications
Rough classification: Specification, synthesis and validation
 control: methods emphasize:
 don’t know when data arrive  for control:
(quick reaction)  event/reaction relation
 time of arrival often matters  response time

more than value (real-time scheduling for
 data: deadline satisfaction)
 data arrive in regular streams  priority among events and
(samples) processes
 values matter most  for data:
 functional dependency between
Distinction is important for: input and output

 specification (language, model, ...)  memory/time efficiency
 synthesis (scheduling, (data-flow scheduling for

optimization, ...) efficient pipelining)
 validation (simulation, formal  all events and processes are
verification, ...) equal
38
Data Flow Graph (DFG)
Powerful formalism for data-dominated applications
DFG support the specification of transformational systems:

 output is a function of the input
 set of actors (nodes) connected by a set of arcs representing the data flow
 no states, no external events to trigger state changes
 unbounded FIFO queues (main data store)
 no control nodes, e.g. branch, loop
DFG represent a partial ordered model of the computation

=> specification of problem-inherent dependencies only
=> suitable for scheduling and code generation
=> there is a relation between buffer dimensioning and scheduling
(static scheduling minimizes the number of buffers required)
Languages:
 graphical: Ptolemy (UCB), GRAPE (U. Leuven), SPW (Cadence), COSSAP
(Synopsys)
 textual: Silage (UCB, Mentor), Haskell, Lucid
39
DFG
Semantics (informal)
 actors perform computation (often stateless)
 firing of actors when all needed inputs are available
 unbounded FIFOs for unidirectional exchange of data between actors
(integer, floats, arrays, etc.)
 extensions to model decisions
Example: FIR (finite impuls response) filter

 single input sequence i(n)
 single output sequence o(n)
 o(n) = c1 * i(n) + c2 * i(n-1)
i * c2
* c1 i(-1)
+ o
40
DFG – Example
41
Control Flow Graph (CFG)
 also called flow chart (abstract description of program designs)
 focus on control aspect of a system
 set of nodes and arcs
 trigger of an activity (node) when a particular preceding activity is completed
 different triggers for transitions
 suitable for well defined tasks that do not depend on external events
 imposes a complete order on the execution of activities
=> close to implementation (on conventional computer architecture)
 various variants with various levels of details
 simple operator level (addition, multiplication, etc)
 abstract function/procedure level
42
CFG – Example (detailed level)
43
Control/Data Flow Graph (CDFG)
 also called sequence graph
 mixture of control and data flow graph
 hierarchy of sequential elements
 units model data flow
 hierarchy models control flow
 special nodes (for control operations)

 start/end node: NOP (no operation) – all inputs needed (AND), all outputs
needed (AND)
 branch node (BR) – one out of many outputs selected (OR)
 iteration (LOOP) – one out of two outputs selected (OR)
 procedure call (CALL) – lower hierarchy is executed exactly once
 attributes
 nodes: execution time, cost, ...
 arcs: conditions for branches and loops
44
CDFG – Entity
Legend:
data dependencies
control dependencies
Notes: AND dependencies at NOPs (NO Operation), OR dependencies at

BRanches and LOOPs
45
CDFG – Branch
Notes:
• data dependencies are not fully specified
• x = a – b may execute in parallel to IF statement
• computation of p and q within IF statement may execute in parallel
46
CDFG – Loop
47
CDFG – Call
48
Review of Models, Concepts and Languages
Basic Concepts
 concurrency
 hierarchy
 communication
 synchronisation
Behavioral Models
 non-determinism
 NDFSM
 timing
 composed FSM
 Petri Net (PN)

 SDL
 VHDL
 SystemC
 ...
49
transition
 message passing
Concurrency
 reduction of states behaviror
 timeouts
References
Embedded Systems. Prentice Hall, 1994. (chapters 2 and 3)
 http://www.sei.cmu.edu/publications/documents/02.reports/02tn001.html
51
Models, Concepts and Languages
Basic Concepts
 concurrency
 hierarchy
 communication
 synchronisation
Behavioral Models
 non-determinism
 NDFSM
 timing
 composed FSM
 Petri Net (PN)

 SDL
 VHDL
 SystemC
 ...
1
Parallel Finite State Machines - Result of Decomposition
2
Parallel Finite State Machines Example
3
Single FSM
4
FSM- Decomposition / Composition
5
Parallel Finite State Machines - Properties
 Concurrency
 Delay
 Synchronization
 Rendezvous
 Mutual exclusion
 Blocking
 Priorization
6
Finite State Machines - Stability
 Stable {X2,X1,X0}
 {X0}
{X3}
 {X1}
 In = X1= Out
7
 Instable {X2}
 {X0} {X1,X0}
 {X1} {X3}
 In = X1= Out
8
 Conditionally stable
stable for X0
 In = X0 Out ={X0,X2,X3}
 In = X1 Out = X1
(instable for X1 )
9
 Example
10
 Example
11
 Example
12
 Example
13
 Instable States
14
 Stable States (abstraction)
15
Petri Nets (PNs)
 Model introduced by C.A. Petri in 1962

 Ph.D. Thesis: “Communication with Automata”
 Applications: distributed computing, manufacturing, control, communication

networks, transportation, …
 PNs describe explicitly and graphically:
 sequencing/causality
 conflict/non-deterministic choice
 concurrency
 Asynchronous model (partial ordering)

 Main drawback: no hierarchy
22
transition
 message passing
Concurrency
 reduction of states behavior
 timeouts
References
Embedded Systems. Prentice Hall, 1994. (chapters 2 and 3)
 http://www.sei.cmu.edu/publications/documents/02.reports/02tn001.html
44
TECHNISCHE
UNIVERSITÄT
ILMENAU
Systems Design
Part 9,
Time and Performance Evaluation
1
Evaluation of Temporal and Performance Aspects
 Problem Statement  Performance Evaluation

 Performance Modeling
Integrated Hard- and Software Systems
http://www.tu-ilmenau.de/ihs
3
Example: IP Office Firewall
Analysis
Typical performance-related
Design questions in design phase:
 identify
performance  System architecture?
requirements Implementation HW architecture, need for
 identify traffic evaluate design special HW?
Integration

model alternatives  Which chip sets/processor?
 identify costly or  identify performance  Which peripherals?
contradicting critical components  Programming approach,
requirements  measurement-based
 adapt design to meet language?
replace costly evaluation
 performance  Which operating system?
4
functions by requirements
cheaper functions
Digital Systems Design  …?
Accuracy and Effort
 look at worst case (maximum load) or average (be aware of nonlinear
behavior)
 watch level of detail!
 different kinds of performance requirements
 throughput/utilization of resources -> cheap and accurate performance
evaluation
 response time -> less accurate and highly expensive evaluation
 optimistic/pessimistic evaluation (use of bounds)

note: estimation of bounds is much easier than exact values
3 cases: perf. req. response time
 right on track optimistic pessimistic

estimate estimate
 details/special optimistic pessimistic

care needed estimate estimate
 there is a
optimistic pessimistic
problem! estimate estimate
5
Tasks of Performance Evaluation - Summary
(1) Identify the goals of the performance evaluation
(2) Study the details of the object under investigation
(3) Decide on the modeling approach
(4) Build the performance model
(5) Derive quantitative data (as input) for the performance model
(6) Transform the performance model to an executable or assessable model
(7) Evaluate the performance model
(8) Verify the performance results against the performance requirements
Some advice:
 do simple things first!
 abstract, abstract, abstract!
(back-of-the-envelope analysis is preferable over complex behavioral model)
 don´t skip or defer performance evaluation!
6
Tasks (1): Identify the Goals of the Performance Evaluation
 What is the purpose of the performance evaluation?
 evaluate possible solutions to a decision problem
 identify the parts of the system critical to performance
=> avoid spending time on evaluating things you already know
 What are the performance metrics to be estimated (response time or system

capacity)?
=> impact on modeling and evaluation methods
 What is the required accuracy of the evaluation?
=> impact on modeling and evaluation methods
 What kind of performance evaluation is performed?
=> best/worst case evaluation, average case evaluation
7
Tasks (2-5): Performance Modelling
(2) Study the details of the object under investigation
Workload:
 identification of the service requests issued to the system
Available resources:
 analysis of the execution environment
System:
 analysis of the static structure as well as dynamic aspects of the system
Mapping:
 identification of the resources used by specific service requests
(3) Decide on the modeling approach
 select appropriate performance evaluation technique (CFG, DFG, FSM,
sequence diagrams, queuing model, ...)
(4) Build the performance model
 carefully select the level of abstraction
(5) Derive quantitative data for the performance model
 derive execution times, available resources, traffic model, ...
8  measurement, emulation, code analysis, empirical estimation
Tasks (6-8): Performance Evaluation
(6) Transform the performance model to an executable or assessable model
 take into account the limits of the selected performance evaluation
technique
(7) Evaluate the performance model
 tool support for simulation, queuing analysis, graph analysis, ...
 ensure the model is a valid model of the system
validation of results (confidence intervals, seeds for simulation, rare

event problems)
(8) Verify the performance results against the performance requirements
 check if real-time, response time, capacity requirements are met
9
Performance Model – The Incredients
Application
 information about the application
 typically some behavioral model attributed with temporal information on

execution times
 e.g. PN, DFG, CFG, FSM
Resources
 typically some structural model attributed with capacity information of
resources (MIPS, FLOPS, ...)
Mapping (spatial assignment)
 information describing how the entities of the application are assigned to the
resources (which function is assigned to which processor or other HW entity)
Runtime system (temporal assignment)
 information on dynamic aspects, e.g. scheduling algorithms
System stimuli (traffic model)
 the characteristics of the input to the system that triggers an execution
 types and temporal characteristics of the input events
10
Example
Application (DFG or CFG) Resources
2 P1
Mapping
4 5 (spatial assignment)
3
P2
6
Schedule for processor P1:

 1, 2, 3, 4 (no impact with given mapping)
 schedule may be static or dynamic (priorities)
Stimuli:
number of arrivals (stimuli) for task 1 (source node) per second
(deterministic or probabilistic)
11
Performance Evaluation – Summary of Methods
Methods
 process graph analysis (structural model)
 task graph analysis (behavioral model)
 schedulability analysis (real-time analysis)
 Markov chain analysis
 queuing network analysis
 operational analysis
 discrete-event simulation
In order to select the right method it is important to understand

the strengths and limits of each method!
12
Process Graph Analysis
Process graph
 structural model of the application
 nodes represent functional entities (module, function, procedure, operation, etc)
 edges represent communication relations
 precedence relations are neglected
Process graph analysis
 limited to the analysis of the load imposed on the resources of the system
 assumption that contention on resources does not have a negative impact on the
load of the system
 resources may be physical (e.g. processor, HW entity, communication link) or
logical (e.g. critical sections)
Example of simple analysis:
load(r) = ∑ p∈Ar load(p,r)
where
 p denotes some process
 Ar specifies the set of processes assigned to resource r and
 load(p,r) denotes the exact resource demand resulting from the assignment of process
p on resource r
Note: the formula may be equally applied to compute the load of a communication link
13
Example: HW/SW partitioning
SW HW
 assign the tasks to the SW and the HW entity
such that 1
1 4
 the maximum of the processing time of SW 5/3 10/1
and HW is a minimum and 10 8
 the communication cost are minimal
 20/2 denote the cost (load) of processing the 2 5

15/9 8/2
process in SW or HW, respectively 3 6
 9 denote the communication cost (load) if 9
communicating partners are assigned to different 3 6
20/2 20/3
entities, otherwise the cost are zero
Cost function (example):

cost (partitioning) = wp max∀ r ∈ R {∑p ∈ Ar load(p,r)} + wc ∑c ∈ Ac load(c)
where
 wp and wc denote the weight (importance) of the processing cost and the
communication cost, respectively
 R denotes the set of processing resources
 Ar specifies the set of processes p assigned to processing resource r
14  Ac specifies the set of non-internal communications between two entities
Typical questions to be answered:
 can the load be handled by the available resources (processors, links)?
 is the load balanced?
Method is often used in industry to estimate the load imposed on a system and
to estimate the system capacity
Application to communication systems design: estimate the communication
bandwidth of the system (e.g. of internal memory bus or system bus)
Tooling: excel sheet is sufficient
Discussion:
 simple, fast and efficient
 application to best-case analysis
=> load/capacity is a central constraint that has to be met by the system,
otherwise detailed studies are useless!
15
Task Graph Analysis
Task graph
 simple behavior model of the application
 nodes represent functional entities (module, function, procedure, operation, etc)
 arcs represent precedence constraints
Task graph analysis

 analysis of the critical path from source to sink (graph theory)
 focus on response time of the system
 assumption that contention on resources does not have a negative impact on the
load of the system (e.g. no context-switch times - similar to process analysis)
 resources may be physical (e.g. processor, HW entity, communication link) or
logical (e.g. critical sections)
Discussion:
 simple and efficient for deterministic (constant) execution times
(complex for other distributions)
 application to best-case analysis
(neglect contention on resources – scheduling)
 wide application to optimization techniques
16
Task Graph Analysis – Examples
Analysis:
 find the longest (critical) path and compute its length
(apply recursive scheme to compute subpaths)

Example 1: DFG (or CDF with Example 2: communication system
parallel entities)
prot. stack
prozessor
1 2 MI 20 ms
2 100 MIps
2
1
4 5 medium phy network
33 ms
3 4 1 Mb 30 Mbps
3 4
prot. stack
6 prozessor
1 2,8 MI 23 ms
120 MIps
Result: critical path T = 8 ms

(best case, i.e. no contention)
Result: critical path T = 76 ms (best-case, i.e.
17 determ. times, no contention, no queuing)
Schedulability Analysis
Analysis techniques to check whether a system can meet its deadlines
Model:
 fixed set of processes
 single processor/resource
 all processes are periodic, with known periods
 processes are completely independent of each other
 process deadlines are equal to the process periods
 all system overheads are ignored
 all processes have a fixed worst-case execution time
 priority-based preemptive scheduling of processes (runable higher-priority

process immediately interrupts a low-priority process)
Schedulability analysis:
 check if the deadlines can be met under all circumstances
 different schemes available depending on the specific model
18
Rate Monotonic Priority Assignment
Idea: assign priorities to processes according to their period T (and deadline D)
(process with shortest period is assigned the highest priority (5))
Rate monotonic (RM) scheduling is optimal in the sense that

 if a process set can be scheduled (using preemptive priority-based
scheduling) with a fixed priority assignment scheme,
 then the same process set can also be scheduled with an RM assignment
scheme
Example for RM scheduling:
process period T priority P

A 25 5
B 60 3
C 42 4
D 105 1
E 75 2
19
Schedulability Analysis – Utilization-based
Idea: derive sufficient condition for schedulability based on the analysis of the
resource utilization
Assumption: RM scheduling
Sufficient condition for schedulability (though not a necessary condition):
Utilization U = ∑ (Ui) = ∑ (Ci/Ti) < N(21/N – 1)

i=1...N i=1...N
where
 i identifies the process,
 Ui specifies the resource utilization due to process i
 Ci specifies the computation time of process i
 Ti specifies its period
 N defines the number of processes
Utilization bounds (U): N=1 => U=1; N=2 => U=0.828; N=10 => U=0.718;
for infinite number of N: U->0.69
Discussion:
20  simple test for simple models (deadline Di = Ti, etc.)
Schedulability Analysis – Example
process period T comp. time C priority P

0 3 1 3
1 4 1 2
all times in ms
2 6 2 1
1/N
U = ∑i=1...N (Ui) = ∑i=1...N (Ci/Ti) < N(2 – 1)
RM scheduling => Utilization-based analysis:

1/3 + 1/4 + 2/6 = 11 /12
0.33 + 0.25 + 0.33 = 0.91 > 0.78
=> sufficient condition is not given
21 
Schedulability Analysis – Response-time Analysis
Idea:
 predict the worst-case response time of each process and compare with the
deadline to determine the feasibility of the schedule
Assumption: any priority assignment (not only RM)
Outline of approach:
 response time Ri of process i is Ri = Ci + Ii where Ii is the maximum
interference of process i from higher-priority processes
 the interference depends on the number of releases of the interfering processes
and their computation time, i.e. the interference Ii,j of the higher priority
process j on process i is
Ii,j = Ri/Tj * Cj
 application of fixed-point iteration method to solve the equations
(start with Ri,0 = Ci; terminate when Ri,n+1 = Ri,n)
Ri,n+1 = Ci + ∑j<i Ri,n/Tj * Cj
For details and variants see Burns&Wellings or Krishna&Shin

22
Schedulability Analysis – Example
process period T comp. time C priority P
0 3 1 3
1 4 1 2
2 6 2 1 all times in ms
Response-time analysis:
Response time R0 of Process P0:
R0 = C0 + I0 = C0 + 0 = 1 ms 
Response time R1 of process P1 (recursive):
R1 = C1 = 1 ms (without interrupt)
R1 = C1 + I1 = C1 + I1,0 = C1 + R‘1/T0 * C0 = 1 + 1/3 * 1 = 2 ms
R1 = C1 + I1 = C1 + I1,0 = C1 + R‘1/T0 * C0 = 1 + 2/3 * 1 = 2 ms 
Response time R2 of process P2 (recursive):
R2 = C2 = 2 ms
R2 = C2 + I2 = C2 + I2,0 + I2,1 = C2 + R‘2/T0 * C0 + R‘2/T1 * C1 = 2 + 2/3 * 1 + 2/4 * 1 = 4 ms
23 R2 = C2 + I2 = C2 + I2,0 + I2,1 = C2 + R‘2/T0 * C0 + R‘2/T1 * C1 = 2 + 6/3 * 1 + 6/4 * 1 = 6 ms 

Markov Chain Analysis
Idea: model the states and the transitions of the system and assign rates to the
transitions (comparable to a FSM with timed transitions)
Example: single server with a queue holding up to 2 requests
µ µ µ
λ denotes the arrival rate
λ 3 2 1 0 µ denotes the service rate
λ λ λ
Sketch of solution technique for steady-state analysis:
 mapping of Markov chain on a set of linear equations defining the state
probabilities
 normalization equation ∑i=0...n pi = 1
 derivation of mean values and distribution functions from state probabilities
Transient analysis is based on set of differential equations
Discussion:
 rather low-level description of the states of the system
 restricted to exponentially distributed transition rates and independence of events
24  state explosion problem for realistic systems (beyond millions of states)
Markov Chain Analysis – Example
Example: single server with a queue holding up to 2 requests
µ µ µ
λ denotes the arrival rate
λ 3 2 1 0 µ denotes the service rate
λ λ λ
Steady-state analysis:
 mapping of Markov chain on a set of linear equations
state 3: λp2 = µp3
state 2: λp1 + µp3 = λp2 + µp2 steady state implies that
state 1: λp0 + µp2 = λp1 + µp1 arrivals = completions
state 0: µp1 = λp0
normalization equation: p0 + p1 + p2 + p3 = 1
 resolution of system of equations to derive state probabilities
p0 = 1 / (1 + λ/µ + (λ/µ)2 + (λ/µ)3 )
p1 = (λ/µ) / (1 + λ/µ + (λ/µ)2 + (λ/µ)3 ); p2 = ...
 derivation of mean values and distribution functions from state probabilities
utilization: U = 1 - p0; mean number of jobs in system: N = p1 + 2p2 + 3p3 ;
25 blocking probability B; distribution functions for waiting time, response time, etc.
Queuing Network Analysis
Idea: solve the system at the level of queuing stations directly as an alternative
to a mapping and solution of the Markov chains
Assumption:
 stations are separable (product-form queuing networks)
 each station can be analysed in separation (exponential input results in
exponential output)
Restrictions:
 limited distributions (exponential and derivatives)
 no synchronizations
 no blocking (infinite queues)
Results:
 mean values for delays, utilization, queue length and population
Discussion:
 efficient solution techniques available for a considerable set of queuing
networks
26
See R. Jain for details
Queuing Network Analysis - Example
Example: communication system (unbounded queues)
arrival rate: 25 packets/s

prot. stack λ = 25 1/s
µ = 100 MIps / 2 MI = 50 1/s
prozessor
2 MI 100 MIps
µ = 30 1/s
medium phy network
1 Mb 30 Mbps
prot. stack
µ = 43 1/s
prozessor
2,8 MI 120 MIps
Results (assuming exponential service times and arrivals):

 utilization = λ/µ (e.g. physical network util. = 83 %)
 population per station ni = (λ/µ) / (1− λ/µ)
 mean total population N = ∑ ni =7,39
i
27  mean response time T = N/λ = 296 msec (Little’s law)
Operational Analysis
Idea:
 model the system as a set of stations with queues
 use a small set of simple laws (job flow balance etc.)
 base analysis on operational data (i.e. measurable and testable)
Assumptions:
 job flow balance
 no assumptions on service and arrival time distributions
Analysis of arrival rates, throughput, utilization and mean service times of the
different stations in the system
Discussion:
 simple (unsuitable to parallel execution)
 fast
 answers „what if“ questions
 derivation of response time figures only if population is given (i.e. application of
Little´s law (answer response time questions only if the population of jobs in the
system is known ) – no assumptions about distributions)
28 See Lazowska et.al. or Denning & Buzen for details

Discrete-event Simulation
Idea:
 model the relevant events of the system
 process the events according to their temporal order (similar to the real
execution with the exception that simple processing blocks are modeled only)
Example: Execution on a 2-processor system (non-preemptive)
1
2/1 P1 1 5 3 6
P2 4 2
2
1/2 0 2 4 6 8 10
4 5
3/3 4/4
3 4/5
Discussion
6 no assumptions
1/6 
Legend:  danger of including too many details

green: execution time  evaluation is time consuming
blue: process priority (1=low)  problems with rare events
29
 large set of tools and models available
Measurement-based Evaluation
Steps of measurement-based evaluation
 derive (behavioral) model of the system
 decide on instrumentation points
 instrumentation of the executables to generate traces (add time stamp)
 interfacing to track data (SW or HW monitoring) – minimize the intrusion to
system execution (and thus falsification of results)
 post-execution analysis of the traces
 special care needed in distributed systems -> common notion of time needed
Various measurement tools are available
Gain important insight in the system execution for performance debugging and
development of future systems
30
Comparision of Methods
Analysis Analysis of Verification Modelling of
multiprocessor of Real parallel
best worst average systems Time processing (prec.
case case requests constraints)
Process graph   no 
Task graph  not really ? 
Schedulability
Utiliz.-based  no  no
Resp.-based  no  no
Markov chains   no 
Queuing   no no
networks
Operational   no no
analysis
Simulation   no 
Measurements  no 
31
Problems and Limits of Performance Evaluations
 missing data
 uncertainty of available execution data
 data dependencies (if, case, while, ...)
 context dependencies: caching, scheduling, synchronization, blocking
=> worst case execution time (based on code rather than measurements)
 uncertainty of traffic model, i.e. the distributions of the stimuli of the system
32
References
Overview and simple techniques:
 A. Mitschele-Thiel: Systems Engineering with SDL – Developing Performance-Critical
Communication Systems. Wiley, 2001. (section 2.3 & 2.4)
 H.U. Heiss: Prozessorzuteilung in Parallelrechnern. BI-Wissenschaftsverlag, Reihe
Informatik, Band 98, 1994.
 R. Jain: The Art of Computer Systems Performance Analysis – Techniques for
Experimental Design, Measurements, Simulation, and Modeling. Wiley, 1991.
Evaluation of real-time systems (deterministic assumptions):

 A. Burns, A. Wellings: Real-Time Systems and Programming Languages, 2nd edition,
Addison Wesley, 1996.
 G. Buttazzo: Hard Real-Time Computing Systems. Kluwer Academic Publishers. 1997.
 C.M. Krishna, K.G. Shin: Real-time Systems. McGraw-Hill, 1997.
 H. Kopetz: Real-time Systems. Kluwer Academic Publishers, 1997.
Evaluation of queuing systems (exponential and other distributions):

 J. Dennig, J. Buzen: The Operational Analysis of Queueing Network Models. Computing
Surveys, 10(3), Sept. 1978.
 E.D. Lazowska, J. Zahorjan, G.S. Graham, K. Sevcik: Quantitative System Performance:
Computer System Analysis Using Queueing Network Models. Prentice-Hall, 1984.
33
TECHNISCHE
UNIVERSITÄT
ILMENAU

Part 9,,
Optimization
1
Heuristic Search
Most heuristics are based on an iterative search comprising the following
elements:
 selection of an initial (intermediate) solution (e.g. a sequence)
 evaluation of the quality of the intermediate solution
 check of termination criteria
select initial solution
select next solution

(based on previous solution) search strategy
evaluate quality
y accept solution as
acceptance criteria satisfied
„best solution so far“
n
termination criteria satisfied
10 y
Hill-Climbing – Discussion
 simple
 local optimizations only: algorithm is not able to pass a valley to finally reach
a higher peak
 idea is only applicable to small parts of optimization algorithms but needs to
be complemented with other strategies to overcome local optimas
11
Random Search
also called Monte Carlo algorithm
Idea:
 random selection of the candidates for a change of intermediate solutions or
 random selection of the solutions (no use of neighborhood)
Discussion:
 simple (no neighborhood relation is needed)
 not time efficient, especially where the time to evaluate solutions is high
 sometimes used as a reference algorithm to evaluate and compare the
quality of heuristic optimization algorithms
 idea of randomization is applied to other techniques, e.g. genetic algorithms
and simulated annealing
12
Simulated Annealing
Idea:
 simulate the annealing process of material: the slow cooling of material leads to
a state with minimal energy, i.e. the global optimum
Classification:
 Search strategy
 random local search
 Acceptance criteria
 unconditional acceptance of the selected solution if it represents an
improvement over previous solutions
 otherwise probabilistic acceptance
 Termination criteria
 static bound on the number of iterations (cooling process)
13
Simulated Annealing – Discussion and Variants
Discussion:
 parameter settings for cooling process is essential (but complicated)
 slow decrease results in long run times
 fast decrease results in poor solutions
 discussion whether temperature decrease should be linear or logarithmic
 straightforward to implement
Variants:
 deterministic acceptance
 nonlinear cooling (slow cooling in the middle of the process)
 adaptive cooling based on accepted solutions at a temperature
 reheating
14
Genetic Algorithms – Basic Operations
1 1 0 0 1 0 1 0 1 1 0 1 0 1 0 0 1 0 0 1
crossover
1 1 0 0 0 0 1 0 0 1
mutation
1 1 0 0 0 1 1 0 0 1
15
Genetic Algorithms – Basic Algorithm
crossover Replacement and selection rely

on some cost function defining
the quality of each solution
selection mutation
Different replacement
strategies, e.g. “survival of the
population replacement fittest”
Crossover selection is typically

random
General parameters:
 size of population
 mutation probability
 candidate selection strategy (mapping quality on probability)
 replacement strategy (replace own parents, replace weakest, influence of
probability)
Application-specific parameters:
 mapping of problem on appropriate coding
16 handling of invalid solutions in codings
Genetische Algorithmen – Minimum Spanning Tree
17small


population results in inbreeding
larger population works well with small mutation rate  tradeoff between size of population and number of iterations
Genetic Algorithms –Basic Operations
 Mutation
 => crating a new member of the population by changing one member
18
Genetic Algorithms –Basic Operations
 Crossover
 => crating a new member of the population from two members
19
Genetische Algorithmen – Traveling Salesman Problem
20minimal


impact of mutation rate with small population
negativ impact of high mutation rate with larger population (increased randomness) – impact not quite clear
Genetic Algorithms – Discussion
 finding an appropriate coding for the binary vectors for the specific
application at hand is not intuitive
problems are
 redundant codings,
 codings that do not represent a valid solution, e.g. coding for a

sequencing problem
 tuning of genetic algorithms may be time consuming
 parameter settings highly depend on problem specifics
 suited for parallelization of optimization
21
Tabu Search
Idea:
 extension of hill-climbing to avoid being trapped in local optima
 allow intermediate solutions with lower quality
 maintain history to avoid running in cycles
Classification:
 Search strategy
 deterministic local search
 Acceptance criteria
 acceptance of best solution in neighborhood which is not tabu
 Termination criteria
 static bound on number of iterations or
 dynamic, e.g. based on quality improvements of solutions
22
Tabu Search – Algorithm
select initial solution
select neighborhood set

(based on current solution)
remove tabu solutions

from set increase neigborhood
y
set is empty
n
The brain of the algorithm is the
evaluate quality and tabu list that stores and maintains
select best solution from set information about the history of the
search.
update tabu list In the most simple case a number of
previous solutions are stored in the
tabu list.
n More advanced techniques maintain
termination criteria satisfied
attributes of the solutions rather than
y the solutions itself
23
Tabu Search – Organisation of the History
The history is maintained by the tabu list
Attributes of solutions are a very flexible mean to control the search
Example of attributes of a HW/SW partitioning problem with 8 tasks assigned to 1 of 4

different HW entities:
(A1) change of the value of a task assignment variable 1
2/1
(A2) move to HW 2
1/2 4 5
(A3) move to SW 3 3/3 4/4
(A4) combined change of some attributes
4/5
6
(A5) improvement of the quality of two subsequent solutions over or below 1/6
a threshold value
Aspiration criteria: Under certain conditions tabus may be ignored, e.g. if

 a tabu solution is the best solution found so far
 all solutions in a neighborhood are tabu
 a tabu solution is better than the solution that triggered the respective tabu conditions
Intensification checks whether good solutions share some common properties
Diversification searches for solution that do not share common properties
Update of history information may be recency-based or frequency-based (i.e. depending on
the frequency that the attribute has been activated)
24
Tabu Search – Discussion
 easy to implement (at least the neighborhood search as such)
 non-trival tuning of parameters
 tuning is crucial to avoid cyclic search
 advantage of use of knowledge, i.e. feedback from the search (evaluation of
solutions) to control the search (e.g. for the controlled removal of
bottlenecks)
25
Heuristic Search Methods – Classification
Search strategy
 search area
 global search (potentially all solutions considered)
 local search (direct neighbors only – stepwise optimization)
 selection strategy
 deterministic selection, i.e. according to some deterministic rules
 random selection from the set of possible solutions
 probabilistic selection, i.e. based on some probabilistic function
 history dependence, i.e. the degree to which the selection of the new
candidate solution depends on the history of the search
 no dependence
 one-step dependence
 multi-step dependence
Acceptance criteria
 deterministic acceptance, i.e. based on some deterministic function
 probabilistic acceptance, i.e. influenced by some random factor
Termination criteria
 static, i.e. independent of the actual solutions visited during the search
 dynamic, i.e. dependent on the search history
26
Heuristic Search Methods – Classification
Heuristic Search strategy Acceptance Termination

criterion criterion
Search area Selection strategy History dependence
local global det. prob. random none one- multi- det. prob. stat. dyn.
step step
hill- x x x x x
climbing
tabu x x x x x x
search
simulated x x x x x
annealing
genetic x x x x x x x
algorithms
random x x x x x
search
27
Single Pass Approaches
The techniques covered so far search through a high number of solutions.
Idea underlying single pass approaches:

 intelligent construction of a single solution (instead of updating and
modification of a number of solutions)
 the solution is constructed by subsequently solving a number of subproblems
Discussion:
 single-pass algorithms are very quick
 quality of solutions is often small
 not applicable where lots of constraints are present (which require some kind
of backtracking)
Important applications of the idea:

 list scheduling: subsequent selection of a task to be scheduled until the
complete schedule has been computed
 clustering: subsequent merger of nodes/modules until a small number of
cluster remains such that each cluster can be assigned a single HW unit
28
Single Pass Approaches – Framework
derive guidelines for The guidelines are crucial

solution construction and represent the
intelligence of the algorithm
select subproblem
decide subproblem
based on guidelines
possibly recompute or
adapt guidelines
n
final solution constructed
y
29
List Scheduling – Example (1)
Problem:
 2 processors
 6 tasks with precedence constraints 1 2 /8
 find schedule with minimal execution time
2 1 /6
HLFET (highest level first with estimated times)
4 3 /4 5 4 /5
 length of the longest (critical) path to the sink
node (node 6) 3 4 /5
Assignment strategy
 first fit 6 1 /1
Resulting schedule:
Legend:
P1 1 2 3 6 green: estimated times
P2 5 4 red: levels (priorities)
0 2 4 6 8 10
31
List Scheduling – Example (2)
Problem (unchanged):
 2 processors
 6 tasks with precedence constraints 1 2 /2
 find schedule with minimal execution time
SCFET (smallest co-level first with estimated 2 1 /3

times) 4 3 /5 5 4 /6
 length of the longest (critical) path to the
3 4 /7
source node (node 1)
Assignment strategy
 first fit 6 1 /8
Resulting schedule:
Legend:
P1 1 2 5 6 green: estimated times
P2 4 3 blue: co-levels (priorities)
0 2 4 6 8 10
32
Clustering - Basics
Partitioning of a set of nodes in a given number of subsets
assign each node to a Application:

different cluster
 processor assignment (load
balancing – minimize interprocess
compute the „distance“ communication)
between any pair of clusters
 scheduling (minimize critical
path)
select the pair of clusters
with the highest affinity  HW/SW partitioning
Clustering may be employed as part

merge the clusters
of the optimization process, i.e.
combined with other techniques
n
termination criteria holds
y
34
Clustering
probabilistic deterministic
Each node belongs with certain A node belongs to exactly one

probabilities to different clusters cluster or not
hierarchical partitioning
Starts with a distance matrix of Starts with given number of K

each pair of nodes clusters (independent from nodes)
Exact method: always the Results depend on the chosen

same result initial set of clusters
Termination after all nodes Termination after a given

belong to one cluster number of iterations
35
Hierarchical Clustering
Stepwise reduction of the number of clusters
Determine the distance

between each pair of
nodes
Select the smallest distance
Replace the selected pair

in distance matrix by a
cluster representative
Recompute distance matrix

Example data in a matrix
n
All nodes in one cluster
Algorithm is kind of subsequent merger of
y nearest neighbors (nodes/clusters)
12
Hierarchical Clustering
Dendrogram
Algorithm is kind of subsequent merger of

nearest neighbors (nodes/clusters)
13
Partitioning Clustering (k-means)
Choose positions of k initial

assign each node to the

nearest cluster
representative
Recompute positions of the

Based on the positions of
the nodes in each cluster
n
Number of iterations reached
y
14
Clustering – Application to Load Balancing
assign each node to a Optimization goal:

different cluster  minimize inter-process (inter-
cluster) communication
compute the sum of the  limit maximum load per processor
communication cost (cluster) to 20
between any pair of clusters
select the pair of clusters

with the highest comm.
cost that does not violate
the capacity constraints
merge the clusters
y reduction of comm. cost

without violation of constraints
possible
n
15
Clustering – Application to Load Balancing (2 processors)
10
7 5 12 12 12
5 4 5 4 5 4 5 4
4 4 4 4
6 7 6 7 6 7 6
3 8 3 8 3 8 3 16
1 1 1 1
2 9 2 9 2 9 2
12
18 18 20
5 4 8 8
4 9
6
3 16 3 16 3 16 16
1 1 1
2 2 2
16
Clustering – Hierarchical Algorithms
Single linkage Complete Linkage
Centroid-based
Algorithms implement
different methods to
compute the distance
between two clusters
17
Clustering – Single Linkage
10
9 P1 P7 Distance between groups is estimated as
8 the smallest distance between entities
P5
7
6 Example:
d ( 2, 4 )5 = min[d 25 , d 45 ] = d 45 = 4.1
5 P3
P4
4
3
P2 P6
2
1
0
0 2 4 6 8 10
Cluster # P1 P2 P3 P4 P5 P6 P7
P1 0 7.2 5 7.1 6.1 9.2 7
P2 - 0 3 1.4 5.4 3 6.7
P3 - - 0 2.2 2.8 4.3 4.3
P4 - - - 0 4.1 2.2 5.4
P5 - - - - 0 5.1 1.4
P6 - - - - - 0 6
P7 - - - - - - 0
18
Clustering – Single Linkage
10 Cluster # P1 C24 P3 C57 P6

9 P1 P7
P1 0 7.1 5 6.1 9.2
8
P5
7 C24 - 0 2.2 4.1 2.2
6
P3 - - 0 2.8 4.3
5 P3
P4 C57 - - - 0 5.1
4
3 P6 - - - - 0
P2 P6
2
1
0
Cluster # P1 C243 C57 P6
0 2 4 6 8 10
P1 0 5 6.1 9.2
Cluster # P1 P2 P3 P4 P5 P6
C243 P7 - 0 2.8 2.2
P1 0 7.2 5 7.1 6.1 C57

9.2 7 - - 0 5.1
P2 - 0 3 1.4 5.4 P6
3 6.7 - - - 0
P3 - - 0 2.2 2.8 4.3 4.3
P4 - - - 0 4.1 2.2 5.4
P5 - - - - 0 5.1 1.4
P6 - - - - - 0 6
P7 - - - - - - 0
19
Clustering – Group Average
10
9 P7
Distance between groups is defined
P1
8 as the average distance between
P5
7 all pairs of entities
6
5 P3 Example:
P4
4
3
2 P2 P6 d ( 2, 4 )5 =
1
(d 25 + d 45 ) = 4.8
1
2
0
0 2 4 6 8 10
P1 0 7.2 5 7.1 6.1 9.2 7
P2 - 0 3 1.4 5.4 3 6.7
P3 - - 0 2.2 2.8 4.3 4.3
P4 - - - 0 4.1 2.2 5.4
P5 - - - - 0 5.1 1.4
P6 - - - - - 0 6
P7 - - - - - - 0
20
Clustering – Group Average
10 Cluster # P1 C24 P3 C57 P6

9 P1 P7
P1 0 7.2 5 6.6 9.2
8
P5
7 C24 - 0 2.6 4.5 2.6
6
P3 - - 0 3.6 4.3
5 P3
P4 C57 - - - 0 5.6
4
3 P6 - - - - 0
P2 P6
2
1
0
0 2 4 6 8 10 Cluster # P1 C243 C57 P6
P1 0 6.4 6.1 9.2

C243 - 0 4.8 2.5
P1 0 7.2 5 7.1 6.1 9.2

C57 7 - - 0 5.1
P2 - 0 3 1.4 5.4 3
P6 6.7 - - - 0
P3 - - 0 2.2 2.8 4.3 4.3
P4 - - - 0 4.1 2.2 5.4
P5 - - - - 0 5.1 1.4
P6 - - - - - 0 6
P7 - - - - - - 0
21
Clustering – Centroid-based
10
9 xP1 P7
Determine distances between centroids (k,l)
x
8 Merge centroids with the least distance
P5
((C ))
7
6
5 P3
x
d (k , l ) = xk − C xl ) + (C
2
yk − C yl
2
P4
4
3 x
P6
2 P2
1
0
0 2 4 6 8 10
P1 0 7.2 5 7.1 6.1 9.2 7
P2 - 0 3 1.4 5.4 3 6.7
P3 - - 0 2.2 2.8 4.3 4.3
P4 - - - 0 4.1 2.2 5.4
P5 - - - - 0 5.1 1.4
P6 - - - - - 0 6
P7 - - - - - - 0
22
Clustering – Centroid-based
10
Cluster # C1 C24 C3 C57 C6
9 xP1 P7
x
8 C1 0 7.1 5 6.5 9.2
P5
7
C24 - 0 2.5 5.4 2.5
6
5 P3 C3 - - 0 3.5 4.3
x P4
4
C57 - - - 0 5.5
3 x
P2 P6
2 C6 - - - - 0
1
0
0 2 4 6 8 10
P1 0 7.2 5 7.1 6.1 9.2 7
P2 - 0 3 1.4 5.4 3 6.7
P3 - - 0 2.2 2.8 4.3 4.3
P4 - - - 0 4.1 2.2 5.4
P5 - - - - 0 5.1 1.4
P6 - - - - - 0 6
P7 - - - - - - 0
23
Differences between Clustering Algorithms
4 4
x 10 x 10
2.5 2.5
4
2
x 10 2
2.5
Single Linkage K-means
1.5 1.5
1
2
Single
WardLinkage
K-means
Centroid
CompleteLinkage
Linkage 1
0.5 0.5
Y (m)
Y (m)
0 0
1.5
4
-0.5 x 10 -0.5
2.5
-1
2 1 -1
-1.5 Complete Linkage -1.5

1.5
-2
1 0.5 -2
-2.5 -2.5
-3 -2 -1 0 1 2 3
YY (m)(m)
0.5 -3 -2 -1 0 1 2 3
X (m) 4 X (m) 4
0 0 x 10 x 10
4
x 10
-0.5 2.5
-0.5
-1 2
-1.5 x 10
4
1.5
Ward
2.5
-2
-1 1
2
-2.5 Centroid Linkage 0.5
-3 1.5 -2 -1 0 1 2 3
-1.5
Y (m)
X (m) 4
x 10 0
1
-0.5
0.5
-2
Y (m)
-1
0
-1.5
-0.5
-2.5 -2
-3-1 -2 -1 0 1 2 3
-2.5
-1.5 X (m) -3 -2 -1 0 4 1 2 3
X (m) x 10 4
x 10
-2
24
-2.5
-3 -2 -1 0 1 2 3
X (m) 4
x 10
Clustering – Variants
Clustering methods
Partitioning methods Hierarchical methods
k-means Agglomeration Division
Fuzzy-c-means (bottom up) (top down)
SOM Single linkage Wards
Clique Complete linkage Tree Structural Vector
One Pass Average group Quantification
Gustafson-Kessel algorithm Centroid Macnaughton-Smith
MST algorithm
ROCK
Distance Metrics  Camberra

 Euclidean  Chebychev
 Manhattan  Correlation
 Minkowsky  Chi-square
 Mahalanobis  Kendalls‘s Rank
25  Jaccard Correlation
Clustering – Discussion
 Results
 Exact results (single linkage)
 Not-exact results  often several iterations are necessary (K-means)
 Metrics
 Strong impact to clustering results
 Not each metric is suitable for each clustering algorithm
 Decision for one- or multi-criteria metrics (separated or joint clustering)
 Selection of Algorithm
 Depends strongly on the structure of the data set and the expected results
 Some algorithms tend to separate outlayers in own clusters  some large
clusters and a lot of very small clusters (complete linkage)
 Only few algorithms are able to detect also branched, curved or cyclic clusters
(single linkage)
 Some algorithms tend to return clusters with nearly equal size (K-means,
Ward)
 Quality of clustering results
 The mean variance of the elements in each cluster (affinity parameter) is often
used
 In general the homogeneity within clusters and the heterogeneity between clusters
can be measured
 However, the quality prediction can be only as good as the quality of the used
metric!
26
Branch and Bound with Underestimates
Application of the A* algorithm to the scheduling problem
Example: scheduling on a 2-processor system (processor A and B)

Process graph communication || processing (assumption)
f(x) = g(x) + h(x)

1 g(x) exact value of partial schedule
5
2 5 h(x) underestimate for remainder (rem)
2 8 3 9 =(min (altern.rem.proc, rem.comm. + rem.proc.)
x= start, than x=best of X, where X=growing set of
6 1 known solutions (min of comm+proc.)
4
3 f(1) = 5 + min((9 + 3), (2+8+3)) = 5+12 = 17
Legend:
green: processing times
blue : communication times Scheduled to: A B
Search is terminated when min {f(x)} is

a terminal node (in the search tree)
27
Example: computation of f(3)
1 1 1 -> A 2 1 -> B
5
2 5 f(1)=17 f(2)=17
2 8 3 9 f(x) = g(x) + h(x)

3 2 -> A
f(3)=22 g(x) exact value of partial
6 1
schedule
4
3 h(x) underestimate for
remainder
case 1: A= path 1-2-4
A 1 2 4
g(3) = 5 + 8 = 13
B 2->4 4
h(3) = min(3, (5+9+3))
0 4 8 12 16 20 24
f(3) = 16
case 2: A= path 1-3-4
A 1 2 3 4
g(3) = 5
B 1->3 3 4
h(3) = 5 + 9 + 3
0 4 8 12 16 20 24
28 f(3) = 22
Berechnung
 Annahme: Kommunikation auf gleichem Processor läuft parallel zur CPU
 f(1) = 5 + 9 + 3 = 17 f(2) Gleiches Ergebnis,
da egal, ob Prozess 1 auf A oder B läuft 1 5
2 5
 f(3) = 5+8 + min (5+9+3, 6+3) = 22
Schedule: Prozesse 1 und 2 auf Prozessor A
2 8 3 9
 f(4) = 5+2+8+ min (3; 9+1+3) = 18
6 1
Prozess 1 auf A, 2 auf B
(daher +2 Kommunikation und proc 8+5) 4 3
 f(5) = 5+9+ min (1+3; 2+8+3) = 18
Schedule: Prozesse 1 und 3 auf Prozessor A
 f(6) = f(3)
 f(7) = weitere Fallunterscheidungen mit Rest
29
Application of the A* algorithm to the scheduling problem
Example: scheduling on a 2-processor system (processor A and B)

Process graph Search Tree
Legend:
green: processing times
1
5 blue : comm. times 1 1 -> A 2 1 -> B
2 5 f(1)=17 f(2)=17
2 8 3 9
3 2 -> A 4 2 -> B 5 3 -> A 6 3 -> B
6 1 f(3)=22 f(4)=18 f(5)=18 f(6)=22
4 f(x) = g(x) + h(x)
3
g(x) exact 7 2 -> A 8 2 -> B
h(x) underestimate rest f(7)=25 f(8)=18
A 1 3
B 12 2 4 9 4 -> A 10 4 -> B
f(9)=24 f(10)=18
0 4 8 12 16 20 24
30Search is terminated when min {f(x)} is a terminal node (in the search tree)
References
Critical Communication Systems. Wiley, 2001. (section 2.5)
 C.R. Reeves (ed.): Modern Heuristic Techniques for Combinatorial Problems.
Blackwell Scientific Publications, 1993.
 H.U. Heiss: Prozessorzuteilung in Parallelrechnern. BI-Wissenschaftsverlag,
Reihe Informatik, Band 98, 1994.
 M. Garey, D. Johnson: Computer and Intractability. W.H. Freeman, New
York, 1979.
31

Digital Systems Design

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Digital Systems Design

Uploaded by

Copyright:

Available Formats

TECHNISCHE

Digital Systems Design

Indicators that HW is important:

 capacity Systems where HW/SW relation is obvious:

=> Knowledge of HW/SW interaction is required!

Embedded programming without knowledge of HW/SW integration

According to the International Data Corporation

 1997: 96% of all Internet-access devices shipped in the United

 End of 2002: less than 50% of them were PCs

 Today: the most selling Internet-access devices are mobile phones

Given is some problem to be solved by some kind of computer system, e.g. an

Your task is to select the most appropriate system design including HW

Slides and additional information will be provided at

Dr. Karsten Henke

 Integrated HW/SW systems by example

Embedded systems (not user-programable)

Node B Iub Registers

Dedicated Logic uC core

Logic Accelerators book

14Source: Berkeley Wireless Research Center

IVHS Infrastructure Safety-critical System

Navigation Info/Comms/ Stereo/CD Suspension Vehicle Transmission

Electronic Toll Collection

SW Architecture Performance Modeling

IVHS: Intelligent Vehicle Highway Systems

Dense wireless network of sensor,

• Task: ambient conditioning systems allow thermal conditioning in small, localized

Printer Based Internet

Passive CCR comm.

Analog I/O, DSP, Control

Thick film battery

Mapleseed solar cell 1-5 cm

Source: R. Yeh, K. Pister, UCB/BSAC

 works in a reactive and time-constrained environment

 Software is used for providing features and flexibility

• Limited synergies between HW & SW

 Embedded systems market has surpassed the PC market

 Systems differ in many aspects (functionality, time constraints,

 Design methodologies are important to handle complexity

 Methods for HW design align with modern SW design

Poor common infrastructure. Weak specialization of functions.

Refining (or partitioning)

Development is not a pure top-down process Integration

=> in practice the development process is a mixture of

The goals of the analysis phase are

=> Problem definition (German: Lastenheft)

• product goals, scope and major directions of the development

• specifies variables and constants of the product to be developed

• identifies resources necessary to conduct the development (capital

=> Output (depends on exact focus of feasibility study)

• info on technological and financial risks of project

• needed resources for development and/or marketing

• evaluation of possible technical alternatives

=> Requirements specification (German: Pflichtenheft)

• Defines output of the development process (deliverables)

• Definition of the interfaces to the environment

• Definition of overall functionality of the product

• Contraints on SW, operating system and HW

• Possibly guidelines for internal structure of the product

Architectural Design (Top-level Design) Design

Detailed Design (Module Design)

 System architecture – overall architecture (structural model, or mapping of

Different modeling approaches focus on different aspects of the system