A simple way to generate a simulator, start the SimUI and open the simulator is to click the Simulate quick button in the Organizer.
This chapter is a reference to the simulator user interface.
For a guide to how to use the simulator, see Simulating a System.
A simulator generated by SDT consists of two main parts; the application itself (the simulated SDL system), and an interactive monitor system. The monitor system is the interface between the user and the simulated system. For more information on the structure of a simulator and the features of the simulator monitor, see Structure of a Simulator.
Two different user interfaces are provided for the simulator monitor, a textual and a graphical.
The textual interface only allows commands to be entered from the keyboard, using the syntax described in the section Syntax of Monitor Commands.
The graphical interface still allows commands to be entered from the keyboard in the same way, but also provides buttons, menus and dialogs for easy access to commands and other features.
The textual interface is invoked by executing the generated simulator directly from the operating system prompt. This is called running a simulator in textual mode. When started, the simulator responds with the following text:
Welcome to SDT SIMULATOR. Simulating system <system> Command :
Another prompt may appear if the SDL system contains external synonyms. For more information, see Supplying Values of External Synonyms.
The graphical interface, known as the Simulator UI, runs in a separate window. It is started from the Organizer by selecting SDL > Simulator UI from the Tools menu. The Simulator UI is described in Graphical User Interface.
If a file called siminit.com exists in the current directory an implicit Include-File command will be done on this file at startup.
Commands can be issued to the interactive monitor system when it becomes active. The simulator's monitor system becomes active:
<Return> is pressed during the output of trace information. The interactive monitor then becomes active directly after the current symbol has been executed.
|
Note: No other characters may be typed before |
The monitor system waits for commands from the user by issuing the following prompt:
Command :
The syntax to be used for the commands and their parameters are described in the following.
A command name may be abbreviated by giving sufficient characters to distinguish it from other command names. A special character, the hyphen (-), is used to separate command names into distinct parts. Any part may be abbreviated as long as the command name does not become ambiguous.
Consider, as an example, the command name List-Process. The command name may be typed List-P or L-P. However, if only List is typed, the monitor system will respond with the message
Command was ambiguous, it might be an abbreviation of:
followed by a list of all commands starting with "List," since the command cannot be distinguished from, for example, the commands List-Ready-Queue and List-Timer.
There is no distinction made between upper and lower case letters when matching command names.
Command parameters are separated by one or several spaces, carriage returns or tabs. A colon is also accepted between a process name and an instance number, when a PId value is required. If the parameter list following a command name is not complete the interactive monitor system will ask for the missing parameters by prompting with the type of the expected parameters.
Parameters may be abbreviated as long as the parameter value does not become ambiguous. There is no distinction made between upper and lower case letters.
|
Note: The SDL keywords Sender, Parent, Self and Offspring may not be abbreviated. |
Command parameters that are SDL names may also be abbreviated, as long as the abbreviation is unique. The underscore character `_' is used to separate names into distinct parts in the same way as the hyphen character (-) is used with command names. If a name is equal to the first part of another name, as for example Wait and Wait_For_Me, then any abbreviation of Wait is ambiguous. However, if all characters of the shorter name are given (Wait in this example), this is considered as an exact match and the short name will be selected.
The abbreviation facility means that the introduction of underscores in SDL names simplifies simulation. If, for example, you were considering if two signals should be named GenerateOn and GenerateOff or if they should be named Generate_On and Generate_Off, the last alternative is preferable for simulations, as the abbreviations G_On and G_Off are likely to be unique.
When a (possibly abbreviated) parameter name is entered and is to be matched with an unabbreviated name, only names in the entity class of interest are considered. That is, if the monitor expects a process name as parameter, only the names denoting process types will be part of the search for the full name.
Signal names and timer names are in the same entity class; process formal parameters and process variables are in the same entity class; each other type of name (process, procedure, state, block,...) is in an entity class of its own.
Knowledge of previous parameters is used to narrow the search for a given parameter name. Consider for example the command Output-Via, which takes two parameters, a signal and a channel. The channel name is then only searched for among the channels the given signal can be sent via.
Names can still cause problems, if, for example, there are two process types with the same name in two different blocks, or if the system and a block contain signal definitions with the same name.
In the first situation the process name will always be ambiguous and in the second case the system's signal will always be used. To solve cases like this, qualifiers with the same syntax as in SDL can be used. To reach a process P defined in block B in system S, the following notations can be used:
System S / Block B P <<System S / Block B>> P
The words "system," "block," "process," "procedure," and "substructure" in the qualifier may not be abbreviated, while all names of, for example, blocks and processes may be abbreviated according to the usual rules. It is only necessary to give those parts of the qualifier that make the qualifier path unique (this is an extension of the qualifier concept in SDL). The slash ( / ) in a qualifier may be omitted and replaced by one or more spaces. The angle brackets that are part of the qualifier when printed may be omitted when entering the qualifier.
Some command parameters may be omitted, indicating a default value for the parameter. To accept a default parameter value at the prompt, just press <Return>.
If the parameter is given on the same line as the command name and/or other parameters, type a hyphen `-' to indicate a default parameter value.
Consider as an example the command Breakpoint-Transition, which takes at least eight parameters. To specify default values for all parameters, except the first and fourth parameter:
Breakpoint-Transition P - - State1 - - - -
When the parameters of a signal instance or a timer instance are to be entered, the interactive monitor system will ask for the parameters one by one, in the same way as for command parameters. The parameters can also be entered directly after the signal or timer name, possibly enclosed by parenthesis.
Signal name : S Parameter 1 (Integer) : 3 Parameter 2 (Boolean) : true
The same specification could also be given as:
Signal name : S 3 true
or as:
Signal name : S (3 true)
When entering signal parameters it is not necessary to give all parameter values. By entering `-' at the parameter's position, the parameter is given a "null" value (i.e. the computer's memory for the value is set to 0). By entering `)', the rest of the parameters are given "null" values.
Signal name : S -, true
will give the first parameter a "null" value.
Signal name : S (3, -)
will give the second parameter a "null" value. Could also be given as:
Signal name : S (3)
If an error in a command name or in one of its parameters is detected, an error message is printed and the execution of the command is interrupted, that is, a command is either executed completely or not at all. On UNIX, this is the only way to cancel a command that has been entered, when not using the simulator's graphical user interface.
By typing a question mark (`?'), a context-sensitive help is obtained. The monitor will respond to a `?' by giving a list of all allowed values at the current position, or by a type name, when it is not suitable to enumerate the values. After the presentation of the list, the input can be continued.
If no default value exists for the requested parameter, the list of all allowed values is also printed if the user simply presses <Return> at the prompt. In these cases, there is no need to type `?'.
The syntax of literals of the predefined data types is in most cases obvious and follows the SDL definition of literals. There are, however, some extensions that are described below. As an option, it is also possible to use the ASN.1 syntax for values. On input the monitor system can manage both value notations, while there are commands in the monitor to select the type of output to be produced ( SDL-Value-Notation and ASN1-Value-Notation).
The format of integers conforms exactly with the SDL and the ASN.1 standard, that is, an integer consists of a sequence of digits, possibly preceded by a `+' or `-'. However, with the command Define-Integer-Output-Mode it is possible to define the base of integers on output (decimal, hexadecimal, octal), which also affects how they may be entered. Hexadecimal values are preceded with "0x", and octal values are preceded with `0' (a zero).
Boolean values are entered (and printed) as true and false, using upper or lower case letters. Abbreviation is allowed on input. In ASN.1 mode the value is printed in capital letters (TRUE, FALSE).
The SDL literal syntax of real values has been extended to include the E-notation for exponents, in the same way as in many programming languages.
The real number 1.4527 * 1024 can be written 1.4527E24
The real number 4.46 * 10-4 can be written 4.46E-4
The syntax for real values in ASN.1 is easiest described by an example:
{mantissa 23456, base 10, exponent -3}
This is the value 23.456.
The format for Time and Duration values follows the SDL standards, i.e. real values without E-notation, with one extension. On input time values can either be absolute or relative to NOW. If the time value is given without a sign an absolute time value is assumed, while if a plus or minus sign precedes the value, a value relative to NOW is assumed.
123.5 is interpreted as 123.5
+5.5 is interpreted as NOW + 5.5
-8.0 is interpreted as NOW - 8.0
Character values are entered and printed according to the SDL standard, including the literals for the non-printable characters.
'a', '3', '''', ' ', NUL, DEL
On input, the quotes may be omitted for all characters except ` ' (space) and `[`. A `should be entered as `'''.
Charstring values can be entered and printed according to the SDL standard, that is, a single quote ( ' ) followed by a number of characters followed by a single quote. Any quote (') within a charstring has to be given twice. On output a non-printable character within a charstring is printed as a single quote followed by the character literal followed by a single quote.
The ASN.1 syntax for Charstring is similar to the SDL syntax. The delimiter character ` (single quote) is however replaced by the character " (double quote).
'' |
An empty string |
'abc' |
A string of three characters |
'a'NUL'c' |
The second character is NUL |
Apart from the value null, which is a valid PId value, a PId value consists of two parts, the name of the process type and an instance number, which is an integer greater than 0.
The first process instance of a process type that is created will have instance number 1, the second that is created will have instance number 2, and so on. The syntax is Name:No, where Name is the process name and No is the instance number.
On input the process name and the instance number may, as an alternative, be separated by one or more spaces, if the command parameter is a PId value. In the same circumstances the instance number is not necessary (and will not be prompted for) if there is only one process instance of the process type. If, however, the command parameter is a unit that might be a process type or a process instance, only a colon (`:') is allowed between the process name and the instance number and the colon must follow directly after the process type name. Examples of such situations are the unit parameter in Set-Trace and Signal-Log.
On output a PId value may be followed by a plus sign (`+'), which indicates that the process instance is dead; that is, has executed a stop action. The plus sign is chosen as it is reminiscent of the `' character.
The Bit sort contains two values, 0 and 1. This syntax is used for input and output.
For Bit_String values the following syntax is used:
'0110'B
The characters between the two single quotes must be 0 or 1. On input the syntax for Octet_String, see below, can also be used.
The syntax used for an octet value is two HEX digits. Examples:
00 46 F2 a1 CC
The characters 0-9, a-f, and A-F are allowed.
The syntax for Octet_String is the following
'3A6F'H
Each pair of two HEX values in the string is treated as an Octet value. If there is an odd number of characters an extra 0 is inserted last in the string.
The sort Object_Identifier is in SDL treated as a String(Natural). This means that the syntax, in case SDL value notation is used, will be:
(. 2, 3, 11 .)
On input the items in the list should be separated by a comma and/or spaces - tabs. If ASN.1 value notation has been selected, the syntax will be:
{ 2 3 11 }
On input the items in the list should be separated by a comma and/or spaces - tabs.
Types that in SDL are defined as an enumeration of possible values can be entered and printed using the literals of the SDL data type definition. On input, the literals can be abbreviated as long as they are unique.
A struct value is entered and printed as the two characters "(." followed by a list of components followed by the two characters ".)". The components should, on input, be separated by a comma and/or a number of spaces (or carriage returns or tabs). Example:
(. 23, true, 'a' .)
If ASN.1 syntax is used, the component names will also be present. Example:
{ Comp1 2, Comp2 TRUE, Comp3 'a' }
On input the components using ASN.1 syntax may come in any order. Components not given any value will have the value 0, whatever that means for the data type.
Optional components that are not present, will not be printed. In SDL syntax that means an empty position between two commas.
A #UNION value uses, in SDL value notation, the same syntax as a struct value. However, only the tag value and the active component is printed. In ASN.1 value notation, #UNION values use the Choice value syntax described below.
The syntax for a choice value is ComponentName:ComponentValue. If, for example, a choice contains a component C1 of type integer, then
C1:11
is a valid choice value.
An array value is entered and printed as "(:" followed by a list of components followed by a ":)". The components should, on input, be separated by a comma and/or a number of spaces (or carriage returns or tabs). Note that there should also be a space between the last component and the terminating ":)". In ASN.1 syntax, `{' and `}' are used as delimiters.
There are two syntaxes for array components depending on the implementation that the C Code Generator has selected for the array implementation. This selection is described in Array. These easiest way to determine which syntax to use on input is to look at a variable of the array sort.
(: 1, 10, 23, 2, 11 :)If ASN.1 value notation is selected, replace "(:" and ":)" by `{' and `}'.
(: (others:2), (10:3), (11:4) :)This would mean that for index 10 the value is 3, for index 11 the value is 4, and for all other indexes the value is 2. On input the commas, the parenthesis, and the colons in the components may be replaced by one or more spaces (or carriage returns or tabs).
For simple arrays the second syntax is also accepted. If the first syntax is used for simple arrays it is not mandatory to enter all values for the array components; by entering ":)" or "}" the rest of the components are set to a "null" value (i.e. the computer's memory for the value is set to 0).
A string value starts with "(." and ends with ".)". The components of the string is then enumerated, separated with commas. Example:
(. 1, 3, 6, 37 .)
On input the commas can be replaced by one or more spaces (or carriage returns or tabs). In ASN.1 syntax, `{' and `}' are used as delimiters instead of "(." and ".)".
A powerset value starts with a `[' and ends with a `]'. The elements in the powerset is then enumerated, separated with commas. Example:
[ 1, 3, 6, 37 ]
On input the commas can be replaced by one or more spaces (or carriage returns or tabs).
A bag value starts with a `{' and ends with a `}'. The elements in the bag is then enumerated, separated with commas. Example:
{ 1, 3, 6, 37 }
On input the commas can be replaced by one or more spaces (or carriage returns or tabs). If the same value occurs more than once, then this value is in SDL syntax not enumerated several times. Instead, the number of occurrences is indicated after the value. Example
{ 1, 3:4, 6:2, 37 }
This is identical to
{ 1, 3, 3, 3, 3, 6, 6, 37 }
In ASN.1 syntax, each member is given explicitly according to the last example. On input items are separated by comma and/or one or more spaces. It is also allowed to mention the same value several times, with or without a number of items each time.
There are two possible syntaxes for Ref values. Either the pointer address as a HEX value, or the value of the data area referenced by the pointer. The value Null is printed as Null in both syntaxes. In the monitor system two commands are available to determine the syntax to be used ( REF-Address-Notation and REF-Value-Notation). On input both syntaxes are allowed independently of what syntax that has been selected.
Example of the address notation:
HEX(23A20020)
In the value notation the keyword new() is used to indicate a reference to a value. If, for example, the following data types are available in SDL
newtype Str struct data integer; next StrRef; endnewtype; newtype StrRef Ref(Str) endnewtype;
then a value of the StrRef type can look like the examples below:
Null new( (. 1, Null .) ) new( (. 1, new( (. 2, Null .) ) .) )
The last example is a linked list with two elements. To handle recursive data structures, e.g. graphs, a special syntax is used: old n, where n is an integer. Example:
new( (. 1, new( (. 2, old 1 .) ) .) )
The notation old 1 in the example above means a reference to the same data area as the first new() notation refers to. So here we have two structs with next pointers referring to the other struct value. Old n would refer to the n:th new() seen from the left of the expression.
The same applies for Own and ORef values.
This section provides an alphabetical listing of all available commands in the simulator monitor.
(None)
The monitor will repeatedly look at the keyboard for a carriage return, indicating an immediate break in the execution of the current transition. Using the command @, this facility can be turned off. Each time the command @ is entered the monitor toggles between having the keyboard polling for carriage return on and off. At start up keyboard polling is on.
|
Note: No other characters may be typed together with the carriage return. If some other characters are typed by mistake, please delete them before typing the carriage return. |
To turn keyboard polling off is useful in some situations, for example if a user wants to paste a sequence of commands into the monitor. If the sequence contains an empty line this might cause an unwanted interrupt.
(None)
The monitor will respond to a `?' (question mark) by giving a list of all allowed values at the current position, or by a type name, when it is not suitable to enumerate the values. After the presentation of the list, the input can be continued.
Typing `?' at the prompt level gives a list of all available commands, after which a command can be entered. For further help, see the command Help.
(None)
The value notation used in all outputs of values is set to ASN.1 value notation. See also the command SDL-Value-Notation.
[ `(' <PId value> `)' ]
<Variable name> <Optional component selection>
<New value>
The new value is assigned to the specified variable in the process instance, service instance, or procedure given by the current scope. Sender, Offspring, and Parent may also be changed in this way, but their names may not be abbreviated.
It is, in a similar way as for the command Examine-Variable, possible to handle components in structured variables (struct, strings, array, and Ref) by appending the struct component name or a valid array index before the value to be assigned. Nested structs and arrays can be handled by entering a list of index values and struct component names.
If a PId is given within parenthesis the scope is temporarily changed to this process instance instead.
<SDT reference> <Optional breakpoint commands>
A breakpoint is defined at the symbol specified by the SDT reference. If the execution reaches the symbol, the monitor becomes active immediately before that symbol. SDT references may be obtained by using the Show GR Reference command in an SDL Editor, see Show GR Reference.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
<Signal name> <Sender process name> <Sender instance number> <Receiver process name> <Receiver instance number> <Counter> <Optional breakpoint commands>
A breakpoint is activated and a breakpoint condition is defined. If a breakpoint condition is matched by an output, the monitor becomes active immediately after the symbol containing the output. The breakpoint condition defines one or several outputs and is specified by the parameters. Any of the parameters may be omitted, which implies that any value will match the missing fields in the breakpoint condition. Initially no breakpoints are active.
The <Counter> parameter is used to indicate how many times the breakpoint condition should be true before the monitor should become active. Default value for this parameter is 1, which means that the monitor should be activated each time the breakpoint condition is true.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
<Process name> <Instance number> <Service name> <State name> <Signal name> <Sender process name> <Sender instance number> <Counter> <Optional breakpoint commands>
A breakpoint is activated and a breakpoint condition is defined. If a breakpoint condition is matched by a transition, the monitor becomes active immediately before that transition is started. The breakpoint condition matches one or several transitions and is specified by the parameters. Any of the parameters may be omitted, which implies that any value will match the missing fields in the breakpoint condition. Initially no breakpoints are active.
The <Counter> parameter is used to indicate how many times the breakpoint condition should be true before the monitor should become active. Default value for this parameter is 1, which means that the monitor should be activated each time the breakpoint condition is true.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
<Variable name> <Optional breakpoint commands>
A breakpoint is defined on the specified variable in the process instance given by the current scope. If the variable's value is changed, the monitor becomes active immediately after the symbol or assignment statement where the value is changed. The value is only checked between symbols and between assignment statements in tasks.
The breakpoint is also triggered when the variable no longer exists, i.e. the PId containing the variable is stopped or the procedure containing the variable has reached its end. In this case, the breakpoint is automatically removed.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
(None)
The Call-Env command performs one call of the function InEnv. See the command Start-Env for more details.
|
Note: This command and the commands Start-Env and Stop-Env are only available when the C Code Generator is used to generate applications. |
(None)
The command makes one call to the function that looks for incoming signals from the SDT communication mechanism. This means that all signals that have come to the simulator will be sent to their appropriate receiving process instances. See the command Start-SDT-Env for more details.
<Directory>
Change the current working directory to the specified directory.
(None)
This command is used to reset the coverage table to 0 in all positions, which means restart counting coverage from now.
<Entry number>
Stops the signal log with the specified entry number and closes the corresponding log file; see the command Signal-Log for more details. Entry numbers assigned by the command List-Signal-Log should be used.
(None)
The command log facility is turned off; see the command Command-Log-On for details.
<Optional file name>
The command enables logging of all the commands given in the monitor. The first time the command is entered a file name for the log file has to be given as parameter. After that any further Command-Log-On commands, without a file name, will append more information to the previous log file, while a Command-Log-On command with a file name will close the old log file and start using a new file with the specified name.
Initially the command log facility is turned off. It can be turned off explicitly by using the command Command-Log-Off.
The generated log file is directly possible to use as a file in the command Include-File. It will, however, contain exactly the commands given in the session, even those that were not executed due to command errors. The concluding Command-Log-Off command will also be part of the log file.
(None)
This command will create a new Breakpoints menu in the SDL Editor and tell the SDL Editor to show all graphical breakpoints. If no SDL Editor is opened, the menu will appear when an SDL Editor is opened the next time. The commands given in the new menu will only be handled in those simulations that are connected. See also the Disconnect-Editor command.
<Process name> <Parent's PId value> <Process parameters>
A process instance of the specified process type is created. If the parent PId is not equal to null, Offspring is set in the specified parent instance. If the number of instances of the specified process type is greater than or equal to the maximum number of concurrent instances, the user has to verify the create action.
"On" | "Off"
Defines whether the execution of the simulation shall continue after a command is given. The default is "Off".
"dec" | "hex" | "oct"
Defines whether integer values are printed in decimal, hexadecimal or octal format. In hexadecimal format the output is prepended with "0x", in octal format the output is prepended with `0' (a zero).
On input: if the format is set to hexadecimal or octal, the string determines the base as follows: After an optional leading sign a leading zero indicates octal conversion, and a leading "0x" hexadecimal conversion. Otherwise, decimal conversion is used.
The default is "dec", and no input conversion is performed.
"On" | "Off"
Defines whether the env instance should be split into one instance for each channel connected to env in the MSC trace. The default is "Off".
(None)
This command will remove the connection to the SDL Editor. If this simulation is the only connected to the SDL Editor, it will also remove the Breakpoints menu in the SDL Editor. See also the Connect-To-Editor command.
<Optional service name>
Moves the scope one step down in the procedure call stack. If the current scope is a process containing services, one of the services should be specified. See also the commands Stack, Set-Scope and Up.
[ `(' <PId value> `)' ]
Information about the process instance given by the current scope is printed (see the Set-Scope command for an explanation of scope). This information contains the current values of Parent, Offspring, Sender and a list of all currently active procedure calls made by the process instance (the stack). The list starts with the latest procedure call and ends with the process instance itself. If the process contains services, these services will be listed, each with its own procedure call stack.
If a PId is given within parenthesis information about this process instance is printed instead.
<Entry number>
The parameters of the signal instance at the position equal to entry number in the input port of the process instance given by the current scope are printed (see the Set-Scope command for an explanation of scope). The entry number is the number associated with the signal instance when the command List-Input-Port is used.
<Entry number>
The parameters of the specified timer instance are printed. The entry number is the number associated with the timer when the List-Timer command is used.
[ `(' <PId value> `)' ]
<Optional variable name>
<Optional component selection>
The value of the specified variable or formal parameter in the current scope is printed (see the Set-Scope command for an explanation of scope). Variable names may be abbreviated. If no variable name is given, all variable and formal parameter values of the process instance given by the current scope are printed. Sender, Offspring, Self, and Parent may also be examined in this way. Their names, however, may not be abbreviated and they are not included in the list of all variables.
|
Note: If a variable is exported, both its current value and its exported value are printed. |
It is possible to examine only a component of a struct, string or array variable, by appending the struct component name or a valid array index value as an additional parameter. The component selection can handle structs and arrays within structs and arrays to any depth by giving a list component selection parameters. SDL syntax with `!' and "( )" as well as just spaces, can be used to separate the names and the index values.
It is also possible to print a range of an array by giving "FromIndex: ToIndex" after an array name. Note that the space before the `:' is required if FromIndex is a name (enumeration literal), and that no further component selection is possible after a range specification.
To see the possible components that are available in the variable, the variable name must be appended by a space and a `?' on input. A list of components or a type name is then given, after which the input can be continued. After a component name, it is possible to append a `?' again to list possible sub components.
To print the value of the data referenced by a Ref pointer it is possible to use the SDL syntax, i.e. the "*>" notation. If, for example, Iref is a Ref(Integer) variable then Iref*> is the integer referenced by this pointer. If Sref is a Ref of a struct, then Sref*> ! Comp1 is the Comp1 component in the referenced struct. The sequence *> ! can in the monitor be replaced by -> (as for example in C).
If a PId is given within parenthesis the scope is temporarily changed to this process instance instead.
(None)
The simulation is terminated. If the command is abbreviated the monitor asks for confirmation. This is the same command as Quit.
(None)
This command will execute the currently executing procedure up to and including its return, i.e. it will finish this procedure. The execution will also be interrupted at the end of the transition. In a process, Finish will behave just like the command Next-Transition.
(None)
The execution of the simulation is resumed. The execution will continue until one of the conditions listed in Activating the Monitor becomes true. To stop the execution of transitions, press<Return> (and only this key). The interactive monitor will then become active when the execution of the current SDL symbol is completed.
This command has to be used with care in the interactive monitor, as it might result in executing the simulation program "forever" (if none of the conditions for activating the monitor becomes true). In a catastrophic situation (e.g. an endless loop within an SDL symbol) it is possible to terminate the program by using the way to stop the execution of a program defined in the operating system (<Ctrl+C> on UNIX).
(None)
The command Go-Forever behaves, in most situations, in the same way as the command Go.
For Go-Forever to behave differently than Go, there has to be an environment to the SDL system that can send signals to the SDL system (communicating simulations or environment functions). When the command Go is issued and the SDL system becomes completely idle (no possible transition and no active timer) the monitor becomes active again and is entered. If Go-Forever was used instead of Go, the monitor is not entered in this case; instead the simulation continues to wait for external stimulus. This feature is valuable when a simulation communicates with other simulations or applications.
<Optional command name>
Issuing the Help command without a parameter will print all the available commands. If a command name is given as parameter, this command will be explained.
<File name>
This command provides the possibility to execute a sequence of monitor commands stored in a text file. The Include-File facility can be useful for including, for example, an initialization sequence or a complete test case. It is allowed to use Include-File in an included sequence of commands; up to five nested levels of include files can be handled.
(None)
All active breakpoints are listed. Each breakpoint is assigned an entry number that can be used in the Remove-All-Breakpoints and Show-Breakpoint commands.
(None)
The values of all currently defined GR traces are listed. The list contains the trace unit type (system, block, process, PId), the unit name, and the GR trace value (both numeric and a textual explanation). See also the commands Set-GR-Trace and Reset-GR-Trace.
[ `(' <PId value> `)' ]
A list of all signal instances in the input port of the process instance given by the current scope is printed (see the Set-Scope command for an explanation of scope). For each signal instance an entry number, the signal type, and the sending process instance is given. A `*' before the entry number indicates that the corresponding signal instance is the signal instance that will be consumed in the next transition performed by the process instance. The entry number can be used in the commands Examine-Signal-Instance, Rearrange-Input-Port and Remove-Signal-Instance.
If a PId is given within parenthesis information about this process instance is printed instead.
(None)
This command returns the current status of the MSC log (off / interactive / batch). See also the commands Start-Interactive-MSC-Log, Start-Batch-MSC-Log and Stop-MSC-Log.
(None)
This command returns the current status for the MSC trace parameters. The list contains the trace unit type (system, block, process, PId), the unit name, and the MSC trace value (both numeric and a textual explanation). See also the commands Set-MSC-Trace and Reset-MSC-Trace.
<Optional process name>
A list of all process instances associated with the specified process type is produced. If no process name is specified all process instances in the system are listed. The list will contain the same details as described for the List-Ready-Queue command.
(None)
A list is produced containing the process instances in the ready queue, i.e., those instances that have received a signal that can cause an immediate transition, but that have not yet had the opportunity to execute this transition to its end. If the process contains services, the currently active service is also listed. If a process/service instance has active procedure calls, the current executing procedure instance is also listed. For each instance in the list the following information is given:
The process instance, the state, and the signal instance determine uniquely the transition that will be executed by the process instance when it gets permission to do so.
The entry number can be used in the command Rearrange-Ready-Queue.
(None)
Print information about the currently active signal log; see the command Signal-Log for more details. Each log is assigned an entry number which can be used in subsequent Close-Signal-Log commands.
(None)
A list of all currently active timers is produced. For each timer, its corresponding process instance and associated time is given. An entry number will also be part of the list, which can be used in the command Examine-Timer-Instance.
(None)
The values of all currently defined traces are listed. The list contains the trace unit type (system, block, process, PId), the unit name and the trace value (both numeric and a textual explanation). See also the commands Set-Trace and Reset-Trace.
(None)
The command Log-Off turns off the interaction log facility, which is described in the command Log-On.
<Optional file name>
The command Log-On takes an optional file name as a parameter and enables logging of all the interaction between a simulation program and the user that is visible on the screen. The first time the command is entered, a file name for the log file has to be given as parameter. After that any further Log-On commands, without a file name, will append more information to the previous log file, while a Log-On with a file name will close the old log file and start using a new file with the specified file name.
Initially the interaction log facility is turned off. It can be turned off explicitly by using the command Log-Off.
(None)
The News command summarizes the changes in the textual monitor user interface from the previous SDT release.
<Optional number of statements>
This command is used to step statement for statement through SDL transitions. A statement is the same as a symbol, except that a task symbol may contain several assignment statements; compare with the Next-Symbol command.
Next-Statement steps over procedure calls, i.e. all actions in the procedure will be executed and the monitor will be entered again when the statement after the procedure call is reached; compare with the Step-Statement command.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
|
Note: The right hand side of an assignment may contain a value returning procedure call. |
<Optional number of symbols>
This command is used to step symbol for symbol through SDL transitions. A symbol may contain several statements; compare with the Next-Statement command.
Next-Symbol steps over procedure calls, i.e. all actions in the procedure will be executed and the monitor will be entered again when the symbol after the procedure call is reached; compare with the Step-Symbol command.
Using the optional integer parameter, a specified number of symbols can be stepped through. Next-Symbol will, however, never step from within one transition into another transition.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
|
Note: Join is not considered a symbol by this command. |
To determine how far a transition has been executed, the commands Show-Next-Symbol and Show-Previous-Symbol, together with trace printouts and GR traces can be used. The last trace printout is from the last executed symbol (if it has caused a printout, which depends on the trace level), while the symbol next to be executed is selected by the GR trace, if GR trace is on.
(None)
The next transition is executed. If real time is used and the next transition is a timer output scheduled in the future (more than a second from now), the command Next-Transition will wait one second, after which the monitor is entered again.
Executing a Next-Transition command within a transition will execute the remaining part of the transition.
(None)
A number of transitions are executed up to and including the next transition with a trace value > 0. For a timer output transition, it is the trace value for the corresponding process instance that is considered.
This command should be used with care in the interactive monitor, as it might result in executing the simulation program "forever" (if no transition with trace>0 is ever executed). To stop the execution of transitions, press <Return>. The interactive monitor will then become active when the execution of the current SDL symbol is completed.
<State name>
The state of the process/service/procedure instance given by the current scope is changed (see the Set-Scope command for an explanation of scope). This command implies that all actions in a nextstate are performed, i.e. recalculation of enabling conditions and continuous signals, and searching for a signal to be received according to the input and save sets. As a consequence the ready queue for process instances may change.
(None)
The current value of the simulation time is printed.
<Signal name> <Signal parameters> <Receiver's PId value> <Sender's PId value>
The command is used to simulate an output of an internal signal instance between two process instances in the system. The parameter <Sender's PId value> may also denote "env:1". No check is made to ensure that a path of signal routes and channels exists. The monitor responds with either of the three messages below.
Signal <name> is not in valid input signal set of process <name>
The signal was not in the valid input signal set of the receiver and can thus not be handled by the receiver. The signal was immediately discarded.
Signal <name> was sent to <receiver> from <sender>
The signal instance was successfully sent and was placed in the input port of the receiver.
Signal <name> caused an immediate null transition
The receiving process instance is currently waiting in a state where the specified signal type neither may cause an input operation, nor is saved. The signal instance is immediately discarded (in SDL this is called a null transition, i.e a transition with no actions, leading back to the same state).
<PId value> <Optional service name>
The command is used to send a signal "none" to the specified process instance. If the process instance contains services, one of the services should to be specified as well. The none signal is used to indicate that a spontaneous transition should be initiated in the current state.
<Signal name> <Signal parameters> <Receiver's PId value>
The command is used to send a signal from the environment of the system to a process instance in the system. It will be checked that a path of channels and signal routes exists from the environment to the specified process instance.
The monitor will respond with either of the messages described below, or by an error message if no path existed.
Signal <name> was sent to <receiver> from <sender>
The signal instance was successfully sent and is placed into the input port of the receiver.
Signal <name> caused an immediate null transition.
The receiving process instance is currently waiting in a state where the specified signal type neither may cause an input operation, nor is saved. The signal instance is immediately discarded (in SDL this is called a null transition, a transition with no actions, leading back to the same state).
<Signal name> <Signal parameters> <Optional channel name>
The command is used to send a signal from the environment of the system to a process instance in the system via the specified channel. If no channel is given, it is assumed that any channel from the environment to the system may be selected. It will be checked that there exists one process instance that can receive the signal, according to the rules of outputs in SDL.
The monitor will respond with either of the messages below, or by an error message if the number of possible receivers is not equal to one.
Signal <name> was sent to <receiver> from <sender>
The signal instance was successfully sent and is placed into the input port of the receiver.
Signal <name> caused an immediate null transition.
The receiving process instance is currently waiting in a state where the specified signal type neither may cause an input operation, nor is saved. The signal instance is immediately discarded (in SDL this is called a null transition, a transition with no actions, leading back to the same state).
<File name>
This command can be used to obtain test coverage information and profiling information. Each time the command is issued a coverage file, with the name specified as parameter, is produced in the work directory containing the relevant information. The coverage file always reflects the situation from the start of the simulation. To study the information in the coverage file, it can be opened in the Coverage Viewer; see The Coverage Viewer.
|
Note: The specified file is always overwritten, i.e. there is no confirmation message if an existing file is specified. |
The generated file consists of two sections, first a summary with profiling information, containing the number of transitions and the number of symbols executed by each process type. Secondly the file contains detailed information about how many times each symbol and each state - input combination is executed.
*************** PROFILING INFORMATION **************
2 System DemonGame : Transitions = 13, Symbols = 40
3 Block GameBlock
4 Process Main : Transitions = 3 (23%),
Symbols = 10 (25%), MaxQ = 2
4 Process Game : Transitions = 6 (46%),
Symbols = 15 (37%), MaxQ = 2
3 Block DemonBlock
4 Process Demon : Transitions = 4 (30%),
Symbols = 15 (37%), MaxQ = 1
This information in Example 157 should be interpreted in the following way:
************** COVERAGE TABLE DETAILS ************** 2 System DemonGame 3 Block GameBlock 4 Process Main 1 : Start #SDTREF(SDL,main.spr(1),131(30,10),1) 1 : Game_Off Newgame #SDTREF(SDL,main.spr(1),137 1 : Game_On Endgame #SDTREF(SDL,main.spr(1),119( -------------------- 1 START : #SDTREF(SDL,main.spr(1),131(30,10),1) 1 INPUT : #SDTREF(SDL,main.spr(1),137(31,44),1) 1 INPUT : #SDTREF(SDL,main.spr(1),119(56,44),1) 1 NEXTSTATE : #SDTREF(SDL,main.spr(1),134(34,29),1) 1 CREATE : #SDTREF(SDL,main.spr(1),140(37,59),1) 1 TASK : #SDTREF(SDL,main.spr(1),143(34,72),1) 1 NEXTSTATE : #SDTREF(SDL,main.spr(1),146(35,89),1) 1 OUTPUT : #SDTREF(SDL,main.spr(1),122(56,59),1) 1 TASK : #SDTREF(SDL,main.spr(1),125(60,72),1) 1 NEXTSTATE : #SDTREF(SDL,main.spr(1),128(59,89),1)
For each process type two types of information are given, separated by a line of hyphens:
To identify the process symbols, the command Show GR Reference command in the SDL Editor's Tools menu can be used for the printed GR references. (See Show GR Reference.)
(None)
This command will execute all transitions up to but not including the next timer output. The timer output will not be executed even if it is the next transition.
<Time value>
The execution of the simulation is resumed. The monitor will become active when the value of the simulation time first becomes equal to the time value given as parameter.
Note that relative time values can be given using the `+' sign. Entering "+5.0" as parameter is interpreted as the time value NOW+5.0. See also Input and Output of Data Types.
(None)
The simulation is terminated. If the command is abbreviated the monitor asks for confirmation. This is the same command as Exit.
<Entry number> <New entry number>
This command is used to change the order of signal instances in the input port of the process instance given by the current scope (see the Set-Scope command for an explanation of scope).
The entry number parameters refer to the numbers assigned by the command List-Input-Port. The signal instance with entry number equal to the first parameter will be moved to a position where it in a subsequent List-Input-Port command will be assigned the entry number given as the second parameter.
<Entry number> <New entry number>
This command is used to change the order in which transitions by process instances are executed. The entry number parameters refer to the entry numbers assigned by the command List-Ready-Queue. The process instance with entry number equal to the first parameter will be moved to a position where it in a subsequent List-Ready-Queue command will be assigned the entry number given as the second parameter.
The Rearrange-Ready-Queue command should be used with care when process priorities are used. The ready queue is then sorted in priority order (see also Scheduling), which means that a rearrangement might disturb this order. Such a disturbance does not harm, except when a new process should be inserted into the ready queue. In this situation the insert point might not be the proper one. The following insert algorithm is used: Search from the end of the ready queue until a process with higher or equal priority (lower or equal priority value) is found, then insert the new process after the found process. If no process with higher or equal priority is found, then insert the new process first in the ready queue.
(None)
REF values (pointers introduced using the generator Ref) are printed as addresses, using the HEX value for the address. The Null value is printed as Null. On input, both this syntax and the Value-Notation (see command REF-Value-Notation) can be used.
The same applies for Own and ORef values.
(None)
REF values (pointers introduced using the generator Ref) are printed as NEW(<the value the pointer refers to>). This is the default syntax for REF values. It means that complete lists or graphs will be printed. Example:
NEW( (. 1, NEW( (. 2, Null .) ) .) )
To avoid problems in cyclic graphs a special syntax is used if a pointer refers to an address already presented in the output. OLD n, where n is a digit, means a reference to the n:th NEW in the printed value. Example:
NEW( (. 1, NEW( (. 2, OLD 1 .) ) .) )
The Null value is printed as Null. On input both this syntax and the Address-Notation (see command REF-Address-Notation) can be used.
The same applies for Own and ORef values.
(None)
This command removes all breakpoints.
<SDT reference>
This command removes all breakpoints at the symbol specified by the SDT reference.
<Entry number>
This command removes the breakpoint with the specified entry number. The entry number given by List-Breakpoints should be used.
<Entry number>
The signal instance with the given entry number in the input port of the process instance given by the current scope is removed (see the Set-Scope command for an explanation of scope). The entry number given by List-Input-Port should be used. If this signal was selected for the next transition, the process instance will execute an implicit nextstate action.
|
Note: Entry numbers are just positions in the input port. The removal of a signal changes the entry numbers of the remaining signals. |
<Optional unit name>
The GR trace value of the given unit is reset to undefined. If no unit is specified the GR trace value of the system is reset to undefined. As there always has to be a GR trace value defined for the system,
Reset-GR-Trace on the system is considered to be equal to setting the GR trace value to 0. For more information about optional unit names, see the command Set-Trace.
<Optional unit name>
The MSC trace value of the given unit is reset to undefined. If no unit is specified the MSC trace value of the system is reset to undefined. As there always has to be a MSC trace value defined for the system,
Reset-MSC-Trace on the system is considered to be equal to setting the trace value to 0. For more information about optional unit names, see the command Set-MSC-Trace.
<Timer name> <Timer parameters>
The result of the command is exactly the same as if the process instance given by the current scope had executed a reset action. If the reset action causes a timer signal to be removed and this signal was selected for the next transition, the process instance will execute an implicit nextstate action.
<Optional unit name>
The trace value of the given unit is reset to undefined. If no unit is specified the trace value of the system is reset to undefined. As there always has to be a trace value defined for the system, Reset-Trace on the system is considered to be equal to setting the trace value to 0. For more information about optional unit names, see the command Set-Trace.
(None)
This command prints the current scope. See the command Set-Scope for a description of scope.
(None)
The value notation used in all outputs of values is set to SDL value notation. This is the default value notation. See also the command ASN1-Value-Notation.
<File name>
This command will save all breakpoints in a file, with the name specified as parameter (in the work directory). It is written as a text file with commands, so the breakpoints can be restored with the Include-File command.
<Optional unit name> <Trace value>
The GR trace value is assigned to the specified unit (system, block, process, or process instance). If no unit is specified the GR trace value is assigned to the system. The initial GR trace value of the system is 0, i.e. no GR trace, while it is undefined for all other units. For more information about optional unit names, see the command Set-Trace.
For a description of the possible GR trace values, see GR Traces.
<Optional unit name> <Trace value>
This command enables the trace of SDL events that take place during the simulation and which can be transformed into events in a Message Sequence Chart. Typically, the events that can be transformed are sending and consumption of signals, and creation and termination of processes.
|
Note: Setting the MSC trace value with this command does not start the actual logging of MSC events. To do this, the command Start-Interactive-MSC-Log or Start-Batch-MSC-Log is used. |
The scope of the trace can be delimited by specifying an optional unit name and a trace value. The general considerations for specifying the unit name for the command Set-Trace are also applicable for Set-MSC-Trace.
The initial MSC trace value of the system is 1. For more information on MSC trace values, see Message Sequence Chart Traces.
|
Note: Once the logging of Message Sequence Chart traces has been started (using any of the commands Start-Interactive-MSC-Log or Start-Batch-MSC-Log) modifying the scope of trace may cause unpredictable results, such as Message Sequence Charts with an unexpected appearance. |
<PId value> <Optional service name>
This command sets the scope to the specified process, at the bottom procedure call. If the process contains services, one of the services can be given as parameter to the command. A scope is a reference to a process instance, a reference to a service instance if the process contains services, and possibly a reference to a procedure instance called from this process/service. The scope is used for a number of other commands for examining and changing the local properties of a process instance. The scope is automatically set by the execution commands, when entering the monitor, to the next process in turn to execute.
The command Scope prints out the current scope; i.e. the name of the process instance and possibly the service instance and the called procedure instance. See also the commands Stack, Define-MSC-Trace-Channels and Up.
<Timer name> <Timer parameters> <Time value>
The result of the command is exactly the same as if the process instance given by the current scope had executed a set action. If the set action causes a timer signal to be removed and this signal was selected for the next transition, the process instance will execute an implicit nextstate action.
<Optional unit name> <Trace value>
The trace value is assigned to the specified unit (system, block, process, or process instance). If no unit is specified the trace value is assigned to the system. The initial trace value for the system is 4, while it is undefined for all other units. For a description of the possible trace values, see Trace Limit Table.
There might, in some cases, be problems in identifying a specific unit. If more than one unit in the system match the, possibly abbreviated, unit name, the first unit found when searched from the system level will be assigned. To make sure the correct unit is assigned, the unit's diagram type, e.g. "process" (unabbreviated), can be introduced before the unit name. If there still are problems, for instance due to the fact that there are several processes with the same name, a qualifier should be inserted immediately before the unit name. An example can be found in Specifying Unit Names.
To specify a PId value, a colon and an instance number must follow directly after the process name; see also Input and Output of Data Types.
<Entry number>
This command is only applicable for symbol breakpoints defined with the command Breakpoint-At. The breakpoint with the specified entry number is listed, and the symbol with the breakpoint will be selected in an SDL Editor showing the source GR document. The entry number given by List-Breakpoints should be used.
(None)
This command prints the .c file name and line number where the execution of the current SDL transition is suspended. The Text Editor is opened with the cursor positioned on that line in the C source file. The given line number will reference a statement with the following structure:
XBETWEEN_SYMBOLS(...)
The case label just following this statement is the place where the execution will be resumed when an execute command is given in the monitor.
The Show-C-Line-Number command is mainly thought to be used when the execution is interrupted within an SDL transition. If the command is issued between two transitions, theXBETWEEN_SYMBOLSstatement immediately before the last Nextstate or Stop operation will be referenced in the printout, together with a warning that this is not the current position.
|
Note: Changes made in the monitor, as for example Rearrange-Ready-Queue, will not affect the printout by this command. |
(None)
This command starts the Coverage Viewer tool with the current test coverage loaded.
(None)
The symbol in turn to be executed will be selected in an SDL Editor showing the source GR document. If the simulation is not connected to SDT or the SDL source document is in SDL-PR, a GR symbol reference or a PR reference will instead be displayed on the screen. The details about GR symbol references are presented in Dynamic Errors. A PR reference is a file name and a line number. See also Syntax.
Note that between the execution of two transitions, i.e. after a Nextstate or Stop operation, no next symbol can be shown. Note also that changes made in the monitor, as for example changing the ready queue using the command Rearrange-Ready-Queue, will not affect the symbol selected by Show-Next-Symbol.
This command uses the same mechanisms to select symbols in the SDL Editor as the GR trace facility, so the same general characteristics as presented in GR Traces are also valid for this command.
(None)
The last executed symbol will be selected in an SDL Editor displaying the source GR document. If the simulation is not connected to SDT or the SDL source document is in SDL-PR, then a GR symbol reference or a PR reference will instead be displayed on the screen. See the command Show-Next-Symbol for more information.
(None)
The versions of the C Code Generator and the runtime kernel that generated the currently executing program are presented.
<Unit name> <File name>
Starts logging of signals to a specified file. See also the commands Close-Signal-Log and List-Signal-Log.
The unit name parameter should be either a channel, a signal route, a system, a block, a process type, or a process instance.
Note that the process "env" is a legal unit in the Signal-Log command. By specifying "env" as unit parameter, the signal interface between the system and the environment is logged. For more information about the unit name parameter, see the command Set-Trace.
(None)
The procedure call stack for the PId/service defined by the scope is printed. For each entry in the stack, the type of instance (procedure/process/service), the instance name and the current state is printed. See also the commands Set-Scope, Define-MSC-Trace-Channels and Up.
<Symbol level> <File name>
This command starts the logging of SDL events which can be translated into the corresponding MSC events in a log file (see Mapping Between SDL and MSC). See also the commands Start-Interactive-MSC-Log and Stop-MSC-Log.
The results will be stored in a log file, whose contents are specific for this purpose. That log file can later on be read by a Message Sequence Chart Editor, where its contents are interpreted as a Message Sequence Chart and displayed as such.
The symbol level parameter determines if states and actions should be included in the MSC log. For a description of the possible symbol level values, see Level of Symbol Logging.
The file name parameter to this command can be any valid file name, although it is recommended to use a file name with the suffix .mpr, since this is the default suffix used when reading a log file into a Message Sequence Chart Editor.
(None)
When the C Code Generator is used to generate applications, interface functions towards the environment of the SDL system must be provided. The InEnv function, which is used to enter signals into the SDL system, is frequently called from the main loop in the process scheduler. During debugging, the polling of the InEnv function can turned on and turned off.
The Start-Env command turns on the polling of InEnv. At start up of the program polling is turned off. See also the commands Stop-Env and Call-Env.
|
Note: This command and the commands Stop-Env and Call-Env are only available when the C Code Generator is used to generate applications. |
<Symbol level>
This command starts the logging of SDL events which can be translated into the corresponding MSC events in a Message Sequence Chart Editor (see Mapping Between SDL and MSC). See also the commands Start-Batch-MSC-Log and Stop-MSC-Log.
The symbol level parameter determines if states and actions should be included in the MSC log. For a description of the possible symbol level values, see Level of Symbol Logging.
When the command is issued, the following takes place:
Some drawing conventions and default layouting algorithms are used when drawing the automatically generated Message Sequence Chart. These conventions are described in Drawing Conventions.
(None)
A simulator can communicate with other simulations using SDL signals and the communication mechanism in SDT. Signals sent to the environment in one simulation can enter as signals from the environment in another simulator.
This command is used to tell a simulator to start sending signals that are designated to the environment via the SDT communication mechanism and to start looking for incoming signals (polling) from the SDT communication mechanism. See also the commands Stop-SDT-Env and Call-SDT-Env.
This facility is at program start up turned off, and should only be turned on when a simulator should be able to communicate with other simulators (or applications).
|
Note: The command must be given in both communicating simulators. |
(None)
This command starts the communication with ITEX.
(None)
This command starts a Simulator UI and connects the running simulator to it. After this it is only possible to give commands in the UI.
(None)
This command attempts to start the program sdtenv in the SDT start directory. The started program is assumed to connect itself to the SDT communication mechanism and can then communicate with the simulation program.
|
Note: The command Start-SDT-Env should be given in the simulation program to make it communicate. |
<Optional number of statements>
This command is used to step statement for statement through SDL transitions. A statement is the same as a symbol, except that a task symbol may contain several assignment statements; compare with the command Step-Symbol.
Step-Statement will step into procedure calls; compare with the Next-Statement command.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
|
Note: The right hand side of an assignment may contain a value returning procedure call. |
<Optional number of symbols>
This command is used to step symbol for symbol through SDL transitions. A symbol may contain several statements; compare with the Step-Statement command.
Step-Symbol will step into procedure calls; compare with the Next-Symbol command.
Using the optional parameter, a specified number of symbols can be stepped through. Step-Symbol will, however, never step from within one transition into another transition.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
|
Note: Join is not considered a symbol by this command. |
<PId value> <Optional service name>
The specified process instance is stopped. If the process contains services, then either the process can be stopped by giving no service parameter, or one of the services can be stopped. The result of the command is exactly the same as if the process instance or service instance had executed a stop action.
(None)
This command turns off the polling of the InEnv function; see the Start-Env command for more details.
|
Note: This command and the commands Start-Env and Call-Env are only available when the C Code Generator is used to generate applications. |
(None)
This command stops the logging of Message Sequence Chart events (in interactive mode as well as in batch mode). In the case of a batch mode logging, the log file will be closed. See the commands Start-Interactive-MSC-Log and Start-Batch-MSC-Log for more details.
Following this command, it is possible to log the rest of the session on a new file.
(None)
The command turns off the communication mechanism described for the Start-SDT-Env command.
(None)
Moves the scope one step up in the procedure call stack. Up from a service leads to the process containing the service. See also the commands Set-Scope, Stack and Define-MSC-Trace-Channels.
When a process instance executes actions within a transition, trace information describing the current action might be printed on the screen. The amount of information printed can be selected using the trace commands in the monitor system. A typical trace from a transition containing a few actions is given below.
*** TRANSITION START * PId : Demon:1 * State : Generate * Input : T * Sender : Demon:1 * Now : 1.0000 * OUTPUT of Bump to Game:1 * SET on timer T at 2.0000 *** NEXTSTATE Generate
The transitions can also be traced in the GR source diagrams. This is discussed in detail under GR Traces.
A trace value, which is a non-negative integer, can be assigned to process instances, to process types, blocks, and to the system. The commands associated with traces are Set-Trace, Reset-Trace and List-Trace-Values.
When a process instance starts a transition, the trace value that governs the amount of trace to be printed is computed according to the following algorithm:
The hereby computed value is compared with the trace limit for each action executed during the transition. The trace information is printed only if the trace value is greater or equal to the trace limit for the action. Trace information at trace level 1 is treated specially, see below.
In the table below the trace limits for all the information that can be part of a trace is presented.
|
Note: The trace messages are produced when actions defined in the SDL diagrams are executed. These messages are not used when monitor commands like Set-Timer, Nextstate, or Stop are entered. |
The trace limit table can be summarized as follows:
Trace information at trace level 1, i.e. trace of signals sent to the environment of the specified unit, is treated in a special way. This information is not printed if the trace value is greater than 1, instead the normal trace of outputs is used.
GR trace is a way to follow the execution of transitions in the GR source diagrams by selecting SDL symbols. It should normally only be used for a small number of processes to limit the amount of information displayed. The GR trace value determines to what degree the execution will be traced, i.e. how often SDL symbols will be selected in the GR diagrams (see below). After a nextstate or stop operation, i.e. between two transitions, the nextstate or stop symbol is still selected.
The commands associated with GR traces are Set-GR-Trace, Reset-GR-Trace and List-GR-Trace-Values.
The GR tracing will take place in a single SDL Editor window, which will show the appropriate GR diagram as the execution progresses. If no SDL Editor is opened, a new editor is started.
Three trace values are possible:
The commands associated with MSC traces are Set-MSC-Trace, Reset-MSC-Trace and List-MSC-Trace-Values.
When executing an SDL system, some of the SDL events can be transformed into a corresponding symbol in a Message Sequence Chart. The mapping rules which govern how SDL events are transformed into MSC symbols, lines and textual elements are described in Mapping Between SDL and MSC.
The ITU definition of the MSC language introduces the instance concept. An instance is mapped to any instance of an SDL process.
The scope of MSC trace is the process instances that have a calculated MSC trace value > 0.
Assume that we have set the scope of MSC trace to a part of the SDL system, for instance a block and the underlying structure in terms of processes. When an event takes place in the SDL system, one of three possible situations is possible. Let us assume for the sake of simplicity that the event is the sending of a signal from one process to another process. The three cases and their behavior are as follows:
The MSC trace levels 1 and 2 are used to specify if conditional trace should be presented or not; see the table below. MSC trace level 3 specifies a block level trace.
| MSC Trace for Sender | MSC Trace for Receiver | Result |
|---|---|---|
|
|
0 |
No trace |
|
0 |
1 |
No trace |
|
|
2 |
Conditional trace |
|
|
0 |
No trace |
|
1 |
1 |
Trace |
|
|
2 |
Trace |
|
|
0 |
Conditional trace |
|
2 |
1 |
Trace |
|
|
2 |
Trace |
The symbol level determines the amount of information that should be part of the MSC log. Three symbol levels are possible:
At the start of a simulation, the trace values, the GR trace values and the MSC trace values for all units except the system are undefined. The system trace is 4, the system GR trace is 0, and the system MSC trace is 1.
Violations of the dynamic rules of SDL will cause dynamic errors during the execution of a simulation program. A dynamic error is presented to the user on the screen as an error message. See the example below.
Warning in SDL Output of signal Bump Signal sent to NULL, signal discarded Sender: Demon:1 TRANSITION Process : Demon:1 State : Generate Input : T Symbol : #SDTREF(SDL,/usr/tom/demon.spr(1),122(30,55),1) TRACE BACK Process : Demon Block : DemonBlock System : Demongame
The symbol reference given in the TRANSITION message should be interpreted as follows:
| Item | Text in Example 159 | Interpretation |
|---|---|---|
|
1 |
SDL |
Reference to SDL-GR object |
|
2 |
/usr/tom/demon.spr |
Reference to the file |
|
3 |
(1) |
Page name |
|
4 |
122 |
The object identity (an unique number assigned by the SDL Editor) |
|
5 |
30 |
The x-coordinate of the object in mm. The origin of coordinates is the upper left corner of the page. |
|
6 |
55 |
The y-coordinate of the object in mm |
|
7 |
1 |
Line number within symbol |
By entering the monitor command Show-Previous-Symbol, the symbol that caused the error is displayed.
For more information on references in SDT, see SDT References.
Error in SDL array index in sort <sort>: <value> is out of range.
Violation of the index range given in an array.
Error in assignment in sort <sort>: <value> is out of range.
Violation of the range conditions given in a syntype.
Error in SDL Decision: Value is <value> Entering decision error state
The value of the expression in the decision did not match any of the possibilities (answers).
Error in SDL Import. Attempt to import from NULL Error in SDL Import. Attempt to import from stopped process instance Error in SDL Import. Attempt to import from the environment Error in SDL Import. No process exports this variable Error in SDL Import. The specified process does not export this variable
Error in an import statement. Supplementary information about remote variable and exporting processes is also given.
Warning in SDL Output of signal <signal>. No path to receiver, signal discarded
An attempt was made to output a signal to a PId expression. There exists, however, no path of channels and signal routes between the sender and the receiver that can convey the signal.
Warning in SDL Output of signal <signal>. No possible receiver found, signal discarded
An attempt was made to output a signal without specifying a to PId expression. When all paths or all paths mentioned in a via clause had been examined no possible receiver was found.
Warning in SDL Output of signal <signal>. Signal sent to NULL, signal discarded
An attempt was made to output a signal to a PId expression that was null.
Warning in SDL Output of signal <signal>. Signal sent to stopped process instance
An attempt was made to output a signal to a PId expression that referred to a process instance which has performed a stop action.
Error in SDL View. Attempt to view from NULL Error in SDL View. Attempt to view from stopped process instance Error in SDL View. Attempt to view from the environment Error in SDL View: The specified process does not reveal this variable Error in SDL View: No process reveals this variable
Error in a view statement. Supplementary information about viewed variable and viewing process is also given.
Error in SDL Create: Process <process> More static instances then maximum number of instances.
Obvious!
Illegal #UNION tag value for assignment to component Name. Tag value is xxx.
Attempt to assign a value to a non-active UNION component.
Illegal #UNION tag value for access to component Name. Tag value is xxx.
Attempt to access a non-active UNION component.
Error when accessing component Name. Component is not Present.
Attempt to access a non-active optional struct component.
Component Name is not active.Present is xxx.
Attempt to access a non-active choice component.
Dereferencing of NULL pointer. Pointer assigned new data area at address: HEX(xxx)
Attempt to de-reference a Null pointer defined using the Ref generator.
User specified error: SDL error expression found
Error introduced by the user, by inserting the error expression defined in SDL.
The errors that can be found in operators defined in the predefined data types are listed below.
Error in SDL Operator: Extract! in sort Charstring, Index out of bounds Error in SDL Operator: Modify! in sort Charstring, Character NUL not allowed. Error in SDL Operator: MkString in sort Charstring, Character NUL not allowed. Error in SDL Operator: First in sort Charstring, Charstring length is 0 Error in SDL Operator: Fix in sort Integer, Integer overflow Error in SDL Operator: Last in sort Charstring, Charstring length is 0 Error in SDL Operator: Substring in sort Charstring, Charstring length is 0 Error in SDL Operator: Substring in sort Charstring, Length of substring < 0 Error in SDL Operator: Substring in sort Charstring, Start index is <= 0 Error in SDL Operator: Substring in sort Charstring, Start index + length of substring > length of charstring Error in SDL Operator: / in sort Integer, Attempt to divide by 0. Error in SDL Operator: / in sort Real, Attempt to divide by 0.0. Error in SDL Operator: Rem in sort Integer, Second operand is 0 Error in SDL Operator: Mod in sort Integer, Second operand is 0 Error in SDL Operator: Modify! in sort Bit_String, Index out of bounds. Error in SDL Operator: Extract! in sort Bit_String, Index out of bounds. Error in SDL Operator: First in sort Bit_String, Bit_String length is zero. Error in SDL Operator: Last in sort Bit_String, Bit_String length is zero. Error in SDL Operator: SubString in sort Bit_String, Bit_String length is zero. Error in SDL Operator: SubString in sort Bit_String, Start is less than zero. Error in SDL Operator: SubString in sort Bit_String, SubLength is less than or equal to zero. Error in SDL Operator: SubString in sort Bit_String, Start + Substring length is greater than string length. Error in SDL Operator: BitStr in sort Bit_String, Illegal character in Charstring (not 0 or 1). Error in SDL Operator: HexStr in sort Bit_String, Illegal character in Charstring (not digit or a-f). Error in SDL Operator: Modify! in sort Octet, Index out of bounds. Error in SDL Operator: Extract! in sort Octet, Index out of bounds. Error in SDL Operator: Division in sort Octet, Octet division with 0. Error in SDL Operator: Mod operator in sort Octet, Right operand is 0. Error in SDL Operator: Rem operator in sort Octet, Right operand is 0. Error in SDL Operator: BitStr in sort Octet, An Octet should consist of not more than 8 characters 0 or 1. Error in SDL Operator: HexStr in sort Octet, An Octet should consist of 2 HEX values. Error in SDL Operator: HexStr in sort Octet, Illegal character in Charstring (not digit or a-f). Error in SDL Operator: Modify! in sort Octet_String, Index out of bounds. Error in SDL Operator: Extract! in sort Octet_String, Index out of bounds. Error in SDL Operator: BitStr in sort Octet_String, An Octet_String should consist of 0 and 1. Error in SDL Operator: HexStr in sort Octet_String, Illegal character in Charstring (not digit or a-f).
Apart from these error message each instantiation of generator String will introduce similar error messages as for the Charstring sort. Note that Object_Identifier is a predefined sort which is an instantiation of String.
After a dynamic error, the execution of the simulation program is continued until the current symbol is ended. The interactive monitor will then become active. The following actions will be taken:
A user can define his own run-time errors or assertions. Basically the run-time library only provides an appropriate C function that can be called to print out an error message. This function is assumed to be used in #CODE directives in TASKs according to the following example:
TASK '' /*#CODE
#ifdef XASSERT
if (#(I) < #(K))
xAssertError("I is less than K");
#endif
*/ ;
The xAssertError function, which has the following prototype:
extern void xAssertError ( char *Descr )
takes a string describing the assertion as parameter and will produce an SDL run-time error similar to the normal run-time errors. The function is only available if the compilation switch XASSERT is defined. For the standard libraries this is true for all libraries except the Application Library.
For some special SDL constructs, an SDT simulator is not able to continue executing without prompting the user for necessary input. The execution continues when the user has entered an allowed value.
If an SDL DECISION is encountered with an ANY question, the user will be prompted which path to execute:
Decision with ANY 1 (go path) 1 ? (show path) 2 (go path) 2 ? (show path) 3 (go path) 3 ? (show path) Enter path :
At this point, the user must enter a path value (integer) within the allowed range. If GR trace is enabled, the user may enter a path value followed by a `?' to see the corresponding path in an SDL Editor.
If an SDL DECISION is encountered with informal text, the user will be prompted which path to execute:
Informal decision: `Question1' `answer1' 1 `answer2' 2 `ELSE' 3 Enter path :
At this point, the user must enter a path value (integer) within the allowed range. If GR trace is enabled, the user may enter a path value followed by a `?' to see the corresponding path in an SDL Editor.
If an expression is encountered involving an operator that is not implemented, the user will be prompted for the value to be returned depending on the parameters:
Operator op in sort s is called Parameter 1: 50 Enter value(s) :
At this point, the user must enter a value in the resulting sort to be the returned value of the operator when called with the listed parameter values.
This section describes the appearance and functionality of the graphical user interface to the simulator monitor (SimUI). Some user interface descriptions general to all tools in Telelogic Tau can be found in User Interface and Basic Operations. These general descriptions are not repeated in this chapter.
A new SimUI is started by selecting SDL > Simulator UI from the Tools menu in the Organizer. When the SimUI is started, a number of definition files are read, controlling the contents of the main window and some status windows. See Definition Files for more information.
No simulator is started automatically by the SimUI in this way. The user must start a simulator by selecting Open from the File menu, as stated in the text area of the main window, or by using the Open quick button.
|
|
A simple way to generate a simulator, start the SimUI and open the simulator is to click the Simulate quick button in the Organizer. |
When a simulator is started, a file selection dialog may be opened if the SDL system contains external synonyms. For more information, see Supplying Values of External Synonyms.
The main window provides a text area (which displays output from the monitor system), an input line (used for entering and displaying textual command line input to the monitor system) and a button area with button modules (with buttons for execution of monitor commands).
|
|
The text area displays all text output from the monitor system, including user prompts, error messages and command results.
Commands cannot be entered in this area, but a command given on the input line or through the use of the command buttons is echoed after the displayed prompt:
Command :
The input line is used for entering and editing monitor commands from the keyboard. For information on available monitor commands, see Monitor Commands.
The 100 latest commands entered on the input line are saved in a history list. The history list can be traversed by using the <Up> and <Down> keys on the input line.
When <Return> is pressed anywhere on the input line, the complete string is saved in the history list and is moved to the text area. The command is then executed.
The input line also has an associated popup menu with the choices Undo, Command and Save:
.com).If a command entered on the input line requires additional user input (i.e. parameter values), the information will automatically be asked for in a dialog:
Each parameter dialog has an OK button for confirming the value and a Cancel button for cancelling the command altogether. Some parameters have a default value that does not have to be specified. In this case, an empty value or `-' is accepted for the default value.
Additional functionality is available in the dialog for enumeration type parameters:
Figure 435 : A typical selection dialog
|
|
In this dialog, the value can also be entered or edited on the text input line below the list in the dialog. The Sort button sorts all values in alphabetical order.
Name completion with the space character is provided. When you press <Space> after an initial string, the first value starting with the string will be selected (if any). Another <Space> will select the next value, etc. When there are no more matches, a space character will be added after the string you initially entered.
A slightly different name completion is provided with the `?' character. When you press `?' after an initial string, the first value containing the string will be selected (if any). Another `?' will select the next value. When there are no more matches, a `?' character will be added after the string you initially entered.
For those commands that take an optional variable component, the component must be entered on the text input line after the selected variable name, since it will not be asked for in a dialog. If a `?' is entered instead of a variable component, an additional dialog is opened in which the component can be selected. See the discussion of `?' in Examine-Variable.
If a command takes an output signal as parameter, and that signal have parameters, the signal parameters are asked for in a separate dialog. In this dialog, all parameters are listed with their default ("null") values, and they can all be edited in the same dialog. For more information, see Selecting Signal Parameters.
The button area is used for entering monitor commands by clicking the left mouse button on a command button. Each button corresponds to a specific monitor command. The buttons are divided into groups, roughly corresponding to the different types of commands listed in Simulating a System. Each group is shown as a module in the button area. Any number of button modules may reside in the button area. If the modules do not fit in the button area, a vertical scroll bar is added.
The definition of the buttons and button groups are stored in a button definition file (see Definition Files). New buttons can be added and existing ones deleted or redefined by using the Group menu in a button module.
To examine a button's definition without executing the command, the left mouse button is pressed on the button and the mouse pointer is moved outside the button. The command definition then appears in the status bar, but the command is not executed.
If a button's definition contains parameters, the parameter values are prompted for in dialog boxes before the command is executed, in the same way as described for commands entered from the input line. See Parameter Dialogs.
When no more parameter values are requested, the string shown on the input line saved in the history list and is moved to the text area. The command is then executed.
A button module looks like this:
|
|
Each module consists of a title bar and a number of command buttons arranged in rows and columns. The title bar displays:
The Group button contains the following menu items:
This menu choice adds a new button to the button module. A dialog prompts for the button label and the command to be executed when the button is pressed (see Figure 437). The new button is added to the end of the module. Several buttons may be added with the dialog by using the Apply button instead of the OK button.
Figure 437 : Adding a new button
|
|
For the syntax of a button definition, see the subsection Button and Menu Definitions.
This menu choice edits the label and definition of a button. The button to edit is selected in a dialog (see Figure 438). When a button has been selected, the label and definition can be edited using a dialog similar to Figure 437.
|
|
|
Note: On UNIX, if several buttons have the same button label, it is always the first button found that will be edited, independently of the selection. |
This menu choice deletes one or more buttons from the button module. The buttons to be deleted are selected in a dialog (see Figure 439).
Figure 439 : Deleting a button
|
|
|
Note: On UNIX, if several buttons have the same button label, it is always the first button found that will be deleted, independently of the selection. |
This menu choice edits the name of the current button module in a dialog (see Figure 440).
Figure 440 : Renaming a module
|
|
This menu choice deletes the current module from the button area. A dialog asks for confirmation.
The following tables list the default buttons in the button modules and the corresponding monitor command. See Monitor Commands for more information.
|
Note: The buttons in the button modules are specified in the button definition file. If the default button file is not used, the button modules may be different than described here. See Button and Menu Definitions for more information. |
| Button | Monitor command |
|---|---|
|
Symbol |
|
|
Transition |
|
|
Go |
|
|
Until Timer |
|
|
Break |
Pressing |
| Button | Monitor command |
|---|---|
|
Send To |
|
|
Send Via |
|
|
Send None |
| Button | Monitor command |
|---|---|
|
Process List |
|
|
Variable |
|
|
Var In Scope |
| Button | Monitor command |
|---|---|
|
MSC |
|
|
SDL |
|
|
TEXT |
This section describes the menu bar of the SimUI's main window and all the available menu choices. However, the Help menu is described in Help Menu.
The menu bar contains the following menus:
The File menu contains the following menu choices:
Restart the currently opened simulator. After user confirmation, the currently running simulator is stopped, the Watch window is updated, and the text area is cleared from previously executed commands.
The command is dimmed if no simulator has been opened.
The View menu contains the following menu choices:
Opens the Watch window displaying variable values in the simulation. If this window is already opened, the menu item is dimmed. See Watch Window for more information about this window.
Opens the Command window in which arbitrary monitor commands will be executed. If this window is already opened, the menu item is dimmed. See Command Window for more information about this window.
Opens the Watch and Command windows.
Closes the Watch and Command windows.
Clears the text area in the main window without affecting the simulation.
The Buttons menu contains the following menu choices:
For more information on the SimUI's button definition file mentioned in the menu commands below, see Definition Files.
Reads in a new button definition file that overrides the current button definitions. All buttons and modules currently in the button area are deleted and replaced by the buttons and modules defined in the new file. A File Selection Dialog is opened for specifying the file to load.
Appends the contents of a new button definition file into the current button definitions. Buttons with new labels are added to the button area, while buttons with already existing labels in the same module will be duplicated (possibly with different definitions). A File Selection Dialog is opened for specifying the file to append.
Saves the current button and module definitions in the button definition file under its current file name.
Saves the current button and module definitions in a new button definition file. A File Selection Dialog is opened for specifying the new file name.
Expands all modules in the button area.
Collapses all modules in the button area.
Adds one or more new button module after the last module in the button area. A dialog box is opened for specifying the name of the new module. Several modules may be added with the dialog by using the Apply button instead of the OK button.
The Log menu contains the following menu choices:
Start Command Log starts logging of monitor commands only, i.e. each string given to the monitor from the input line and via command buttons will be logged. A File Selection Dialog is opened for specifying the log file. If an already existing log file is selected, the user is asked whether to overwrite this file or to append the log to it.
Stop Command Log stops the command logging to the file. The appropriate menu choice is displayed depending upon the current state of the log.
Start Complete Log starts the logging of complete monitor interaction, i.e. the complete contents of the text area will be logged to a file. A File Selection Dialog is opened for specifying the log file. If an already existing log file is selected, the user is asked whether to overwrite this file or to append the log to it.
Stop Complete Log stops the complete logging to the file. The appropriate menu choice is displayed depending upon the current state of the log.
Displays the status of the command and complete logs in a dialog box. If a log is active, the name of the log file is shown.
In addition to the standard SimUI menus, a few special simulator menus are included in the menu bar. The menu choices in these menus simply execute a monitor command, i.e. they are functionally equivalent to buttons in the button modules. If the monitor command requires parameters, they are prompted for using dialogs in the same way as the command buttons.
The following tables list the default menu choices and the corresponding monitor command. See Monitor Commands for more information.
|
Note: The additional menus in the SimUI are specified in the button definition file. If the default button file is not used, the button modules may be different than described here. See Button and Menu Definitions for more information. |
| Menu choice | Monitor command |
|---|---|
|
Command |
|
|
Start SDT Env |
|
|
Version |
|
|
News |
| Menu choice | Monitor command |
|---|---|
|
Go |
|
|
Over Symbol |
|
|
Into Stmt |
|
|
Over Stmt |
|
|
Finish |
|
|
Until Time |
|
|
Until Trace |
|
|
Until Timer |
|
|
Script |
|
|
Stop Sim |
| Menu choice | Monitor command |
|---|---|
|
Ready Q |
|
|
Now |
|
|
Process List |
|
|
Input Port |
|
|
Signal |
|
|
Timer List |
|
|
Variable |
|
|
Call Stack |
|
|
Set Scope |
| Menu choice | Monitor command |
|---|---|
|
Ready Q |
|
|
State |
|
|
Create Process |
|
|
Stop Process |
|
|
Input Port |
|
|
Del Signal |
|
|
Set Timer |
|
|
Reset Timer |
|
|
Variable |
| Menu choice | Monitor command |
|---|---|
|
Next Symbol |
|
|
Prev Symbol |
|
|
C Line |
|
|
Coverage |
| Menu choice | Monitor command |
|---|---|
|
Text Level : Set |
|
|
- : Show |
|
|
SDL Level : Set |
|
|
- : Show |
|
|
MSC Level : Set |
|
|
- : Show |
|
|
MSC Trace : Start |
|
|
- : Start Batch |
|
|
- : Stop |
| Menu choice | Monitor command |
|---|---|
|
Transition |
|
|
Output |
|
|
Variable |
|
|
Symbol |
|
|
Connect sdle |
|
|
Remove |
|
|
Show |
The Command window is an optionally visible window used for displaying the results of executed commands. The Command window is opened from the SimUI's View menu.
Figure 441 : The Command window
|
|
The Command window is updated automatically whenever the monitor becomes active and after each monitor command. See Activating the Monitor for information on when the monitor becomes active. The window can also be updated manually with a menu command.
Any number of commands can be defined to be executed in the Command window. Each command is executed in a scrollable module in the window.
New commands can be added to the window and existing commands can be changed. The commands to execute are by default List-Process and List-Ready-Queue. The set of commands to execute are stored in a command definition file (see Definition Files). The default command definition file can be changed with the Preference Manager.
A command module looks like this:
|
|
Each module consists of a title bar and a scrollable text area for the command output. The title bar displays:
The Command button contains the following menu items:
Opens a dialog for editing the command executed.
Deletes the command and command module from the Command window.
Sets the size of the text area. A dialog is opened where the number of text rows can be set using a slider.
The File menu contains the following menu choices:
Reads in a new command definition file that overrides the current command definitions. All commands currently in the Command window are deleted and replaced by the commands defined in the new file. A File Selection Dialog is opened for specifying the file to load.
Appends the contents of a new command definition file into the current command definitions. New commands are added to the command window, but already existing commands are not affected. A File Selection Dialog is opened for specifying the file to append.
|
Note: Command names in a command definition file are case sensitive. If a command in an appended file already exists in the Command window, but with different case, the command will be duplicated. |
The Command menu contains the following menu choices:
Adds a new command to the Command window. A dialog box prompts for the new command. The new command module is added to the bottom of the window. For the syntax of a command definition, see Command Definitions.
Updates all command modules by executing the defined commands.
The Watch window is an optionally visible window used for displaying values of variables defined in the currently running simulation. The Watch window is opened from the SimUI's View menu.
|
|
The Watch window is updated automatically after each monitor command. The window can also be updated manually with a menu command.
The variables to display are selected with a menu command. The set of selected variables are stored in a variable definition file (see Definition Files).
The File menu contains the following menu choices:
Reads in a new variable definition file that overrides the current variable definitions. All variables currently in the Watch window are deleted and replaced by the variables defined in the new file. A File Selection Dialog is opened for specifying the file to load.
Appends new variable definitions to the current variable definitions file. The variables in the file are added to the Watch window. A File Selection Dialog is opened for specifying the file to merge. Duplicate variable definitions are permissible.
The Watch menu contains the following menu choices:
Updates the Watch window by showing the current value of all displayed variables.
Adds one or more variables to the Watch window. A dialog is opened for specifying the variable to be added (see Figure 444). For the syntax of a variable definition, see Variable Definitions. Several modules may be added with the dialog by using the Apply button instead of the OK button.
Figure 444 : Adding a variable
|
|
Edits a variable specification in the Watch window. The variable whose specification is to be changed is selected in a dialog. When a variable has been selected, the specification can be edited using a dialog similar to Figure 444.
Deletes one or more variables from the Watch window. The variables to delete are selected in a dialog (see Figure 445).
Figure 445 : Deleting a watch variable
|
|
Deletes all variables from the Watch window.
In the SimUI, the following types of information are stored on files:
At start-up of the SimUI, the files to read are determined in the following way:
def.btns, def.cmds and def.vars is used, respectively.Once a file has been found, it is read and the contents of the corresponding window are set up. If a file cannot be found, the corresponding window area becomes empty.
Each of three text files can contain comment lines starting with the `#' character. Empty lines are not discarded.
|
Note: When a file is read, no checks are made upon the relevance or correctness of the definitions contained in the file. |
Button and Menu DefinitionsThe button and menu definitions are stored in a button definition file with the default extension .btns. The button definitions are divided into groups where each group defines a button module in the main window's button area, or a menu in the main window's menu bar.
In the file, a button group has the following syntax:
:[COLLAPSED] <group name> <button label> <definition> <button label> <definition> . . .
The <group name> is the string shown in the title bar of the button module. If the group name is prefixed with the string COLLAPSED, the button module is initially collapsed. The <button label> is the label of the button in the button module. The <definition> is the monitor command that will be executed when the button is pressed. The syntax of a button definition is the same as when entering a command textually to the monitor.
A menu has the following syntax:
:MENU <menu name> <menu choice> <definition> <menu choice> <definition> . . .
The <menu name> is the name of the menu shown in the menu bar. The <menu choice> is the name of the menu choice in the menu. The <definition> is the monitor command that will be executed when the menu choice is selected.
In the monitor command definition, a `?' as parameter will not work, but a hyphen `-' can be used to signify the default value. Missing parameters at the end of the command will open dialogs for those parameters.
In addition, a button definition may consist of several monitor commands, if they are separated by a space and a semicolon, i.e. ";". The commands are then executed immediately after each other.
next-transition ; out-via probe -
This button definition executes the next transition and then sends the signal Probe from the environment.
Command DefinitionsThe command definitions are stored in a command definition file with the default extension .cmds. Each command definition defines a command module in the Command window. The file has the following syntax:
<command> <command> . . .
The <command> is the monitor command that will be executed in the command module. The syntax of a command definition is the same as when entering a command textually to the monitor. All parameter values must be specified explicitly or with the default value `-', i.e. `?' is not allowed, and no parameters may be missing. Command names are case sensitive.
|
Note: Care should be taken when deciding what command to execute; commands belonging to the Execute group should be avoided. |
Variable DefinitionsThe variable definitions are stored in a variable definition file with the default extension .vars. Each variable definition defines a variable to display in the Watch window. The file has the following syntax:
(<process>) <variable> (<process>) <variable> . . .
The <process> is the name of the process, possibly augmented with an instance number separated with a space or colon. The <variable> is the name of the variable in that process. Names are not case sensitive.
(Main) Count (game:1) guess
The following restrictions apply to the monitor input:
<Ctrl+C>, <Ctrl+D>, and <Ctrl+Z> are typical characters that might terminate a simulation program.There are a number of dynamic checks that are not performed at all or performed at the C level by the C runtime system. A C runtime error will of course lead to the simulation program being terminated. The following checks are not made at the SDL level.