Digital Systems Design

TECHNISCHE UNIVERSITÄT ILMENAU

Andreas Mitschele-Thiel

and Software Systems Dieter Wuttke - - Integrated Hard Integrated http://www.tu -ilmenau.de/ihs Digital Systems Design

Part I Introduction

2 Digital Systems Design 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 Digital Systems Design Motivation for the Course – Why is this important?

Embedded programming without knowledge of HW/SW integration

, September1999.

4 IomegaImage“borrowed” advertisement an from software Y2Kdrives,for diskand Scientific American Digital Systems Design Motivation for the Course – Why is this important?

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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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: [email protected] Email: [email protected] Phone: 03677-69-2819 Phone: 03677-69-2820

Dr. Karsten Henke Office: Zusebau, Room 2078 Email: [email protected] Phone: 03677-69-1443

10 Digital Systems Design Introduction

. Integrated HW/SW systems by example

. Issues of HW/SW systems development

11 Digital Systems Design 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 Digital Systems Design Example: UMTS Network

UTRAN CN RNS CS Domain

User Node B Equipment (UE) GMSC RNC MSC/VLR

Node B Iub Registers

Iur

RNS HLR/AuC/EIR

Node B

SGSN Gn GGSN RNC PS Domain UE Node B Iub

Uu Iu 13 Digital Systems Design Example: Digital Wireless Platform

Dedicated Logic uC core and Memory (ARM)

phone Java Keypad, book Logic Accelerators 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 Digital Systems Design 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 Digital Systems Design 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) Digital Systems Design 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, Voice Control Challenges Diagnostics Comms, User Apps Stylus, ETC • Minimum Technology to Satisfy User Requirements Display • Usability Processor Heads Up, • Integrate with Other Vehicle RISC, PowerPC Flat Panel X86, Hitachi RISC Systems Graphics • Add Functions Without Adding the Cost

17 Digital Systems Design 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 Digital Systems Design Example: Home Networking Application (Subnet) Clusters

Stereo Web-TV Voice Video STB TV Phone Phone Entertainment Based Telecom DVD Cam PDA Player Corder Based

PC-1 Still PC-2 laptop VCR 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 Digital Systems Design 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 Digital Systems Design Example: Airborne Dust

Mapleseed solar cell 1-5 cm MEMS/Hexsil/SOI

Controlled auto-rotator Rocket dust MEMS/Hexsil/SOI MEMS/Hexsil/SOI 21 Digital Systems Design Example: Synthetic Insects

22 Source: R. Yeh, K. Pister, UCB/BSAC Digital Systems Design 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 . 23 power, cost and reliability are often important issues Digital Systems Design What is a System Anyway?

environment

sensor sensor sensor sensor sensor actor

processing . Environment to environment . Sensors + Information Processing + Actuators . Computer is a system . Microprocessor (ASCI, memory) is not 24 Digital Systems Design Design Process: Behavior vs. Structure

Performance models: Models of emb. SW, comm. and comp. resources computation Requirements

System System Validation Behavior Architecture HW/SW Behavior Mapping partitioning, Simulation scheduling

Performance Simulation SW Synthesi Communication estimation s Refinement

Flow To Implementation

25 Digital Systems Design 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

? • HW or IP Selection Software Hardware • Design • Verification • System Test

Clock VCXO Select

Tx Synth/ STM I/F Optics MUX Line STS OHP Cell/ I/F XC SPE Data Rx CDR/ STS Packet Map Framer Optics DeMUX PP I/F

mP 26 Digital Systems Design 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 Digital Systems Design Digital Systems Design

Part II Development Process

2 Digital Systems Design System Development – Poor Process

Poor common infrastructure. Weak specialization of functions. Poor resource management. Poor planning. 3 Digital Systems Design System Development – Ordered Process

Good planning. Good common infrastructure. Specialization of functions. Good resource management. 4 Digital Systems Design 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 Digital Systems Design System Development Process – The Theory

Analysis Waterfall model

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 bottom-up and top-down design 6 Digital Systems 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 design section . Support . Documentation . Cost (development, deployment and operation) . Date of completion 11. ... Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Design Models and Views – An Overview

Different modeling approaches focus on different aspects of the system

& & &

structural msc data_transfer view application transport network medium network transport application

data-oriented functional system view view

behavioral view

15 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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, ...) Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design V Model

Extension of the waterfall model to integrate quality assurance (verification and validation)

requirements application scenarios acceptance definition test validation

top-level test cases system design test

detailed test cases integration design test

test verification 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) Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Digital Systems Design

Part III Requirements

2 Digital Systems Design Requirements

. Analysis process . Functional requirements . Performance requirements . Real-time requirements . Safety and reliability . Principles and elements of requirements analysis

3 Digital Systems Design The Importance of Requirements

Proper definition of the requirements is vital to ensure quality! 4 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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) KEY_OFF or END_TIMER_5 => S OFF BELT _ON => ALARM_ON * c2 + o(n) END_TIMER_10 or i(n-1) c2 * i(n-1) BELT_ON or ALARM KEY_OFF => ALARM_OFF 7 Digital Systems Design Performance Requirements

Important performance requirements . Capacity . Response time . Jitter

Examples of performance requirements: time response . 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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) . A. Mitschele-Thiel: Systems Engineering with SDL – Developing Performance- Critical Communication Systems. Wiley, 2001. . B. Thomé (Editor): Systems Engineering – Principles and Practice of Computer-based Systems Engineering, Wiley, 1993.

17 Digital Systems Design Digital Systems Design Part IV Behavioral Models and Specification Languages

1 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Finite State Machines – Control Algorithms

5 Digital Systems Design Finite State Machines – Discussion

6 Digital Systems Design Moore vs. Mealy Automata

Theoretically, same computational power In practice, different characteristics . Moore machines: . non-reactive (response delayed by 1 cycle – δ τ µ nZ aZ Y clocked change of output only) X . 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 Digital Systems Design Finite State Machines – Discussion

8 Digital Systems Design Finite State Machines – Example: state diagram (informal)

9 Digital Systems Design Finite State Machines – Discussion

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 Digital Systems Design Finite State Machines - Extensions

Divide and conquer

⇒ Nondeterminism

⇒ Parallel automata

⇒ Processes

⇒ Communication

⇒ Hierarchy

⇒ Graphical support

⇒ Extended formal semantic

11 Digital Systems Design 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 => SEC => END SEC => END 6 SEC => 8 7 SEC => SEC =>

12 Digital Systems Design 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 a s2 s3 a b a s2 13 Digital Systems Design 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 Digital Systems Design FSM Composition – Example

Example: seat belt control || timer KEY_ON => START_TIMER WAIT

KEY_OFF or END_TIMER_5 => OFF Belt BELT _ON => ALARM_ON Timer Control END_TIMER_10 or BELT_ON or ALARM KEY_OFF => ALARM_OFF

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 Digital Systems Design FSM Composition – Example

Example: seat belt control || timer KEY_ON => START_TIMER WAIT

KEY_OFF or END_TIMER_5 => OFF Belt BELT _ON => ALARM_ON Timer Control END_TIMER_10 or BELT_ON or ALARM KEY_OFF => ALARM_OFF

START_TIMER => SEC => SEC => SEC => 1 2 3 4 SEC => START_TIMER => END_TIMER_5

SEC => SEC => SEC => SEC => SEC => END_TIMER_10 0 9 8 7 6 5

16 Digital Systems Design FSM Composition – Example

Cartesian product

KEY_ON and START_TIMER => START_TIMER must 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 Digital Systems Design Finite State Machines - Extensions: parallel automata

18 Digital Systems Design FSM Extensions – Example: user interaction > Processes

19 Digital Systems Design FSM Extensions - Communication (MSC)

20 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Digital Systems Design

Part V High-level Synthesis

1 Digital Systems Design High-level Synthesis

. 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 Digital Systems Design 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 Digital Systems Design 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

abstraction levels layout PowerPC750 physical domain (layout) 5 Digital Systems Design Abstraction Levels

structural domain behavioral domain

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) Digital Systems Design Structural Synthesis

Structural synthesis is the translation from a behavioral description into a structural description structural domain behavioral domain

processors, memories, buses CFG, algorithms registers, ALUs, MUXs register transfers gates, flip-flops Boolean expressions transistors transistor functions

transistor layout cells chips

boards

7 physical domain (layout) Digital Systems Design 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, memories, buses CFG, algorithms registers, ALUs, MUXs register transfers gates, flip-flops Boolean expressions transistors transistor functions

transistor layout

cells

chips

boards

8 physical domain (layout) Digital Systems Design 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, memories, buses CFG, algorithms registers, ALUs, MUXs register transfers gates, flip-flops Boolean expressions transistors transistor functions

transistor layout

cells

chips

boards

9 physical domain (layout) Digital Systems Design 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 behavioral domain structural domain (b) a control unit that controls the sequencing of the states in the register-transfer description processors, memories, buses CFG, algorithms registers, ALUs, MUXs register transfers gates, flip-flops Boolean expressions transistors transistor functions

transistor layout

cells

chips

boards

10 physical domain (layout) Digital Systems Design High-level Synthesis

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, memories, buses CFG, algorithms registers, ALUs, MUXs register transfers gates, flip-flops Boolean expressions transistors transistor functions

transistor layout cells chips

boards

11 physical domain (layout) Digital Systems Design Levels of Synthesis

12 Digital Systems Design 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) Digital Systems Design 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 Digital Systems Design 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) Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design DFG – Example

21 Digital Systems Design CDFG – Loop

22 Digital Systems Design 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) . Data Flow Graph (DFG) . Control Flow Graph (CFG) . Control/Data Flow Graph Specification Languages (CDFG) . StateCharts . SDL . VHDL . SystemC . ... 23 Digital Systems Design 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 Digital Systems Design 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 - may be 5 RT synthesis) + implemented 9 + on < 10 25 11 Digital Systems Design High-level Synthesis: Example Scheduling with unlimited resources: => latency 4 T

* * * * + 1 2 6 8 10

* * + < 3 7 9 11

- 4

- 5

t4 26 Digital Systems Design High-level Synthesis: Example Mapping and scheduling with limited resources:

. 4 multipliers

. 2 ALUs => latency 4 T t0

* * * * + 1 2 6 8 10

* * + < 3 7 9 11

- 4

- 5

t4 27 Digital Systems Design High-level Synthesis: Example Mapping and scheduling with t0 limited resources: * + . 1 multiplier 1 10 t1 . 1 ALU < => latency 7 T * 2 11 t2

* 3

t3 * - 6 4 t4 * 7 t5

* 8 - 5

+ 9 t 28 7 Digital Systems Design 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 7 9 11

dito - 4

dito - 5

t4 29 Digital Systems Design 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

dito * * 3 6

t2 assign nodes with - * * + scheduled successor 4 7 8 10

t3 assign all nodes without sucessor + < - 5 9 11

t4 30 Digital Systems Design 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)

* * * * + 1 2 7 8 10 t1

< * 3 * + 11 76 9 t2

- 4 * * 6 8

- 5 + 9

t4 31 Digital Systems Design 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) * Example: 1 multiplier, 1 ALU 3 t3 Priority assignment (according to length to sink): * - 6 4 4 4 3 2 2 * 1 * 2 * * 8 + 10 t 6 4 * 7 3 * 2 * 1 + 1 < 3 7 9 11 t5

* 8 - 5 2 - t 4 6

+ 9 t 32 1 - 7 Digital Systems5 Design 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

t * * 3 Priority assignment (length to sink): 3 6

t4 6 * 6 * 5 * 3 * 2 + 1 2 6 8 10

t5 * 7 * 8 4 * 3 * 1 + 1 < 3 7 9 11 t6 - + 4 10 2 - 4 t7 - + 5 9 t 1 - 8 5 < 11 33 t Digital Systems Design 9 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 Digital Systems Design 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 . J. Teich: Digitale Hardware/Software Systeme. Springer, 1997.

35 Digital Systems Design Models, Concepts and Languages

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 Digital Systems Design StateCharts – Basic Principles

. 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 Digital Systems Design

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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design StateCharts – Top Down Design

State V is an abstraction of states S and U

11 Digital Systems Design StateCharts – Default State

Flat structure Hierarchical structure

12 Digital Systems Design StateCharts – Default State

Flat structure Hierarchical structure

13 Digital Systems Design StateCharts – Exit on Sub-States

Incorrect (b=c ???) correct

14 Digital Systems Design StateCharts – Default State and History

Default: “off” on first activation Same meaning Then: history

15 Digital Systems Design StateCharts – AND State

Parallel structure: n+m states Flat structure: ???

16 Digital Systems Design StateCharts – AND State

Flat structure: equivalent FSM ! n*m states 17 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design StateCharts – Action on Entry and/or Exit

20 Digital Systems Design StateCharts – Synchrony Hypothesis

21 Digital Systems Design StateCharts – Synchrony Problem

22 Digital Systems Design StateCharts – Microsteps

23 Digital Systems Design StateCharts – Example

24 Digital Systems Design StateCharts – AND Decomposition <> Composition

To be in state U the system V, W U k must be both in states S and T V, Y V, Z S T k e V Z X,Y X,Z e W e X Y e

k X,W Q

Q R R 25 Digital Systems Design StateCharts – Summary

26 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Concurrency, causality, choice

Concurrency

t5 Causality, sequencing

Choice, conflict t3 t4

t6 33 Digital Systems Design Communication Protocol

Send msg

Process 1 Process 2

Send Ack

Receive Ack

34 Digital Systems Design Producer-Consumer Problem

Produce

Buffer

Consume

35 Digital Systems Design 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 Digital Systems Design Control vs. Data Flow Applications

38 Digital Systems Design Data Flow Graph (DFG)

Powerful formalism for data-dominated applications

Languages: . graphical: Ptolemy (UCB), GRAPE (U. Leuven), SPW (Cadence), COSSAP (Synopsys) . textual: Silage (UCB, Mentor), Haskell, Lucid 39 Digital Systems Design 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 Digital Systems Design DFG – Example

41 Digital Systems Design 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 Digital Systems Design CFG – Example (detailed level)

43 Digital Systems Design Control/Data Flow Graph (CDFG)

44 Digital Systems Design CDFG – Entity

Legend: data dependencies control dependencies

Notes: AND dependencies at NOPs (NO Operation), OR dependencies at BRanches and LOOPs 45 Digital Systems Design 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 Digital Systems Design CDFG – Loop

47 Digital Systems Design CDFG – Call

48 Digital Systems Design Review of Models, Concepts 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 50 . time constraints (e.g. exec. time) Digital Systems Design References

. D. Gajski, F. Vahid, S. Narayan, J. Gong: Specification and Design of Embedded Systems. Prentice Hall, 1994. (chapters 2 and 3) . J. Teich: Digitale Hardware/Software Systeme. Springer, 1997. . http://www.sei.cmu.edu/publications/documents/02.reports/02tn001.html

51 Digital Systems Design Models, Concepts and Languages

1 Digital Systems Design Parallel Finite State Machines - Result of Decomposition

2 Digital Systems Design Parallel Finite State Machines Example

3 Digital Systems Design Single FSM

4 Digital Systems Design FSM- Decomposition / Composition

5 Digital Systems Design Parallel Finite State Machines - Properties

. Concurrency . Delay . Synchronization . Rendezvous

. Mutual exclusion

. Blocking

. Priorization

6 Digital Systems Design Finite State Machines - Stability

. Stable {X2,X1,X0}

. {X0}

{X3}

. {X1}

. In = X1= Out

7 Digital Systems Design Finite State Machines - Stability

. Instable {X2}

. {X0} {X1,X0}

. {X1} {X3}

. In = X1= Out

8 Digital Systems Design Finite State Machines - Stability

. Conditionally stable

stable for X0

. In = X0 Out ={X0,X2,X3}

. In = X1 Out = X1

(instable for X1 )

9 Digital Systems Design Finite State Machines - Stability

. Example

10 Digital Systems Design Finite State Machines - Stability

. Example

11 Digital Systems Design Finite State Machines - Stability

. Example

12 Digital Systems Design Finite State Machines - Stability

. Example

13 Digital Systems Design Finite State Machines - Stability

. Instable States

14 Digital Systems Design Finite State Machines - Stability

. Stable States (abstraction)

15 Digital Systems Design Petri Nets (PNs)

22 Digital Systems Design 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 behavior Hierarchy Non-determinism . structural hierarchy (system, block, . choice between multiple transitions process, procedure) . non-deterministic ordering . behavioral hierarchy (hierarchical Timing transitions, fork-join) . timeouts 43 . time constraints (e.g. exec. time) Digital Systems Design References

44 Digital Systems Design TECHNISCHE UNIVERSITÄT ILMENAU

Systems Design

Part VI Time and Performance Evaluation

1 Digital Systems Design Evaluation of Temporal and Performance Aspects

. Problem Statement . Performance Evaluation

. Performance Modeling

and Software Systems - - Integrated Hard Integrated http://www.tu -ilmenau.de/ihs

3 Digital Systems Design Example: IP Office Firewall

Analysis Typical performance-related Design . identify questions in design phase: performance . System architecture? requirements Implementation . HW architecture, need for . identify traffic special HW? . evaluate design 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? evaluation . replace costly performance . Which operating system? functions by 4 requirements . …? cheaper Digital functions 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! 5 estimate estimate Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Example

Application (DFG or CFG) Resources

1 P1 2 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 Digital Systems Design 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 Digital Systems Design 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∈A load(p,r) where r . 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 Digital Systems Design Process Graph Analysis

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) = w max {∑ load(p,r)} + w ∑ load(c) p ∀ r ∈ R p ∈ Ar c c ∈ Ac 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 Digital Systems Design Process Graph Analysis

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 Digital Systems Design 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 Digital Systems Design 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 phy network 4 5 medium 33 ms 3 4 1 Mb 30 Mbps 3 4 prot. stack 6 1 prozessor 2,8 MI 120 MIps 23 ms

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) Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 = ∑ (U ) = ∑ (C /T ) < N(21/N – 1) i=1...N i i=1...N i i where . i identifies the process, . U specifies the resource utilization due to process i i . Ci specifies the computation time of process i . T specifies its period i . 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:

. simple test for simple models (deadline , etc.) 20 Di = Ti Digital Systems Design Schedulability Analysis – Example

process period T comp. time C priority P 0 3 1 3 all times in ms 1 4 1 2 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  Digital Systems Design 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 R of process i is R C I where I is the maximum i i = i + i i 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 I of the higher priority i,j process j on process i is I = R /T * C i,j i j j . 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

For details and variants see Burns&Wellings or Krishna&Shin 22 Digital Systems Design 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: R = C + I = C + 0 = 1 ms 0 0 0 0 

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 R = C + I = C + I = C + R‘ /T * C = 1 + 2/3 * 1 = 2 ms 1 1 1 1 1,0 1 1 0 0 

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

R2 = C2 + I2 = C2 + I2,0 + I2,1 = C2 + R‘2/T0 * C0 + R‘2/T1 * C1 = 2 + 4/3 * 1 + 4/4 * 1 = 5 ms

R2 = C2 + I2 = C2 + I2,0 + I2,1 = C2 + R‘2/T0 * C0 + R‘2/T1 * C1 = 2 + 5/3 * 1 + 5/4 * 1 = 6 ms R = C + I = C + I + I = C + R‘ /T * C + R‘ /T * C = 2 + 6/3 * 1 + 6/4 * 1 = 6 ms 23 2 2 2 2 2,0 2,1 2 2 0 0 2 1 1  Digital Systems Design 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 ∑ p = 1 i=0...n i . 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) Digital Systems Design 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 steady state implies that state 2: λp1 + µp3 = λp2 + µp2 arrivals = completions state 1: λp0 + µp2 = λp1 + µp1 state 0: µp1 = λp0

normalization equation: p0 + p1 + p2 + p3 = 1 . resolution of system of equations to derive state probabilities

2 3 p0 = 1 / (1 + λ/µ + (λ/µ) + (λ/µ) ) 2 3 p1 = (λ/µ) / (1 + λ/µ + (λ/µ) + (λ/µ) ); 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. Digital Systems Design 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

See R. Jain for details 26 Digital Systems Design Queuing Network Analysis - Example

Example: communication system (unbounded queues)

arrival rate: 25 packets/s λ = 25 1/s prot. stack µ = 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 = ∑ n =7,39 i i 27 . mean response time T = N/λ = 296 msec (Little’s law) Digital Systems Design 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 Digital Systems Design 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 4 5 0 2 4 6 8 10 3/ 3 4/ 4 3 4/ 5 Discussion 6 1/ 6 . no assumptions Legend: . danger of including too many details green: execution time . evaluation is time consuming blue: process priority (1=low) . problems with rare events . large set of tools and models available 29 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design TECHNISCHE UNIVERSITÄT ILMENAU

Digital Systems Design

Part VII Optimization

1 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Genetische Algorithmen – Minimum Spanning Tree

. small population results in inbreeding .17larger population works well with small mutation rate . tradeoff between size of population and number of iterations Digital Systems Design Genetic Algorithms –Basic Operations

. Mutation . => crating a new member of the population by changing one member

18 Digital Systems Design Genetic Algorithms –Basic Operations

. Crossover . => crating a new member of the population from two members

19 Digital Systems Design Genetische Algorithmen – Traveling Salesman Problem

. minimal impact of mutation rate with small population .20negativ impact of high mutation rate with larger population (increased randomness) – impact not quite clear Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 termination criteria satisfied More advanced techniques maintain attributes of the solutions rather than the solutions itself 23 y Digital Systems Design 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: 1 (A1) change of the value of a task assignment variable 2/ 1 (A2) move to HW 2 1/ 2 4 5 (A3) move to SW 3 3/ 3 4/ 4 4/ 5 (A4) combined change of some attributes 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 5 . length of the longest (critical) path to the sink 3 /4 4 /5 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 Digital Systems Design 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 source node (node 1) 4 /7 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 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design 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 nearest neighbors (nodes/clusters) 12 y Digital Systems Design Hierarchical Clustering

Dendrogram

Algorithm is kind of subsequent merger of nearest neighbors (nodes/clusters) 13 Digital Systems Design Partitioning Clustering (k-means)

Choose positions of k initial cluster representative

assign each node to the nearest cluster representative

Recompute positions of the cluster representative Based on the positions of the nodes in each cluster

n Number of iterations reached y 14 Digital Systems Design 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 Digital Systems Design 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 Digital Systems Design Clustering – Hierarchical Algorithms

Single linkage Complete Linkage

Centroid-based

Algorithms implement different methods to compute the distance between two clusters 17 Digital Systems Design Clustering – Single Linkage

10 9 P1 P7 Distance between groups is estimated as 8 P5 the smallest distance between entities 7 6 Example: 5 P3 P4 4 d 5)4,2( = min[], 4525 ddd 45 == 1.4 3 P6 2 P2 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 Digital Systems Design Clustering – Single Linkage

10 Cluster # P1 C24 P3 C57 P6 9 P7 P1 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 4 C57 - - - 0 5.1 3 P6 P6 - - - - 0 2 P2 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 P6C243 P7 - 0 2.8 2.2

P1 0 7.2 5 7.1 6.1 9.2C57 7 - - 0 5.1

P2 - 0 3 1.4 5.4 P63 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 Digital Systems Design Clustering – Group Average

10 Distance between groups is defined 9 P1 P7 8 P5 as the average distance between 7 all pairs of entities 6 5 P3 Example: P4 4 3 1 P6 2 P2 5)4,2( ()ddd 4525 =+= 8.4 1 2 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 20 Digital Systems Design Clustering – Group Average

10 Cluster # P1 C24 P3 C57 P6 9 P7 P1 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 4 C57 - - - 0 5.6 3 P6 P6 - - - - 0 2 P2 1 0 0 2 4 6 8 10 Cluster # P1 C243 C57 P6

P1 0 6.4 6.1 9.2 Cluster # P1 P2 P3 P4 P5 P6 P7 C243 - 0 4.8 2.5

P1 0 7.2 5 7.1 6.1 9.2C57 7 - - 0 5.1

P2 - 0 3 1.4 5.4 P63 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 Digital Systems Design Clustering – Centroid-based

10 9 x P7 Determine distances between centroids (k,l) P1 x 8 P5 Merge centroids with the least distance 7 6 ),( (()()2 −+−= CCCClkd 2 ) 5 P3 k xx l k yy l x P4 4 3 x P6 2 P2 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 22 Digital Systems Design Clustering – Centroid-based

10 Cluster # C1 C24 C3 C57 C6 9 x P7 P1 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 P6 2 P2 C6 - - - - 0 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 23 Digital Systems Design Differences between Clustering Algorithms

4 4 x 10 x 10 2.5 4 2.5 x 10 2 2 Single2.5 Linkage K-means 1.5 1.5

1 Single Linkage 1 2 CentroidK-CompleteWardmeans Linkage Linkage 0.5 0.5

0 0 Y (m) 1.5 Y (m) 4 -0.5 x 10 -0.5 2.5 -1 -1 2 1 -1.5 Complete Linkage -1.5 1.5 -2 -2 1 0.5 -2.5 -2.5 -3 0.5 -2 -1 0 1 2 3 -3 -2 -1 0 1 2 3 X (m ) 4 X (m ) 4 x 10 x 10 0 0 Y (m) Y (m) Y (m) 4 x 10 -0.5 2.5

-1-0.5 2

4 Ward -1.5 x 10 1.5 2.5 -2 -1 1 2 -2.5 Centroid Linkage 0.5 -3 1.5 -2 -1 0 1 2 3 X (m ) 4 -1.5 x 10 0

1 Y (m) -0.5 0.5 -2 -1 0 Y (m) -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 ) 4 x 10 x 10 -2

24 -2.5 -3 -2 -1 0 1 2 3 Digital Systems DesignX (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 algorithm MST ROCK

Distance Metrics . Camberra . Euclidean . Chebychev . Manhattan . Correlation . Minkowsky . Chi-square . Mahalanobis . Kendalls‘s Rank 25 . Jaccard Correlation Digital Systems Design 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 Digital Systems Design 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 5 g(x) exact value of partial schedule 2 5 h(x) underestimate for remainder (rem) =(min (altern.rem.proc, rem.comm. + rem.proc.) 2 8 3 9 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 Digital Systems Design Branch and Bound with Underestimates

Example: computation of f(3)

1 5 1 1 -> A 2 1 -> B 2 5 f(1)=17 f(2)=17

2 8 3 9 f(x) = g(x) + h(x) 3 2 -> A g(x) exact value of partial 6 1 f(3)=22 schedule 4 3 h(x) underestimate for remainder case 1: A= path 1-2-4 A g(3) = 5 + 8 = 13 1 2 4 B 2->4 4 h(3) = min(3, (5+9+3)) 24 f(3) = 16 0 4 8 12 16 20 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 Digital Systems Design Berechnung

. Annahme: Kommunikation auf gleichem Processor läuft parallel zur CPU . f(1) = 5 + 9 + 3 = 17 f(2) Gleiches Ergebnis, 1 da egal, ob Prozess 1 auf A oder B läuft 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 Prozess 1 auf A, 2 auf B 6 1 4 (daher +2 Kommunikation und proc 8+5) 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 Digital Systems Design 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 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 3 f(x) = g(x) + h(x) 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) Digital Systems Design References

. A. Mitschele-Thiel: Systems Engineering with SDL – Developing Performance- 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