technische universitÄt development of integrated hard- and ... · development of integrated hard-...

Development of Integrated Hard- and Software Systems: Tasks and Processes

TECHNISCHE UNIVERSITÄTILMENAU

Inte

grat

ed C

omm

unic

atio

n Sy

stem

sht

tp://

ww

w.tu

-ilm

enau

.de/

iks

Integrated Communication-Systems 2Andreas Mitschele-Thiel 14-Jan-11

General Development Tasks

Analysis of the requirements of the environment to the system

Modeling 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)


System Development Process – The Theory

Analysis

Design

Implementation

Integration

Maintenance

Development is not a pure top-down process use of subcomponents from the shelf

=> bottom-up 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

Waterfall model


Analysis

Analysis Phase and Subphases

Problemanalysis

Feasibilitystudy

Requirementsanalysis

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


Problem Analysis

Preliminary study to analyse important needs of the environment to be supported by the system

discuss principal solution strategies

=> 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)

AnalysisProblemanalysis

Feasibilitystudy



Feasibility Study (Machbarkeitsstudie)

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)

Focus of the feasibility study are critical issues of the system

in order toimprove 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


Feasibilitystudy




Feasibilitystudy


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

developedThe solution, i.e. the question of how the

requirements are met is typically left open

=> 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


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 ...

We will see methods to ensure that the requirements are met in the design section


Design and Subphases

Design

Architecturaldesign

Detaileddesign

Implementationdesign

Purpose: decide how the system meets the requirements -> inside view focus on the solution


Design and Subphases

Architectural Design (Top-level Design) define the modules of the system and

their interfaces goal: maximize internal coherence and

minimize intermodule coordination modules are typically functional entities

but may be structural entities as well (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

Implementation Design take into account the details of the used

implementation technique, e.g. interfaces to operating systems and hardware

Design

Architecturaldesign

Detaileddesign

Implementationdesign

When is the behavior of the system decided and when the structure?


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

...


&

&&

Design Models and Views – An Overview

Different modeling approaches focus on different aspects of the system

msc data_transferapplication transport network medium network transport application

systemdata-oriented

viewfunctional

view

structuralview

behavioralview


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

&

&

&


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

Process 1

Send msg

Receive Ack

Send Ack

Process 2

KEY_ON => START_TIMER

END_TIMER_5 => ALARM_ON

KEY_OFF orBELT _ON =>

END_TIMER_10 orBELT_ON orKEY_OFF => ALARM_OFF

WAIT

ALARM

OFF

o(n) = c1 * i(n) + c2 * i(n-1)


Behavior and Structure

SystemBehavior

SystemArchitecture

Mapping

Flow To Implementation

CommunicationRefinement

BehaviorSimulation

PerformanceSimulation

Models of computation

HW/SW partitioning,scheduling

Synthesis

RequirementsStructural model

Validation


Behavior meets Structure: The Optimization Problem

Structural Space

System Platform

Behavioral Space


Behavior meets Structure: The Optimization Problem

There are numerous solutions to define 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

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 optimizationproblem

Structural Space

System Platform

Behavioral Space


Design: Behavior vs. Structure

Behavioral specifications describe the functionality of the system using some modeling or programming language

behavior specifications may be abstract models (state charts, UML, SDL) or concrete programs (C, VHDL, SystemC)

behavioral specifications may be executed/implemented on real HW (C program, assembler) or simulated on virtual HW (VHDL, SystemC, SDL)

Behavioral specifications ensure that the functional requirements are met however there is no confidence in non-functional aspects of the system, e.g.

performance, real-time, fault tolerance, cost, power consumption, ...

Structural specifications are needed to implement the system in HW

So, when is the best point in time to decide the structure?


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)


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 systemto ensure conformance with various properties/requirements of the system or its components (behavior, temporal requirements, shock resistance, ...)


Integration

Purpose: ensure compliance with system requirements complete the system for delivery

Tasks: System integration: subsequent addition of HW components and SW

modules to the system until the final system is established Integration testing: stepwise testing of system (requires knowledge of the

system as a whole) System testing: test after all parts have been integrated

Notes: Testing may be applied to almost all requirements or properties of systems,

system components or modules (functionality, performance, reliability, termal resistance, shock resistance, ergonomics, man-machine interface, documentation, ...)

Testing is the most popular validation method in practice


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


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)


Classic Waterfall Model & Iterative Waterfall Model

Analysis

Design

Implementation

Integration

Maintenance

Classic 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

Limits of the waterfall model often the requirements are

incomplete in the beginningwaterfall model is not appropriate where requirements are not well understood or not well defined

with the waterfall model, there are no intermediate product releases

Idea of the evolutionary model: provide intermediate product

releases refine and extend

requirements during the development process

analysis

design

implementation

new prototypeneeded

modification of product definition

y

test

n


Spiral Model

Meta model supporting the flexible combination of the above approaches

review results;plan next iteration

define objectives,alternatives and constraints

evaluate alternatives,identify and resolve

risks

developand verify


V ModelExtension of the waterfall model to integrate quality assurance

(verification and validation)

requirements definition

top-leveldesign

detaileddesign

moduleimplementation

moduletest

integrationtest

systemtest

acceptancetest

application scenarios

High level test cases

test cases

testcases

valid

atio

nve

rific

atio

n

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 the specification provided as input (is the system built right? – process quality)


Traditional (Early Partitioning) vs. Codesign Approach

Early Partitioning (Structure First) HW/SW Codesign (Behavior First)

system architectur

HW descr. SW descr.

HW impl. SW impl.

prototyp/product

system description

HW impl. SW impl.

system architectur

prototyp/product

+ joint system description/model eases validation and integration

- joint description is not optimized for both HW and SW

+ flexibility wrt. HW/SW partitioning

+ optimized descriptions/models for HW and SW parts, respectively

- lack of flexibility wrt HW/SW partitioning

- problems with HW/SW integration


Traditional vs. Codesign Approach (Polis, Cadence VCC)

Traditional System Design

SystemBehavior

SystemArchitecture

SystemImplementation

SystemPerformance

Data Sheetson paper

VCC Separation and Mapping

SystemBehavior

SystemArchitecture

Mapping

Behavior onArchitecture

Refine

Implementationof System

1 2

3

4

ExecutableData Sheets


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.

technische universitÄt development of integrated hard- and ... · development of integrated hard-...

Documents