An SDL Tutorial

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
process
signal route name
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_4aType
typeofinstance
path
g1
gatereferences
m4
m4
aType
block instances
block type
8
Inside a Block Type
block type name
gate name
Block Type aType
gate
g1
g1
m4
sr4
m4
m4
Process_3
sr6
g2
g2
m1
m4
sr5
m1
Process_4
gatereference
m5
signals permittedthrough gate
9
Process Types
P_type
Symbol

• Uses gates in the same manner as block types

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
m2
m4
state1
m5
m4
output
state2
state3
next state
14
Variables
name ofvariable
DCL v1 INTEGER, v2 PID, v3 BIT, v4
OCTET, v5 DURATION
process identifier
0 or 1
eight bits
used by timers

• Commas separate declarations, semi-colon
  terminates list
• Other variable types possible

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 lt 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
variable
logical condition
true
x 3
x
false
2
1
else
conditions

• Two forms
• First True and false branches based on logical
  condition
• Second Switch-like statement
• Any logical operator can be used lt, lt, gt, gt,
  , /

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(now5.0,t1)
Starts timer t1 Will expire 5.0 time units from
now
state1
TIMER t1
t1
m2
reset(t1)
timer declaration
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
doesnt fit inside a symbol
x really_long_variable_name
x
really_long_variable_name
22
Save
state1
m1
m2

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

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 callers 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 parameters area
procedure name
Procedure A_Proc
FPAR IN/OUT d BIT, IN e BIT, IN/OUT f
OCTET
state1
m2
m4
procedure starts here
m5
m4
state2
state1
return to caller
29
Procedure Parameters
FPAR IN/OUT d BIT, IN e BIT,
IN/OUT f OCTET
Formal parameters keyword
Parameter type

• Syntax notes
• Note semicolon before FPAR keyword
• Comma separates parameter declarations
• Semicolon terminates parameter list.

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