1 / 62

Hoofdstuk 2 Systeemspecificatietechnieken 2.2 Specificatietalen

Hoofdstuk 2 Systeemspecificatietechnieken 2.2 Specificatietalen. Prof. dr. ir. Dirk Stroobandt Academiejaar 2004-2005 De transparanten van hoofdstuk 2 werden overgenomen van Prof. Peter Marwedel (Universiteit Dortmund) en waar nodig bijgewerkt. Inhoud (deel 1).

donat
Download Presentation

Hoofdstuk 2 Systeemspecificatietechnieken 2.2 Specificatietalen

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hoofdstuk 2Systeemspecificatietechnieken2.2 Specificatietalen Prof. dr. ir. Dirk Stroobandt Academiejaar 2004-2005 De transparanten van hoofdstuk 2 werden overgenomen van Prof. Peter Marwedel (Universiteit Dortmund) en waar nodig bijgewerkt.

  2. Inhoud (deel 1) • Inleiding over Ingebedde systemen, System-on-Chip en Platform-gebaseerd ontwerp • Systeemspecificatietechnieken • Functionele specificaties • Specificatietalen • Eigenschappen • SDL • Petri nets • Exploratie van de ontwerpruimte

  3. Virtual Prototype HW Prototype Executable Homogeneous Specification CODESIGN SW Types of language specifications • Homogeneous modeling Correspondence between concepts of specs and VP Non-trivial

  4. HW model CODESIGN Prototype Heterogeneous Specification SW model Types of language specifications (2) • Heterogeneous modeling Multilanguage specification. Codesign is simple mapping of HW and SW models on parts. Validation and interfacing is key. Burden mainly on designer.

  5. Some general properties of languages1. Synchronous vs. asynchronous languages • Description of several processes in many languages non-deterministic:The order in which executable tasks are executed is not specified (may affect result). • Synchronous languages: based on automata models. • Synchronous languages describe concurrently operating automata. • „.. when automata are composed in parallel, a transition of the product is made of the "simultaneous" transitions of all of them“.

  6. Some general properties of languages1. Synchronous vs. asynchronous languages • Synchronous languages implicitly assume the presence of a (global) clock. Each clock tick, all inputs are considered, new outputs and states are calculated and then the transitions are made. • This requires a broadcast mechanism for all parts of the model. • Idealistic view of concurrency. • Has the advantage of guaranteeing deterministic behavior. •  StateCharts is a synchronous language.

  7. Some general properties of languages2. Properties of processes • Number of processesstatic;dynamic (dynamically changed hardware architecture?) • Nested declaration of processesor all declared at the same level • Different techniques for process creationElaboration in the source code,explicit fork and join,process creation calls •  StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source code.

  8. Some general properties of languages3. Communication paradigms • Message passing • Non-blocking communicationSender does not have to wait until message has arrived; potential problem: buffer overflow • Blocking communication, rendez-vous-based communicationSender will wait until receiver has received message • Extended rendez-vousExplicit acknowledge from receiver required. Receiver can do checking before sending acknowledgement.

  9. Some general properties of languages3. Communication paradigms • Shared memoryVariables accessible to several tasks • Critical sections = sections at which exclusive access to some resource r must be guaranteed.  StateCharts uses shared memory for communication between processes.

  10. Some general properties of languages 4. Specifying timing • 4 types of timing specs required [Burns, 1990]: • Measure elapsed timeCheck, how much time has elapsed since last call • Means for delaying processes • Possibility to specify timeoutsWe would like to be in a certain state only a certain maximum amount of time. • Methods for specifying deadlinesWith current languages not available or specified in separate control file.  StateCharts comprises a mechanism for specifying timeouts. Other types of timing specs are not supported.

  11. Properties of specification languages5. Using non-standard I/O devices - • Direct access to switches, displays etc; • No protection required; OS can be much faster than for operating system with protection. •  No support in standard StateCharts. •  No particular OS support anyhow.

  12. Classification of languages • Computation models of specification languages.

  13. Synthesis intermediate forms • Internal representation to go from spec to architecture. • Generally only one intermediate form is used. System Level Specification Language Oriented Model Architecture Architecture Oriented Model Language Oriented Refinements Architecture Oriented Refinements Graph models FSM models

  14. a c b d + - v1 v2 * v3 e Language oriented intermediate forms • Data Flow Graph (DFG) • Nodes represent operators • Edges represent values • Control Flow Graph (CFG) • Loops, global exceptions, synchronization, proc. calls • Nodes represent operations • Edges represent sequencing relations • Control Data Flow Graph (CDFG) • Extends DFG with control nodes (if, case, loops)

  15. CONTROLE/DATAFLOWGRAAFeen neutrale representatie • Graaf bestaande uit 2 soorten knopen: operatorknopen: operaties + fan-out naar alle opvolgers selectieknopen: selectie van één voorganger of opvolger (merge, join, entry, exit) • Takken geven precedenties weer + eventueel data flow • CDFG bevat de hele semantiek van algoritme en bevat tevens meer potentieel voor parallellisme

  16. CONTROLE/DATAFLOWGRAAFvoorbeelden van syntaxis • IF-statement • -- oude waarden van x,y,... • if cond(x,y,..) • then block1(x,y,..) • else block2(x,y,..) • endif • -- nieuwe waarden van x,y,...

  17. CONTROLE/DATAFLOWGRAAFvoorbeelden van syntaxis • Iteratie • -- oude waarden van x,y, ... • loop • block1(x,y,...) • if cond(x,y,...) then • exit • block2(x,y,...) • endloop • -- nieuwe waarden van x,y, ...

  18. Cij/Aij Si Sj Cji/Aji Architecture oriented intermediate forms • FSM with Data path model (FSMD) • FSM extended with operations on data • Internal variables and transitions may include operations on variables Cij: A <= 0; Cji: A > 0; Aij: X := A + Y; Output <= ‘1’; Aji: X := A - Y; Output <= ‘0’;

  19. Data path Top Controller Storage Units Calculation Units Co-processor 1 Co-processor 2 Architecture oriented intermediate forms • FSM with Coprocessors (FSMC) • FSMD with operations executed on coprocessors • FSMD + N coprocessors C (each defined by FSMC)

  20. Inhoud (deel 1) • Inleiding over Ingebedde systemen, System-on-Chip en Platform-gebaseerd ontwerp • Systeemspecificatietechnieken • Functionele specificaties • Specificatietalen • Eigenschappen • SDL • Petri nets • Exploratie van de ontwerpruimte

  21. SDL • Language designed for specification of distributed systems. • Dates back to early 70s, • Formal semantics defined in the late 80s, • Defined by ITU (International Telecommunication Union): Z.100 recommendation in 1980Updates in 1984, 1988, 1992, 1996 and 1999

  22. SDL • Provides textual and graphical formats to please all users, • Just like StateCharts, it is based on the CFSM model of computation; each FSM is called a process, • However, it uses message passing instead of shared memory for communications, • SDL supports operations on data.

  23. SDL-representation of FSMs/processes state input output

  24. Operations on data • Variables can be declared locally for processes. • Their type can be predefined or defined in SDL itself. • SDL supports abstract data types (ADTs). Examples:

  25. Communication among SDL-FSMs • Communication between FSMs (or „processes“) is based on message-passing, assuming a potentially indefinitely large FIFO-queue. • Each process fetches next entry from FIFO, • checks if input enables transition, • if yes: transition takes place, • if no: input is ignored (exception: SAVE-mechanism).

  26. Process interaction diagrams • Interaction between processes can be described in process interaction diagrams (special case of block diagrams). • In addition to processes, these diagrams contain channels and declarations of local signals. • Example: ,

  27. Counter TO OFFSPRING CounterVia Sw1 Designation of recipients • Through process identifiers:Example: OFFSPRING represents identifiers of processes generated dynamically. • Explicitly:By including the channel name. • Implicitly:If signal names imply channel names (B  Sw1)

  28. Hierarchy in SDL • Process interaction diagrams can be included in blocks. The root block is called system. Processes cannot contain other processes, unlike in StateCharts.

  29. Timers • Timers can be declared locally. Elapsed timers put signal into queue (not necessarily processed immediately). • RESET also removes timer signal from queue.

  30. Additional language elements • SDL includes a number of additional language elements,like • procedures • creation and termination of processes • advanced description of data

  31. Larger example: vending machine Machine° selling pretzels, (potato) chips, cookies, and doughnuts: accepts nickels, dime, quarters, and half-dollar coins. Not a distributed application. ° [J.M. Bergé, O. Levia, J. Roullard: High-Level System Modeling, Kluwer Academic Publishers, 1995]

  32. Overall view of vending machine

  33. p DecodeRequests

  34. ChipHandler

  35. Versions and tools • SDL-88 • SDL-92: object orientation added • SDL-96 • SDL-2000: Extended graphical support;processes and blocks becoming replaced by agents. • Tools for connecting to MSCs (see below) • Tools for connecting to UML (see below) • Tools for translation to CHILL. • Information: www.sdl-forum.org

  36. Evaluation • Excellent for distributed applications(was used to specify ISDN), • Commercial tools available from SINTEF, Telelogic, Cinderella (http://www.cinderella.dk). • Not necessarily deterministic(order in which FSMs are reading input is unknown) no synchronous language, • Implementation requires bound for the maximum length of FIFOs; may be very difficult to compute, • Timer concept adequate just for soft deadlines, • Limited way of using hierarchies, • Limited programming language support, • No description of non-functional properties.

  37. Inhoud (deel 1) • Inleiding over Ingebedde systemen, System-on-Chip en Platform-gebaseerd ontwerp • Systeemspecificatietechnieken • Functionele specificaties • Specificatietalen • Eigenschappen • SDL • Petri nets • Exploratie van de ontwerpruimte

  38. Petri nets • Introduced in 1962 by Carl Adam Petri in his PhD thesis. • Focus on modeling causal dependencies; • No global synchronization assumed (message passing only). • Key elements: • ConditionsEither met or no met. • EventsMay take place if certain conditions are met. • Flow relationRelates conditions and events. • Conditions, events and the flow relation form • a bipartite graph (graph with two kinds of nodes).

  39. Example: Synchronization at single track rail segment • „Preconditions“

  40. Playing the „token game“

  41. Conflict for resource „track“

  42. s More complex example • Thalys trains between Cologne, Amsterdam, Brussels and Paris. • Synchronization at Brussels and Paris

  43. Condition/event nets • Def.:N=(C,E,F) is called a net, iff the following holds • C and E are disjoint sets • F (C  E)(E  C); is binary relation, („flow relation“) • Def.: Let N be a net and let x  (CE).x := {y | y F x} is called the set of preconditions.x := {y | x F y} is called the set of postconditions. • Example: x x x

  44. Loops and pure nets • Def.: Let (c,e) CE. (c,e) is called a loop iffcFe eFc. Def.: NetN=(C,E,F) is called pure, if F does not contain any loops.

  45. Simple nets • Def.: A net is called simple, if disjoint elements have disjoint pre- and postcondition sets. • Example (not a simple net): Def.: Simple nets with no isolated elements meeting some additional restrictions are called condition/event nets (C/E nets).

  46. Place/transition nets • Def.: (P, T, F, K, W, M0) is called a place/transition net iff • N=(P,T,F) is a net with places p  P and transitions t  T • K: P (N0 {}) \{0} denotes the capacity of places( symbolizes infinite capacity) • W: F(N0 \{0}) denotes the weight of graph edges • M0: PN0{} represents the initial marking of places W (Segment of some net) M0 defaults:K = W = 1

  47. Computing changes of markings • „Firing“ transitions t generate new markings on each of the places p according to the following rules:

  48. Activated transitions • Transition t is „activated“ iff Activated transitions can „take place“ or „fire“,but don‘t have to.We never talk about „time“ in the context of Petri nets. The order in which activated transitions fire, is not fixed(it is non-deterministic).

  49. p  P: M´(p) = M(p)+ t(p) Shorthand for changes of markings Slide 48: Let  M´ = M+ t +: vector add

  50. Matrix N describing all changes of markings Def.: Matrix Nof net N is a mappingN: PT Z (integers)such that t T: N(p,t)=t(p) Component in column t and row p indicates the change of the marking of place p if transition t takes place.

More Related