1 / 31

An SDL Tutorial

An SDL Tutorial. Two primary elements: Structure Identifies the various components of the system, and the communication paths among them. Components : Blocks, Processes Communication paths : Channels, Signal routes …and where they connect: Gates Structural elements may be types

keola
Download Presentation

An SDL Tutorial

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. An SDL Tutorial • Two primary elements: • Structure • Identifies the various components of the system, and the communication paths among them. • Components: Blocks, Processes • Communication paths: Channels, Signal routes • …and where they connect: Gates • Structural elements may be types • Behaviour • Only processes have behaviour • Based on an extended finite state machine

  2. High level structure 1(2) system name page number (total pages) System SDLexample [m2] Block_1 channelname toEnv2 toEnv1 [m3] [m1] Block_2 path block signals permitted on this channel [m4] block name channel environment

  3. Declarations 2(2) System SDLexample SIGNAL m1, m2, m3(INTEGER), m4, m5; Declaration of 5 signals with indicated names parameter for signal end of declaration list

  4. Inside a Block block name declaration local to block Block Block_1 sr1 SIGNAL m5; Process_1 sr3 [m1] [m4] sr2 Process_2 signal route [m5] process name signal route name process

  5. Processes • Unless otherwise specified, one instance of a process is started at system initialization, and it will continue to run until it decides to terminate itself. • Processes can be created dynamically: maximum numberof instances P(1,3) P(0, ) unlimitednumber ofinstances number of instances at system initialization

  6. Process Identification • Each process instance is assigned a unique “process identifier”, or PID. • Can be used to identify other processes • A PID has its own special type • The set of values for PIDs is not defined by the language; it is left for tool implementation • This means that you cannot assume any values for a PID; they are assigned automatically

  7. Block Types System SDLexample2 [m1] Block_3: aType toEnv2 toEnv1 g2 [m1] g1 g2 Block_4:aType typeofinstance path g1 gatereferences [m4] [m4] aType block instances block type

  8. Inside a Block Type block type name gate name Block Type aType g1 gate g1 [m4] sr4 [m4] [m4] Process_3 sr6 g2 g2 [m1] [m4] sr5 [m1] Process_4 gatereference [m5] signals permittedthrough gate

  9. Process Types • Uses gates in the same manner as block types P_type Symbol: P1: P_type Instance:

  10. Signal List System SDLexample3 SIGNAL m1, m2, m3(INTEGER), m4; SIGNALLIST list1 m1, m2, m3, m4; signal list name Block_b use ofsignallist [(list1)]

  11. Other notes • Blocks may contain (sub-)blocks as well as processes (but not on the same page, in older versions of SDL) • Declarations: signals, signal lists, etc. can be at any level • Scope: all contained items know about the declared items, and recognize the names • Good practice: declare items at inner-most level that is possible • Names are required to be unique only to their construct • You can have a process named ‘X’ contained within a block also named ‘X’, since they are different constructs. • Signal lists can be used anywhere that a signal would appear on a structural diagram • Their use is highly recommended

  12. Behaviour • Only applies to processes • Based on extended finite state machines • Model: • Each process has a single input queue of finite length from which it may receive signals • Signals from different sources are appended to the queue as they arrive • To move from one state to another, if the signal at the head of the queue matches the input for a transition, the signal is removed from the queue, and the transition runs to completion.

  13. SDL Behaviour Process p1 start state state1 state input m4 m2 state1 m5 m4 output state3 state2 next state

  14. Variables • Commas separate declarations, semi-colon terminates list • Other variable types possible name ofvariable DCL v1 INTEGER, v2 PID, v3 BIT, v4 OCTET, v5 DURATION; process identifier 0 or 1 eight bits used by timers

  15. Special PID variables • Each input signal automatically carries the PID of its sending process • When an input signal is received, the value of SENDER (a pre-defined variable) is set to this PID. • Other PID pre-defined variables: • SELF: our own PID • PARENT: the PID of the process that created a process • OFFSPRING: the PID of the process most recently created from a process

  16. Guard Conditions state1 DCL x INTEGER; m1 x < 0 guardcondition x = 5 m4 m3 transition taken if input received and condition is true state3 state2 transition taken if no matchinginput received and condition is true

  17. Decisions • Two forms: • First: True and false branches based on logical condition • Second: Switch-like statement • Any logical operator can be used: <, <=, >, >=, =, /= variable logical condition true x = 3 x false = 1 =2 else conditions not-equal

  18. Timers • Actions with timers: • SET: Start a timer for a specified duration • Time units are “unspecified” by the language • Tau tool default: milliseconds • RESET: Cancel an unexpired timer • (EXPIRY): Notification that the duration has elapsed • Results in a “signal” with the same name as the timer being put into the input queue for the process. • Design guideline: • Always cancel unexpired timers

  19. Timers set(now+5.0,t1) Starts timer t1 Will expire 5.0 “time units” from now state1 TIMER t1; t1 m2 timer declaration reset(t1) t1 expiry message cancellation of timer

  20. Other transition elements x := 0 task: used for variable assignments Prcd_name procedure call process termination Prcs_name create a new process instance

  21. Other symbols comment (can be attached anywhere) “extender”: used to add additional text that doesn’t fit inside a symbol x := really_long_variable_name x := really_long_variable_name

  22. Save • If signal m2 is at the head of the input queue in state state1, it is kept in order in the input queue, and the next signal in the queue is examined. • No transition after a save, and state is unchanged. • Used to defer processing of a signal (to another state) • Example: If signal m2 is at the head of the input queue, and signal m1 is second, the signal m2 is “saved” for a future transition. Signal m1 would then be processed in state1. state1 m1 m2

  23. Notes on Signal I/O (1) • Suppose that a process can send signals a, b, and receive signals b, c • Signal a must be defined on an outgoing signal route from the process • Signal c must be defined on an incoming signal route to the process • By default, when the process sends signal b, it will be placed in its own input queue • WARNING: This will happen even if b is also defined on an outgoing signal route.

  24. Notes on Signal I/O (2) • Signal output options: • signal is sent along the specified signal route • signal is sent to the specified process • While these options are defined by the language, tools have difficulties with their implementation m3 VIA signal_route_name m3 TO process_id

  25. Procedure Calls • SDL uses procedures instead of functions, and an older (1970s !) style of parameter passing. A_Proc (a, b, c) Procedure call A_proc (d, e, f) Procedure definition

  26. Procedures vs. Functions • A function has 0 to n parameters, and a separate return value. All parameters are usually passed by value and are intended as input values to the function. The return value is passed using a “return” statement.

  27. Procedures vs. Functions • A procedure has 0 to n parameters, but NO return value. • Do not assign a “result” from a procedure call. • However, each parameter can independently be of two sorts: • IN: similar to a function parameter. Intended for input values. • IN/OUT: The parameter value is passed in from the caller at the start of the procedure, and passed back (out) to the caller at the end of the procedure. • Used to return values • Will modify caller’s original value • Caller must supply a variable, not a constant. • If variable is “output only”, caller can supply a variable that has not yet received a value.

  28. Sample Procedure Definition procedure name procedure parameters area Procedure A_Proc ; FPAR IN/OUT d BIT, IN e BIT, IN/OUT f OCTET state1 m4 m2 procedure starts here m5 m4 state2 state1 return to caller

  29. Syntax notes: Note semicolon before FPAR keyword Comma separates parameter declarations Semicolon terminates parameter list. Procedure Parameters ; FPAR IN/OUT d BIT, IN e BIT, IN/OUT f OCTET Formal parameters keyword Parameter type Parameter name Whether or not parameter value is passed in only, or in and out.

  30. Services • Services are used to further partition a process into sub-structures. • Services can be used to separate functionality that is independent within a process, and will handle separate signals. • Example: • Send service and Receive service within a process to implement • Each service has its own behaviour description, similar to a process.

  31. Service structure 1(1) Process Send_and_Receive [m1] [m2] Receive Send [m4] [m3]

More Related