technische development of integrated hard- and … · development of integrated hard- and software...

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

TECHNISCHE UNIVERSITÄTILMENAU

Inte

grat

ed H

ard-

and

Softw

are

Syst

ems

http

://w

ww

.tu-il

men

au.d

e/ih

s

Integrated HW/SW-Systems 2Andreas Mitschele-Thiel 6-Apr-06

System Development – Poor Process

Poor common infrastructure. Weak specialization of functions. Poor resource management. Poor planning.


System Development – Ordered Process

Good planning. Good common infrastructure. Specialization of functions. Good resource management.


General Development Tasks

Analysisof the requirements of the environment to the system

Modellingthe system to be designed and experimenting with algorithms involved

Refining (or partitioning)the function to be implemented into smaller, interacting pieces

HW/SW partitioningallocating elements in the refined model to either HW units or SW running on custom hardware or general microprocessors

Schedulingthe 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 modelValidation and verification


Analysis

Analysis Phase and Subphases

Problemanalysis

Feasibilitystudy

Requirementsanalysis

The goals of the analysis phase are

to identify the purpose and merit 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

Check the feasibility of the product development and the producttechnical 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• 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 environmentIdentify, analyze and classify the specific requirements of the product to be developed

The solution, i.e. the question of how therequirements 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 reliabilityQuality (absence of errors)SafetyOperating platform (OS, general HW)Power consumptionHeat disipationOperating environment (operating temperature, shock-, dust-resistance, etc.)SizeMechanical constructionEMC (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 thedesign 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 coordinationmodules 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 theimplementation technique, e.g. its algorithms

Implementation Designtake 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_transfermsc data_transfer

application transport network medium network transport application

systemdata-oriented

viewfunctional

view

structuralview

behavioralview


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

END_TIMER_5 => END_TIMER_5 => ALARM_ONALARM_ON

KEY_OFF orKEY_OFF orBELT _ON =>BELT _ON =>

END_TIMER_10 orEND_TIMER_10 orBELT_ON orBELT_ON orKEY_OFF => ALARM_OFFKEY_OFF => ALARM_OFF

WAITWAIT

ALARMALARM

OFFOFF

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


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

&

&

&


Behavior and Structure

SystemSystemBehaviorBehavior

SystemSystemArchitectureArchitecture

MappingMapping

Flow To ImplementationFlow To Implementation

CommunicationRefinement

BehaviorBehaviorSimulationSimulation

PerformancePerformanceSimulationSimulation

Models of computation

HW/SW partitioning,scheduling

Synthesis

RequirementsStructural model


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

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 languagebehavior 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) orsimulated on virtual HW (VHDL, SystemC, SDL)

Behavioral specifications ensure thatthe functional requirements are methowever 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 specifiedHW components are selectedHW/SW partitioning may be decided...

Tasks:coding of functions, algorithms, etc. in the selected implementation languagetest 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-forwardthe implementation phase represents a small part of the development process (appr. 20% for pure SW projects)


Validation Methods

By constructionProperty is inherent.

By verificationProperty is provable.

By testingCheck behavior of (all) inputs.

By simulationCheck behavior in the model world.

By intuitionProperty is true. I just know it is.

By assertionProperty is true. Wanna make something of it?

By intimidationDon’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 andto different models of the system

to ensure conformance with various properties/requirements of the system or its components (behavior, temporal requirements, shock resistance, ...)


Integration

Purpose:ensure compliance with system requirementscomplete 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 thesystem 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 modeloften 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 releasesrefine 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 Model

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

requirements definition

top-leveldesign

detaileddesign

moduleimplementation

moduletest

integrationtest

systemtest

acceptancetest

application scenarios

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 VCC Separation and Mapping

SystemBehavior

SystemArchitecture

SystemImplementation

SystemPerformance

SystemBehavior

SystemArchitecture

Mapping

Behavior onArchitecture

Refine

Implementationof System

1 2

3

4

Data Sheetson paper

ExecutableData Sheets


References

System FocusD. 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 FocusH. 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 development of integrated hard- and … · development of integrated hard- and software...

Documents