Modeling of embedded system behavior
This presentation is the property of its rightful owner.
Sponsored Links
1 / 113

Modeling of Embedded System Behavior PowerPoint PPT Presentation


  • 59 Views
  • Uploaded on
  • Presentation posted in: General

Modeling of Embedded System Behavior. EE298-2 (Fall 2000): Lecture #2 October 3, 2000. Reading. Required [Sgroi00] Sgroi, M.; Lavagno, L.; Sangiovanni-Vincentelli, A. Formal models for embedded system design. IEEE Design & Test of Computers, vol.17, (no.2), IEEE, April-June 2000. p.14-27.

Download Presentation

Modeling of Embedded System Behavior

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Modeling of embedded system behavior

Modeling of Embedded System Behavior

EE298-2 (Fall 2000): Lecture #2October 3, 2000


Reading

Reading

  • Required

    • [Sgroi00] Sgroi, M.; Lavagno, L.; Sangiovanni-Vincentelli, A. Formal models for embedded system design. IEEE Design & Test of Computers, vol.17, (no.2), IEEE, April-June 2000. p.14-27.

    • [Douglass98] Douglass, B.P. State machines and statecharts. Embedded Systems Conference West, 1999. http://www.ilogix.com/dev/SMS.zip

    • Cynapps Cynlib documentation (will need for HW #2)http://chronos.cynapps.com/cgi-bin/download/lrm-index.pl

  • Recommended

    • [Harel97] Harel, D.; Gery, E. Executable object modeling with Statecharts. IEEE Computer, July 1997. p. 31-42.

    • [Edwards97] Edwards, S.; Lavagno, L.; Lee, E.A.; Sangiovanni-Vincentelli, A. Design of embedded systems: formal models, validation, and synthesis. Proceedings of the IEEE, vol.85, (no.3), IEEE, March 1997. p.366-90.


How to design embedded systems wescon 1975

How to Design Embedded Systems? (Wescon 1975)

  • “...deliberately avoid data processing aides such as assemblers, high-level languages, simulated systems, and control panels. These computer-aided design tools generally get in the way of cost-effective design and are more a result of the cultural influence of data processing, rather than a practical need.”

  • “It’ s my observation that the bulk of real-world control problems require less than 2,000 instructions to implement. For this size program computer aided design does little to improve the design approach and does a lot to separate the design engineer from intimate knowledge of his hardware.”


Methodical design of embedded systems

Methodical Design of Embedded Systems

  • Ad hoc approach to design does not work beyond a certain level of complexity, that is exceeded by vast majority of embedded systems

  • Methodical, engineering-oriented, CAD tool-based approach is essential

    • specification, synthesis, optimization, verification etc.

    • prevalent for hardware, still rare for software

  • One key aspect is the creation of models

    • concrete representation of knowledge and ideas about a system being developed

    • model deliberately modifies or omits details (abstraction) but concretely represents certain properties to be analyzed, understood and verified

    • One of the few tools for dealing with complexity


  • Abstractions and models

    Abstractions and Models

    • Foundations of science and engineering

    • Activities usually start with informal specification

    • However, soon a need for Models and Abstractions is established

    • E.g.: Chess and Poker - No Rules, No Games

    • Connections to Implementation (EE & Hardware) and Application (CS & Software)

    • Two types of modeling: system structure and system behavior


    Good models

    Good Models

    • Simple (Ptolemy vs. Galileo)

    • Amenable for Development of Theory

    • Has High Expressive Power (A game is interesting only if it has some level of difficulty)

    • Provides Ability for Critical Reasoning (Science vs. Religion)

    • Practice is currently THE only serious test of model quality

    • Executable

    • Synthesizable


    Elements of a model of computation language

    Elements of a Model of Computation: Language

    • A language is a set of symbols with superimposed syntax and semantics

      • text-based, visual

    • Syntax: Rules for combining symbols

      • well structured, intuitive

    • Semantics: Rules for assigning meaning to symbols and combinations of symbols

      • without a rigorous semantic definition, precise model behavior over time is not well defined

        • full executability and automatic h/w or s/w synthesis is impossible


    Semantics and model of computation

    Semantics and Model of Computation

    • Operational Semantics (Turing Machine): Which action can be taken by fully defined abstract machine

    • Denotational Semantics (Scott & Strachey): Meaning is defined in terms of relations

    • Model of Computation: How the machine can behave or what types of relationship are possible; May include communication style, aggregation, hierarchy, ...


    Design and model of computation

    Design and Model of Computation

    • A design is a system of atomic components

    • The model of computation defines the behavior and interaction of atomic components

    • Model Generality / Efficiency of Design Trade-off

    • Models are easy to define; It is difficult to see their limitations and eventual Effectiveness


    Classical cs models for general purpose computing

    Classical CS: Models forGeneral-Purpose Computing

    • Turing Machine, Post Machine, Universal Register Machine

    • RAM (von Neuman) => Algorithms and Computational Complexity

      • Algol, FORTRAN, Lisp, C, C++

  • CSP - Communicating Sequential Processes - C.A.R. Hoare

  • CCS - Calculus of Communicating Systems - R. Milner


  • Behavior modeling for embedded systems

    Behavior Modeling for Embedded Systems

    • Function: what does the system do

      • in non-real-time systems, this is sufficient

  • Time: meet temporal contract with the environment

    • temporal behavior important in real-time systems, as most embedded systems are

    • simple metric such as throughput, latency, jitter

    • more sophisticated quality-of-service metrics

      Computation model must support description of both functional and temporal behavior


  • Structure modeling for embedded systems

    Structure Modeling for Embedded Systems

    • Embedded systems often have complex high-level run-time structures

      • e.g. redundancy structure in a fault-tolerant system

      • represent the “architecture core”

  • Topological relationship between individual entities or objects

    • Peer relationships between communicating objects

    • Containment relationships

    • Layering relationships

  • Dynamic run-time structures


  • Infrastructure modeling for embedded systems

    Infrastructure Modeling for Embedded Systems

    • ES are more constrained than general-purpose systems

      • e.g. need for timeliness, low-power etc.

  • Models must allow for early and accurate predictions of key attributes of the actual systems

    • response times, throughput, availability etc.

    • finite capacities of underlying computing resources

    • many techniques developed over the years

      • schedulability analysis, queuing theory

  • Need to model not only the behavior and structure of the computation, but also the engineering infrastructure

    • physical devices: processors, networks, busses etc.

    • logical devices: tasks, locks, queues, OS services etc.

  • Resource modeling essential both for accuracy and for systems with application-defined resource management


  • Popular computation models for embedded systems

    Popular Computation Models for Embedded Systems

    • Communicating Finite State Machines

    • Synchronous / Reactive

    • Dataflow

    • Process Networks

    • Rendezvous-based Models (CSP)

    • Petri Nets

    • Tagged-Signal Model

    • Object-oriented Models

    • Heterogeneous Models


    Graphs as an abstract syntax for models

    Graphs as an Abstract Syntax for Models

    • Graph = <Nodes, Arcs>

    • Many computation models are obtained by ascribing specific interpretations (semantics) to the nodes and arcs, and sometimes by constraining the structure of the graph

      • e.g.: Petri nets, Data flow, FSM

  • Hierarchical graphs offer a useful visual representation


  • Finite state machines

    Finite State Machines

    • FSM is a mathematical model of a system that attempts to reduce model complexity by assuming:

      • system can be in a finite # of conditions called states

      • system behavior within a given state is essentially identical

      • system resides in states for significant periods of time

      • system may change states only in a finite # of well-defined ways, called transitions

      • transitions are the response of the system to external or internal events

      • Functions or operations called actions my be executed when the transition is taken, a state is entered, or a state is exited

        • implemented by an internal or external datapath or object’s operations

      • transitions and actions take (approximately) zero time, i.e. instantaneous

        • “synchronous”

      • events not permitted in a state are ignored or result in error or queued

  • FSM = (Inputs, Outputs, States, InitialState, NextState, Outs)

  • Often suitable for controllers, protocols etc.

  • Not Turing Complete, but more amenable to analysis

  • Rarely suitable for Memory and Datapaths


  • Fsm examples

    Source: B. P. Douglass & iLogix

    FSM Examples

    Elevator

    Control


    More complex fsm

    Source: B. P. Douglass & iLogix

    More Complex FSM

    • Reliable transmission service for a protocol stack

    • A message is sent that requires thereceiver to ACK

    • If an ACK doesn’t occur, retransmit

    • If the message is transmitted 5 times without ACK, inform the sender


    Protocol controller fsm

    Source: B. P. Douglass & iLogix

    Protocol Controller FSM


    Fsm example

    FSM Example

    • Informal specification

      if driver turns on the key and does not fasten seat belt within 5 seconds then sound the alarm for 5 seconds or until driver fastens the seat belt or turns off the key

    • Formal representation

      Inputs = {KEY_ON, KEY_OFF, BELT_ON, BELT_OFF, 5_SECONDS_UP, 10_SECONDS_UP

      Outputs = {START_TIMER, ALARM_ON, ALARM_OFF}

      States = {Off, Wait, Alarm}

      Initial State = off

      NextState: CurrentState, Inputs -> NextState

      e.g. NextState(WAIT, {KEY_OFF}) = OFF

      Outs: CurrentStae, Inputs -> Outputs

      e.g. Outs(OFF, {KEY_ON}) = START_TIMER


    Non deterministic fsm

    Non-Deterministic FSM

    • A FSM is said to be non-deterministic when the NextState and Outs functions may be RELATIONs (instead of functions)

    • Non-determinism can be user to model

      • unspecified behavior

        • incomplete specification

    • unknown behavior

      • e.g., the environment model

  • abstraction

    • (the abstraction may result in insufficient detail to identify previously distinguishable situations)


  • Mealy moore fsms

    Source: B. P. Douglass & iLogix

    Mealy-Moore FSMs

    • The set of states define the state space

    • State space are flat

      • all states are at the same level of abstraction

      • all state names are unique

    • State models are single threaded

      • only a single state can be valid at any time

    • Mealy state models: all actions are in transitions

    • Moore state models: all actions are upon state entry


    Retrigerrable one shot timer

    Source: B. P. Douglass & iLogix

    Retrigerrable One-shot Timer


    Problems with conventional fsm

    Source: B. P. Douglass & iLogix

    Problems with Conventional FSM

    • Scalability due to lack of metaphor for decomposition

    • No concurreny support

    • No support for orthogonal connections


    Scalability

    Source: B. P. Douglass & iLogix

    Scalability


    Scalability1

    Source: B. P. Douglass & iLogix

    Scalability


    Concurrency

    Source: B. P. Douglass & iLogix

    Concurrency

    • Problem:

      • a device can be in states

        • Off, Starting-up, Operational, Error

      • And, can be running from

        • mains, battery

    • How to arrange these states?


    Concurrency1

    Source: B. P. Douglass & iLogix

    Concurrency

    • Following are different states in Mealy/Moore view:

      • Operation with battery

      • Operation with mains

    • Leads to state explosion

    • Solution?

      • Allow states to operate concurrently


    Mealy moore solution

    Source: B. P. Douglass & iLogix

    Mealy-Moore Solution


    Concurrent state model solution

    Source: B. P. Douglass & iLogix

    Concurrent State Model Solution


    Orthogonal components

    Source: B. P. Douglass & iLogix

    Orthogonal Components

    How do you draw the state of this object?


    Approach 1 enumerate all

    Source: B. P. Douglass & iLogix

    Approach 1: Enumerate All


    Approach 2

    Source: B. P. Douglass & iLogix

    Approach 2


    Harel s statecharts extension of conventional fsms

    Harel’s StateCharts: Extension of Conventional FSMs

    • Conventional FSMs are inappropriate for the behavioral description of complex control

      • flat and unstructures

      • inherently sequential in nature

      • give rise to an exponential blow-up in # of states

        • small system extensions cause unacceptable growth in the number of states to be considered

  • StateCharts support:

    • repeated decomposition of states into AND/OR sub-states

      • nested states, concurrency, orthogonal components

    • actions (may have parameters)

    • activities (functions executed as long as state is active)

    • guards

    • history

    • a synchronous (instantaneous broadcast) comm. mechanism


  • Features of statecharts

    Features of StateCharts

    • Nested states and hierarchy

      • Improves scalability and understandability

      • helps describing preemption

    • Concurrency - two or more states can be viewed as simultaneously active

    • Nondeterminism - there are properties which are irrelevant


    Basic harel syntax

    Source: B. P. Douglass & iLogix

    Basic Harel Syntax


    State decomposition

    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: no sub-states (bottom of hierarchy)

  • Root State: no parent states (top of hierarchy)


  • Statechart or decomposition

    e

    S

    f

    V

    g[c]

    f

    T

    h

    StateChart OR-decomposition

    U

    e

    S

    V

    f

    g[c]

    T

    h


    Statechart and decomposition

    StateChart AND-decomposition

    V,W

    h

    k

    U

    g

    V,Z

    S

    T

    Z

    V,Y

    k

    V

    e

    m,p

    e

    e

    g

    W

    f

    h

    e

    f

    [in(Y)]

    g

    X,Z

    X,Y

    Y

    X

    m

    e

    e

    k

    h

    X,W

    e

    p

    p

    e

    n

    n

    p

    m,p

    R

    Q

    R

    Q

    p


    Statecharts syntax

    StateCharts Syntax

    • The general syntax of an expression labeling a transition in a StateChart is n[c]/a, where

      • n 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

  • Alternative: name(params)[guards]^event_list/action_list

    • Event list, aka propagated transitions, is a list of transitions that occur in other concurrent state machines because of this transitions

  • For each transition label, event condition and action are optional

    • an event can be the changing of a value

    • standard comparisons are allowed as conditions and assignment statements as actions


  • Transitions

    Transitions


    Statecharts actions and events

    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

      • executing the first transition will immediately cause the second transition to be taken simultaneously

  • Actions and events may be associated to the execution of orthogonal components:

    • action start(A) causes activity A to start

    • event stopped(B) occurs when activity B stops

    • entered(S), exited(S), in(S) etc.


  • Order of nested actions

    Source: B. P. Douglass & iLogix

    Order of Nested Actions

    • Executed from outermost – in on entry

    • Executed from innermost – out on exit


    History

    Source: B. P. Douglass & iLogix

    History

    • The history annotation H means that the state “remembers” the substate and returns to it as the default

    • Can also work with an initial state indicator


    Conditional transitions

    Source: B. P. Douglass & iLogix

    Conditional Transitions


    Another example of the power of statechart formalism

    Another Example of the Power of StateChart Formalism

    reset/

    Uninitialized

    ackB/

    • Conflicting function & control behaviors

      • Function: primary service of the entity

      • Control: actions performed within the system context

  • Solutions: single automaton, two peer concurrent states

  • ReadyToSendA

    send/^A

    reset/

    data/

    data/

    Initialized

    Error

    SendingA

    SendingB

    stop/

    start/

    Operational

    ReadyToSendB

    error/

    send/^B

    ackA/


    Example jolt cola machine

    Source: B. P. Douglass & iLogix

    Example: Jolt Cola Machine


    The combined state machine in statechart formalism

    The Combined State Machine in StateChart Formalism

    reset/

    Uninitialized

    reset/

    data/

    data/

    Initialized

    Error

    stop/

    start/

    Operational

    error/

    ackB/

    ReadyToSendA

    send/^A

    SendingA

    SendingB

    ReadyToSendB

    send/^B

    ackA/


    Example coin receptacle fsm

    Source: B. P. Douglass & iLogix

    Example: Coin Receptacle FSM


    Substate issuing can

    Source: B. P. Douglass & iLogix

    Substate: Issuing Can


    Class button fsm

    Source: B. P. Douglass & iLogix

    Class Button FSM


    Concurrent statecharts

    Source: B. P. Douglass & iLogix

    Concurrent Statecharts

    • Many embedded systems consist of multiple threads, each running an FSM

    • State charts allow the modeling of these parallel threads


    Concurrent statecharts1

    Source: B. P. Douglass & iLogix

    Concurrent Statecharts

    • States S and T are active at the same time as long as X is active

      • Either S.A or S.B must be active when S is active

      • Either T.C, T.D or T.E must be active when T is active


    Concurrent statecharts2

    Source: B. P. Douglass & iLogix

    Concurrent Statecharts

    • When X exits, both S and T exit

      • If S exits first, the FSM containing X must wait until T exits

      • If the two FSMs are always independent, then they must be enclosed at the highest scope


    Explicit synchronization

    Source: B. P. Douglass & iLogix

    Explicit Synchronization


    Example concurrent fsm

    Source: B. P. Douglass & iLogix

    Example Concurrent FSM


    Communication in concurrent fsms

    Communication in Concurrent FSMs

    • Broadcast events

      • Events are received by more than one concurrent FSM

      • Results in transitions of the same name in different FSM

    • Propagated transitions

      • Transitions which are generated as a result of transitions in other FSMs


    Propagations and broadcasts

    Source: B. P. Douglass & iLogix

    Propagations and Broadcasts


    Graphical hierarchical fsm languages

    Graphical Hierarchical FSM Languages

    • Several commercial & non-commercial variants

      • StateCharts, VisualHDL, SpecCharts, SpeedChart, StateVision, etc.

  • Easy to use in control dominated systems

  • Simulation, S/W and H/W synthesis

  • Extended with arithmetic


  • Raphsody statemate etc by i logix

    Raphsody, StateMate etc.by i-Logix

    • Set of tools for development of complex reactive systems

      • heavy graphical orientation

      • captures system behavior using StateCharts

      • rigorous executions and simulations

      • create run-time code for rapid-prototyping

  • Key features:

    • executable and analyzable specifications

    • visual formalisms


  • Co design finite state machines cfsms

    Co-design Finite State Machines (CFSMs)

    • Underlying model of computation for Berkeley’s POLIS system for H/W-S/W synthesis

    • Combines aspects of several other models

      • FSM extended with support for data handling and asynchronous communications

        • FSM part: I/O, states, transition & output relation

        • Data computation part: external, instantaneous functions without side effects

  • Mixes

    • synchronicity: zero & infinite delay

    • Asynchronicity: non-zero, finite, & bounded delay

  • Embedded systems have both aspects


  • Network of cfsms

    Network of CFSMs

    • Interacting CFSMs that communicate through a very low-level primitive: events

    • Broadcast communication model

      • a CFSM, or its environment, emits events

      • one or more CFSMs or the environment can later detect it

  • GALS: globally asynchronous, locally synchronous

    • contrast: in concurrent FSMs, all FSMs change states exactly at the same time

      • does not work in S/W with interleaved FSMs


  • Communication primitives

    Communication Primitives

    • Events implement a communication protocol that does not require acknowledgment

      • receiver waits for sender to emit event

      • sender can proceed immediately after emission

      • implicit one-place buffer between the sender and receiver saves the event until it is detected or overwritten

        • efficient H/W implementation with synchronous circuits, and S/W implementation using polling or interrupts

  • Handshake, if needed, modeled using events


  • More on events

    More on Events

    • Sender does not remove the event immediately after sending it, only when emitting the next one

    • Each CFSM can detect an event at most once any time after the event’s emission, until another event of the same type overwrites it

      • event can be correctly received even with the unpredictable reaction time associated with S/W implementations

      • correct reception is ensured as long as

        • sender date rate < receiver processing ability

        • or, explicit synchronization is done


    Generalization to signals

    Generalization to Signals

    • Signals carry information in the form of events and/or values

      • Event signals: present/absent

      • Data signals: arbitrary values

        • event, data may be paired

  • 1 input buffer / signal /receiver

  • Signal is emitted by sender (by setting buffer)

  • Consumed by receiver (by resetting buffer)

  • “Present” if emitted but not consumed


  • Example cfsm specification

    Example CFSM Specification

    Wait

    • State of a CFSM includes those events that are at the same time input and output for it

      • non-zero reaction time implies storage capability

    *Key = On  *Start

    *End=5  *Alarm = On

    *Key = Off or

    *Belt = On 

    Off

    Alarm

    *End=10 or

    *Belt = On or

    *Key = Off 

    *Alarm = Off


    Discrete events

    Discrete Events

    • Notion of time is fundamental

    • Events are objects which [usually] carry ordered time information

    • There is a casual relationship between events

    • Verilog and VHDL

    • Expensive - ordering tame stamps can be time consuming

    • Large state & Low Activity => Effective simulation

    • Simultaneous Events require complete conflict resolution schemes


    Modeling of embedded system behavior

    Simultaneous Events in the Discrete Event Model

    t

    A

    B

    C

    t

    t

    A

    B

    C

    t


    Reactive synchronous models

    Reactive Synchronous Models

    • Assumptions

      • system reacts to internal and external events by emitting other events

      • events can only occur at discrete time steps

      • reactions are assumed to be instantaneous

        • negligible or relatively small time to process event

        • if processing is significant, start and end events can be associated with the tasks

  • Synchronous languages

    • Imperative: Estrel

    • Dataflow: Lustre, Signal, Argos

  • Simple and clean semantics (FSM based), deterministic behavior, and lots of CAD tools


  • Esterel

    Esterel

    • Describes collection of FSMs

    • Imperative syntax

      • S1;S2 executes in sequence

      • S1 || S2 in parallel

      • [S1||S2] in parallel until both terminate

  • Succinct specification of interrupts

    • do <body> watching <event>

      • the <body> is executed until either it terminates, or the <event> occurs

  • As the number of signals to watch increases, the size of the Esterel program grows linearly, while the FSM complexity grows exponentially


  • Esterel example

    Esterel Example

    module EsterelFSMinput A, B, R;output O;loopdo[await A ||await B];emit O;halt;watching Rend loop

    end module;


    Flow graph models

    Flow Graph Models

    Control/Data

    Flow Graph

    Implementation

    2

    3

    2

    ...

    2

    1

    1

    ...

    Reg

    Reg

    Multiplier

    x

    4

    3

    2

    ...

    D

    +

    Reg

    Reg

    4

    7

    9

    ...

    Adder

    0

    4

    7

    ...


    Synchronous data flow

    Synchronous Data Flow

    +

    -

    x

    x

    +

    -

    D

    D

    +

    -

    x

    x

    x

    x

    +

    -

    x

    x


    What latency sample period can a sdfg achieve

    What Latency & Sample Period can a SDFG achieve?

    x

    y

    +

    +

    • TL = max(I-O path, D-O path)

    • TS = max(D-D path, I-D path)

    D1

    Longest Path for T

    L

    T

    = 2m + 3

    L

    +

    +

    D2

    Longest Path for T

    S

    T

    = m + 2

    S


    Cdfg can be transformed to affect t l t s

    CDFG can be Transformed to Affect TL & TS

    Longest Path for T

    L

    T

    = m + 2

    L

    x

    y

    +

    +

    S1

    S3

    +

    +

    Longest Path for T

    S

    S2

    S4

    T

    = m + 2

    S


    Dataflow process networks

    Dataflow Process Networks

    • Graph: Nodes (actors) are computations, edges (arcs) are ordered sequences of events (tokens)

    • Kahn process network is generalization where unbounded FIFO buffering is available

    • Firing - quant of computation

    • Karp-Miller computation graphs, Lee-Messerschmidt's synchronous SDF, ...


    Modeling of embedded system behavior

    Dataflow Process Networks

    A

    C

    D

    B


    Modeling in hardware asic design

    Modeling in Hardware (ASIC) Design

    Algorithm

    C/C++/Matlab/Java etc.

    Gap ???

    RTL

    Verilog, VHDL

    RTL synthesis

    netlist

    Verilog, Edif

    layout

    Physical

    GDS-II


    Cost of the disconnect between system hardware design

    Cost of the Disconnect between System & Hardware Design

    • Tools

      • Separate suite of tools in both environments

    • Knowledge

      • Lose information when starting over in HDL

    • Design Time

      • Starting from scratch (e.g. VHDL or Verilog) and hope that it produces the same behaviour as the original architecture model

      • Separate testbenches/verification efforts


    Solution approaches

    Solution Approaches

    • Approach #1: do hardware RTL design in the same languages as system design (C/C++/Java)

      • Over 50% of today’s designs begin with architecture modeling in C/C++

      • Iteratively refine to RTL C/C++

      • Synthesize RTL C/C++ to Verilog/VHDL

      • System-C, Cynapps etc.

    • Approach #2: use formal languages for system modeling (SDL, UML etc.), and synthesize VHDL/Verilog RTL design via behavioral synthesis

    • Comment: VHDL (unlike Verilog) can model at higher levels than RTL, but the computation model is too rich for synthesis tools to handle


    Emerging c c based unified design environments

    Emerging C/C++-based Unified Design Environments

    • The hope is that they will allow

      • System/Algorithm Modelling

      • Software Design

      • Hardware Design

        …to be done in the same language


    Example cynapps s c cynlib

    Example: CynApps’s C++/Cynlib

    • http://www.cynapps.com

    • Open source C++ library (Cynlib) for RTL modeling and simulation

    • Tools are not free


    Goto cynapps slides

    Goto CynApps Slides!


    Modeling approaches based on software design methods

    Modeling Approaches based on Software Design Methods

    • No systematic design in 60s

    • From 70s, many different s/w design strategies

      • Design methods based on functional decomposition

        • Real-Time Structured Analysis and Design (RTSAD)

    • Design methods based on concurrent task structuring

      • Design Approach for Real-Time Systems (DARTS)

  • Design methods based on information hiding

    • Object-Oriented Design method (OOD)

  • Design methods based on modeling the domain

    • Jackson System Development method (JSD)

    • Object-Oriented Design method (OOD)


  • Object oriented design methods

    Object-Oriented Design Methods

    • Based on three essential concepts

      • abstraction

        • separate specification from internal body

    • information hiding

      • structuring to decide what information is hidden

  • inheritance

    • relationship among classes where a child class can share the structure and operations of a parent class and adapt it for its own use


  • Object oriented modeling languages uml

    Object-Oriented Modeling Languages: UML

    • What is UML?

      “a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems”

      -- Object Management Group, Inc. (OMG)

    • In Essence:a tool used through the analysis and design phases of system development for expressing the constructs and relationships of complex systems


    Uml goals

    UML Goals

    1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models

    2. Provide extensibility and specialization mechanisms to extend the core concepts.

    3. Be independent of particular programming languages and development processes.

    4. Provide a formal basis for understanding the modeling language.

    5. Encourage the growth of the Object-Oriented tools market.

    6. Support higher-level development concepts such as collaborations, frameworks, patterns and components.

    7. Integrate best practices.


    History origins

    History & Origins

    • Mid 1970s -1980s: Object-Oriented methodology and modeling languages

    • Mid 1990s: 2nd Generation - Booch method, Object Modeling Technique (OMT), Object-Oriented Software Engineering(OOSE)

    • 1994-95: Grady Booch, Jim Rumbaugh, Ivan Jacobson join forces to unify methods

    • OMG push for standardization

    • January 1997: UML 1.0 Definition


    Languages for modeling

    Languages for Modeling

    • Languages have long been used for modeling hardware

      • VHDL, Verilog

  • Also, in specific domains

    • SDL in telecommunication systems

  • UML achieves that for software-oriented complex system modeling


  • Language based hardware design

    Language-based Hardware Design

    • Language-level “model” of hardware

      • create a functional fascimile of the target circuit

      • models can be simulated, analyzed, synthesized.

  • Language-level “design” of hardware

    • create a functional implementation of the target circuit

      • translation of functional implementation into a gate-level circuit is well defined.

  • HDL thesis:

    • (Relevant) executable models can be refined into a gate-level implementation under designer control

    • structured as data and control refinement.


  • Why uml and why oo for real time embedded systems

    Why UML (and Why OO) for Real-time Embedded Systems?

    • UML is application independent

    • Correspondence between analysis and design views

    • Improved stability in the presence of changes

    • Easier reuse

    • Improved scalability - less coupling

    • Better support for reliability + safety concerns

    • Inherent support for concurrency - objects


    Major features of uml

    Major Features of UML

    • Object model

    • Use cases and scenarios

    • Behavioral modeling with statecharts

    • Packaging of various kinds of entities

    • Representation of tasking and task synchronization

    • Models of physical topology

    • Models of source code organization

    • Support for object-oriented patterns


    Visual modeling in uml set of diagrams

    Visual Modeling in UML: Set of Diagrams

    • Context diagram

      • an UML object diagram

  • Use Case diagram

  • Scenarios

    • Sequence Diagram, Collaboration Diagram

  • Class diagram

  • Message Trace

  • Behavior Modeling

  • Models of Architecture and Patterns

    How do these model aspects ofReal-Time Systems?


  • Requirements analysis context diagrams

    Requirements Analysis: Context Diagrams

    Arrhythmia

    Alarm

    • System interaction with objects in the external environment

    • Messages

      • data content, arrival patterns, synchronization patterns

  • External event list

  • Physician

    EKG

    Monitor

    Heart Activity

    Remote

    Display

    Patient


    Use cases

    Use Cases

    • General cases of interaction among the system and external objects

      • provide another view of system context

  • Functional decomposition of system’s behavior without regard to the system’s internal structure

  • Describe the behavior of a set of objects

  • Group functionally related messages together into protocols

  • Protocols - obligations between objects


  • Use cases contd

    Use Cases (contd.)

    Use Case 1

    Actor 1

    Use Case 2

    Actor 4

    Use Case 3

    Actor 2

    Use Case 4

    Actor 3


    Scenarios or interaction diagram

    Scenarios or Interaction Diagram

    • Instances of use cases

    • Model order-dependent message sequences among objects collaborating to produce system behavior

    • Different scenarios for a use case show permutations of object interactions

    • Annotated with timing constraints

    • Two scenario models

      • sequence diagrams

      • collaboration diagrams


    Sequence diagram vs collaboration diagram

    Sequence Diagram vs. Collaboration Diagram

    • Sequence Diagram

      • shows the interactions or exchanged messages among objects

      • does not show any associations among the objects

      • the interactions are arranged in a time/life-line scale to show their progression over time

      • enhancements: “state marks” to allow following the state changes, “time marks”, broadcast messages

  • Collaboration Diagram

    • focuses on the interactions or messages among objects

    • each interaction carryies a sequence number to display its role in an ordered flow of operations


  • Sequence diagram example

    Sequence Diagram Example


    Collaboration diagram example

    Collaboration Diagram Example


    Analysis defining the object structure

    Analysis: Defining the Object Structure

    • After system’s external environment is defined

    • Identification of key objects and classes, and their relationships within the system

      • identify objects

      • identify object associations

      • group objects into classes

      • identify and classify class relationships

      • identify class behaviors

      • group classes into domains

      • validate classes and objects


    Class diagrams

    Class Diagrams

    Class Name

    Attributes

    • Relationships Between Classes

      • Associations

      • Aggregation

      • Composition

      • Generalization (Template)

      • Refinement

    Operations

    Class

    Class inside


    Class diagrams1

    Class Diagrams


    Analysis defining the object behavior

    Analysis: Defining the Object Behavior

    • Define and refine operations and behaviors

    • Three ways of behavior modeling

      • simple behavior

        • no memory e.g. pure mathematical functions

    • state or reactive behavior

      • e.g. FSM, StateChart

  • continuous behavior

    • e.,g. digital filters

  • Scenario modeling to test behavioral models

  • State and scenario models lead to definitions of class models


  • Modeling architecture

    Modeling Architecture

    Node

    Name

    • physical architecture

    • mapping to physical devices

    • task diagrams - show concurrency

    • node - processor, sensors, routers, displays, input devices, memory, etc.

    Subsystem

    Package

    Subsystem

    and Package

    Package

    Active

    Object

    Task


    Modeling architecture contd

    Modeling Architecture (contd.)


    Architectural patterns

    Architectural Patterns

    Master-Slave

    Pattern

    Master

    Slave

    Coprocessor

    Controller

    + Sequence Diagram


    Uml for real time

    UML for Real-Time

    • Uses standard UML and Real-Time Object-Oriented Modeling Language (ROOM)

    • Principal Constructs: Capsules; Ports; Protocols

    • Capsules - objects that interact with surroundings

    • Ports - interface object; physical part of implementation of a capsule; implements behavior defined by protocols

    • Relay Ports - connected to sub-capsules; let all signals pass through


    Uml for real time contd

    UML for Real-Time (contd.)

    • End Ports - connected to the capsule’s state machine; where connectors terminate and communicate with state machine

    • Protocols - rules, formats, and procedures agreed upon by object wanting to communicate

    • Connectors - abstract views of signal-based communication channels ; modeled by associations


    Modeling the engineering infrastructure in uml

    Modeling the Engineering Infrastructure in UML

    • Resources can be modeled by appropriate stereotypes of Class and Node

    • Resources “support” logical elements

      • A logical element may require multiple rsources

  • Resources can be viewed as servers with service interfaces

    • operations of QoS (quality of service) attributes with numerical values e.g. latency, energy

  • Similar approach for OS services

  • Element-to-resource mapping

    • relate logical model to a particular hardware configuration

  • Resource-to-value mapping

    • Attribute values for resources of an implementation machine


  • References for uml

    References for UML

    • Bruce Douglass, “Real-Time UML - Developing Efficient Objects for Embeded Systems,” Addison-Wesley, 1998.

    • http://www.rational.com/

    • Bran Selic & Jim Rumbaugh,“Using UML for Modeling Complex Real-Time Systems,” 1998. http://www.rational.com/support/techpapers/umlrt/

    • Andrew Lyons, “UML for Real-Time Overview,” 1998. http://www.rational.com/support/techpapers/umlrt_overview

    • Grady Booch, “Quality Software and the Unified Modeling Language.” http://www.rational.com/support/techpapers/soft_uml.html

    • http://www.omg.org/news/pr97/umlprimer.html

    • http://spider.ipac.altech.edu/~brundage/presents/uml/index.html

    • http://www.jr-and-assoc.demon.co.uk/uml_int.htm


    How models influence an application design

    How Models Influence an Application Design?

    • Example: given input from a camera, digitally encode it using MPEG II encoding standards.

      • this task involves: storing the image for processing going through a number of processing steps, e.g., Discrete cosine transform (DCT), Quantization, encoding (variable length encoding), formatting the bit stream, Inverse Discrete Cosine transform (IDCT), ...

  • Is this problem appropriate for

    • Reactive Systems, Synchronous Data flow, CSP, ...

  • More than one model be reasonable.


  • Choice of model

    Choice of Model

    • Model Choice: depends on

      • application domain

        • DSP applications use data flow models

        • Control applications use finite state machine models

        • Event driven applications use reactive models

    • efficiency of the model

      • in terms of simulation time

      • in terms of synthesized circuit/code.

  • Language Choice: depends on

    • underlying semantics

      • semantics in the model appropriate for the application.

  • available tools

  • personal taste and/or company policy


  • Login