The SDT Analyzer's primary task is to check SDL-92 diagrams (extended as defined in Compatibility with ITU SDL) with respect to syntactic and semantic rules. The Analyzer accepts both SDL-GR and SDL-PR as input, and has the ability to transform SDL-GR diagrams to SDL-PR files and vice-versa.
This chapter is a reference to the Analyzer commands. Its limitations according to the Z.100 recommendation is found in Analyzer.
For a guide to how to perform syntactic and semantic check on an SDL diagram structure, see Analyzing a System. This chapter also gives an overview of the Analyzer.
The Analyzer's graphical user interface is managed by the Organizer.
To start the Analyzer, select Analyze from the Organizer Generate menu or click the Analyze quick button. For more information, see Analyze and Quick Buttons.
The Analyzer's graphical user interface is further described in Using the Analyzer.
See SDT Batch Facilities for information on running the Analyzer non-interactively.
The Analyzer also has a command-line mode, when it is started from the OS outside the SDT graphical environment. This is the user interface that is described in the remainder of this chapter.
On UNIX, the Analyzer is started in command-line mode from the OS prompt with the command:
$sdtbin/sdtsan 1
In Windows, the Analyzer is started in command-line mode from a "DOS" prompt with the command:
sdtsan 2
When the Analyzer is started in command-line mode, it responds with the prompt
SDT Analyzer Command :
A command name may be abbreviated by giving sufficient characters to distinguish it from other command names. A hyphen ('-') is used to separate command names into distinct parts.
Any part may be abbreviated as long as the command does not become ambiguous.
Parameters to commands are separated by one or several spaces. In case you omit a parameter of type "on/off", the value currently defined will toggle between its "on" and "off" values.
In both command names and parameters there is no distinction made between upper and lower case letters.
|
Note: On UNIX systems, distinction is made between upper case letters and lower case letters for file names. |
In this section, the Analyzer commands are listed in alphabetical order, along with their parameters and a description.
<operating system command>
Escape to the shell to do command.
<Filespec>
Add a file to the list of files to be converted to PR. The file will be processed according to the setting of Input-Mode.
(None)
This command orders the Analyzer to perform the passes according to the Analyzer options as they are defined.
|
Hint: The current analysis options can be printed using the command |
The order in which the passes are performed is:
<directory>
Change current working directory to <directory>.
(None)
Force the Analyzer to perform all passes from scratch as defined in the Analyzer options on the previously selected input. See also the New command described in New.
[<SDL qualifier>]
Add a new item to a program. See Partitioning.
[<file spec>]
An optional file to store analyzer messages in. Default is no error file.
(None)
Terminates the Analyzer and returns you to the Operating System prompt.
[Command]
This command allows filtering or preprocessing files before they are read by the Analyzer. The supplied Command should be an executable file, preferably found in the user's path. The Analyzer appends two parameters to the supplied command. The first parameter is the name of the file and the second parameter tells what the Analyzer is about to do with the file; currently import (before converting to SDL-PR), macro (before macro expansion) and parse (before syntax analysis) is available. The supplied Command is supposed to modify the file given in the first argument and leave the result in the same file.
(None)
This command invokes the Cadvanced Generator, which will produce one / multiple C program(s), as well as a makefile. This C program is then compiled and linked in order to build up an executable application. The Cadvanced Generator uses the options which have been previously defined using the various Generate Options commands. See also Generate-Basic-C.
(None)
This command invokes the Cbasic Generator, which will produce one / multiple C program(s), as well as a makefile. This C program is then compiled and linked in order to build up an executable application. The Cbasic Generator uses the options which have been previously defined using the various Generate Options commands. This command cannot be used when building applications, but otherwise it is identical to Generate-Advanced-C.
(None)
This command invokes the CHIPSY CHILL Generator, which will produce one / multiple CHILL compilation unit(s). The CHILL program is then compiled and linked using build-in features in the CHIPSY environment to build an executable application program. The CHIPSY CHILL Generator uses the options which have been previously defined using the various Generate Options commands.
(None)
This command invokes the ETRI CHILL Generator, which will produce one / multiple CHILL compilation unit(s). The CHILL program is then compiled and linked using build-in features in the ETRI CHILL environment to build an executable application program. The ETRI CHILL Generator uses the options which have been previously defined using the various Generate Options commands.
(None)
This command invokes the Cmicro Code Generator, which will produce one / multiple C program(s), as well as a makefile. This C program is then compiled and linked in order to build up an executable application. The Cmicro Code Generator uses the options which have been previously defined using the various Generate Options commands. See also Generate-Advanced-C.
(None)
This command invokes the Samsung CHILL Generator, which will produce one / multiple CHILL compilation unit(s). The CHILL program is then compiled and linked using build-in features in the Samsung CHILL environment to build an executable application program. The Samsung CHILL Generator uses the options which have been previously defined using the various Generate Options commands.
[<file spec>]
This command specifies where the output of the conversion to PR pass is stored. Default is <infile>.pr.
<GR-File> <PR-File>
The command converts the file designated by the file specifier GR-File to a textual (i.e. PR) description of the diagram, storing the results in the file designated by the file specifier PR-File.
The file GR-File should contain an SDL diagram stored in SDT format.
<sdth2sdl options>
Options to be used by the H2SDL utility. See The H2SDL Utility for more information.
[Command]
The command issues on-line help for the Analyzer commands. Depending on if a command is specified or not, the following happens:
Topic?
<Enter> issues information about the command.<Enter> only, returns control to the Analyzer prompt.You can abbreviate any topic name, although ambiguous abbreviations result in all matches being displayed.
<file spec>
Execute analyzer commands in <file spec>.
ASN.1 | C-Header | GR | PR
Select filter to convert input to PR. Default is PR.
[<file spec>]
Where the instance tree is stored. Default is <system name>.ins. See SDL Instance Information for more information.
[<file spec>]
This command specifies where the output of the macro expander is stored. Default is <infile>.prm.
[<file spec>]
Name of makefile. Default is <system name>.m.
[<file spec>]
Name of make template file. Default is no template.
(None)
This command initializes the Analyzer. Following the New command, you will need to specify an input to the Analyzer using the Set-Input command.
See also Clear.
(None)
Creates a subprocess which returns you temporarily to the Operating System. Once you terminate this process, control is returned to the Analyzer.
Level Type Name File Sep SepName Selected [Depend]
Pass the Organizers info on a diagram to the Analyzer. This command is used by the Organizer.
<Filespec>
This command specifies where the output of the pretty printer is stored. Default is <infile>.sdl.
[<name>]
Name of program built from components. See Partitioning.
(None)
Synonym for exit.
(None)
The Organizer uses this to make sure the right version of the analyzer is running.
[On/Off]
This option informs the C code generators if the SDT C Compiler Driver should be invoked. See SDT C Compiler Driver (SCCD).
Default is off.
[On/Off]
This option informs the Code Generators (C Code Generators and CHILL Code Generators) whether the generated code should be compiled and linked automatically (by executing the generated makefile or calling the CHILL compiler environment).
Default is on.
[On/Off]
This option will print (echo) all Analyzer commands as they are executed. Default is off.
[On/Off]
This option informs the code generators (C Code Generators) if environment functions should be generated or not.
Default is off.
[On/Off]
This option is applicable to the C Code Generators only. With this parameter turned on, a header file containing the definitions of the SDL system's interface to the environment is created. This file is identified by the .ifc suffix.
Default is off.
<Errorlimit>
This command sets the limit of reported diagnostics (errors and warnings) after which the Analyzer will stop its execution. Use 0 to turn off the limit.
Default is a limit of 30 diagnostics.
[On/Off]
This option specifies whether include directives should be handled and expanded when reading input files. See Including PR Files.
Default is on.
<Depth>
This command instructs the Analyzer to issue a warning when the semantic analyzer encounters an SDL expression which is at least Depth deep.
Default is 0, meaning that no warnings will be issued.
[On/Off]
Redo everything if on. Default is off.
[On/Off]
When this option is on, the Analyzer allows implicit type conversion of reference data types (generators Own, ORef, and Ref). Note that analyzing large expressions with this option on is slow. Default is off.
For more information, see Implicit Type Conversions.
<Filespec>
The Analyzer will use the file specified in filespec as input file. The file will be processed according to the setting of Input-Mode (see Input-Mode). Use Add-Input to process a system stored in several files.
[On/Off]
With this option on, a file containing the SDL instance tree will be generated. Default is off. See SDL Instance Information for more information.
<Kernel>
This option is applicable to the C Code Generators only. (The CHILL Code Generators always generate code for execution on top of a CHILL Real-Time Operating System, CRS.) This option allows you to select the appropriate kernel with precompiled runtime libraries. The makefile generated by the C Code Generators contains instructions which link the generated and compiled code with object modules contained in the selected library. The effect of this will be that the code which is generated by the C Code Generators will have different properties, reflecting the purpose of its usage (simulation, application generation, etc.). The allowed values of the parameter kernel vary from one configuration to another. The definitions are made in the file sdtsct.knl. The definitions for Cadvanced are made in the file sdtsct.knl, whereas the definitions for Cmicro are made in the file scmsct.knl.
The following values are recognized for Cadvanced:
The following values are recognized for Cmicro:
|
Note: The predefined kernels for Cmicro cannot be used with any C compiler. They require GCC 2.8.1 on UNIX, or Borland C 5.02 or Microsoft Visual C++ 5.0 in Windows. |
[On/Off]
SDL does not distinguish between lower case letters (a..z) and upper case letters (A..Z), but the high level programming languages C and CHILL do. With this parameter turned on, the names of, for instance, variables in the generated C or CHILL code is written in lower case letters only. Otherwise, the case of an item in the SDL definition is used.
Default is off.
[On/Off]
Turns on or off the macro expansion pass. This option must be turned on if your diagram contains references to macro(s).
Default is off.
[On/Off]
This command affects an option which enables or disables the generation of a makefile in conjunction with generation of C code. The CHILL Code Generators ignore this option, as compile and link scripts are never generated.
Default is on.
[Modularity]
Allows to specify the modularity of the code generated by the code generators, e.g. the C Code Generator. This option affects how many files will be generated.
Three options for the parameter Modularity are available:
Default value is No.
<Filespec>
Allows you to save the information generated by the Analyzer in files with a different name, using Filespec as the base name.
File suffixes are appended automatically by the Analyzer.
[On/Off]
Turning this option on, the Analyzer will perform the PR to GR conversion pass. The steps are:
Step 3 is only performed when a PR to GR conversion is run from the Organizer. The request to put temporary files in the current working directory is ignored on the Windows platform (they end up in some temp directory).
Default is off.
[Prefix]
Allows you to specify what prefix the code generators add to SDL names in the generated code.
Possible values for the parameter prefix are:
Default is Full.
[On/Off]
Turning this switch on, a pretty printed PR file will be generated.
Default is off.
[On/Off]
This option allows you to disable the verification that exactly one reference corresponds to each remote definition.
Default is on.
[On/Off]
With this option turned on, the semantic check pass will be performed. Otherwise, the Analyzer will stop after the syntactic check.
Default is on.
See also Optimizing a System to Reduce Analysis Time.
[On/Off]
Code generators will generate a file with signal numbers if on.
Default is off
[On/Off]
This command informs the code generators whether to generate C (CHILL) code or not when a generate code command is given. The reason for disabling code generation is that you may want to produce a makefile only, without generating code.
Default is on.
[On/Off]
This option turns on or off the syntax analysis pass.
Default is on.
[On/Off]
Select between upper or lower case keywords in pretty printings.
Default is off (i.e. lower case letters).
[On/Off]
Print a message if an optional actual parameter is omitted.
Default is on.
[On/Off]
Print a warning message if an SDL signal output has a different semantic meaning between SDL 88 and 92.
Default is on.
|
Note: This command is particularly useful when working with SDT 2.X diagrams in an SDT 3.X environment (SDT 2.X supports SDL-88, while SDT 3.X supports SDL-92). |
[On/Off]
Print a message if trailing actual parameters are omitted.
Default is on.
[On/Off]
Print a message if an SDL definition is not used.
Default is off.
[On/Off]
With this option on, a file containing SDL Cross References will be generated. See SDL Cross-References.
Default is off.
(None)
This command lists the current Analyzer options.
(None)
Similar to Help. The commands are listed without the command parameters.
(None)
This command displays the code generator options as currently defined.
(None)
This command returns information about:
(None)
This command displays the version number of the Analyzer.
[<directory>]
The analyzer looks for include files in this directory.
Default is current working directory.
[<directory>]
Specifies the directory where the code generators puts their files.
Default is current working directory.
[<file spec>]
Specifies where the cross references are stored.
Default is <infile>.xrf.
The following commands can be used for instance in the case of malfunction or unexpected behavior. They are not described further within the scope of the user documentation.
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
(None)
During the first pass of the Analyzer, an SDL-PR file suitable for processing by the following passes (Macro Expansion or Syntax analysis) is produced. The resulting PR file is not intended to be read by the human, and is not formatted for that purpose. Conversion to PR is needed when input is not already in SDL-PR format, i.e, for SDL-GR diagrams, ASN.1 files, and C header files.
Several tools might be invoked through the PostMaster to perform the actual conversion:
Additional SDL-PR files may be copied into the output of this pass.
A number of checks are performed during this conversion pass. Many of these are actually syntactic in their nature. They may result in error messages; see Error and Warning Messages.
A macro is a form of text substitution used in the SDL system definitions. In a macro definition, a collection of lexical units is defined. A macro call indicates where the text from the macro definition body is to be included. All macro calls must be expanded before further analysis of the system definition can be done.
The name of the macro definition is visible in the whole system definition. A macro call may appear before its corresponding macro definition. A macro definition may contain macro calls, but not calls to itself, directly or indirectly.
A macro may use parameters, called formal parameters, in macro definitions and actual parameters in macro calls. There must be an equal number of formal parameters and actual parameters in corresponding macro definitions and macro calls. Using multiple formal parameters with the same name is not allowed.
When a character string is used as an actual parameter, the value of the character string will be used to replace the formal parameter in the macro body and not the character string itself.
The keyword MACROID may be used in a macro definition body only. The MACROID keyword will be replaced by a unique name at each expansion of the macro (that is, only one unique name is available at each expansion of a macro definition). New names can be constructed by concatenating names, parameters and MACROID using a percent sign (%) as a separator.
The reserved word MACRODEFINITION is not allowed inside a macro definition. The reserved words MACROID and ENDMACRO are only allowed inside a macro definition.
Macro expansion follows this order:
The syntax checks made in the macro parser are entirely specific to macros since no other checks are possible until all macro calls are expanded. Some semantic checks are made during the expansion. These may produce error messages; see Error and Warning Messages.
Constructs such as:
macro test('if par3 then',
'if not par3 then',
'k<0') ;
where the text par3 in the first and second parameter strings is intended to be replaced by the third formal parameter in the macro definition will not work. This is because all formal parameters are replaced with actual parameters in a single step.
The reserved word MACROID is replaced by a unique name consisting of the string "XMID" and an integer. To assure system wide uniqueness the name is tested against all existing names in the system and the integer will be increased until the name is unique.
The scanner (lexical analyzer) reads the input file and passes on lexical units to the parser. The parser checks the syntax and builds an internal representation (an abstract syntax tree) for the SDL specification.
The lexical and syntactic analysis may be performed not only on complete system definitions, but also on the following SDL units:
If no errors are found during the syntactic analysis, the syntax tree can be passed to the pretty-printer and, if the input is a system or package definition, to the semantic analyzer. For a description of the errors that can produced, see Error and Warning Messages.
You may perform analysis on separate SDL units. The units that can be handled (other than system) are:
|
Note: When performing separate analysis on a package, referred packages must be supplied as well. |
If a unit is given without context, only syntactic checking can be performed. But, if the unit's placement in the system (that is, its context) is also given, both the syntactic checking and most of the semantic checking can be performed. The context of a unit is its enclosing scope units including the definitions that are not referenced, i.e. remote diagrams are excluded.
In the Analyzer, the context is specified in the Organizer tree structure if the input is a GR diagram. The diagrams surrounding the diagram that is to be separately analyzed and the diagrams inside that diagram are translated to PR and analyzed. No errors will occur due to missing remote diagrams, except missing remote diagrams inside the separately analyzed diagram. See Performing Syntax Check.
If the input is a PR file, there is no way to specify what part of the system to Analyze. Only syntax analysis is available on incomplete systems in PR form. See Converting SDL-PR to SDL-GR.
The Analyzer allows the user to divide the SDL description into a number of separate PR files. (The macro expansion can, however, only handle one file at a time.) It may, for example, be convenient to have the system level data type definitions in a separate file. A separate file is included by adding an include directive to the SDL description.
The include directive is #INCLUDE followed by the name of the file which should be surrounded by single quotation marks. The directive should be placed in an SDL comment, directly after the comment start ("/*"), at the place where the file should be included.
<TAB> characters are however not allowed.<TAB> characters are however not allowed.System Example; /*#INCLUDE 'DataDefs.pr' */ /*#INCLUDE 'BlockA.pr' */ EndSystem Example;
The Analyzer will search for included SDL-PR files in the following order:
HOME.$telelogic/sdt/include/ADT (on UNIX), or <SDT installation directory>\sdt\include\adt (in Windows)The PR to GR Converter performs a conversion from SDL-PR files into SDL-GR diagrams. (It is also possible to input SDL-GR diagrams, which transforms them to new SDL-GR diagrams, applying default layouting algorithms.)
Conversion is done on a one-diagram-per-file basis, meaning that each generated GR diagram will be stored on one file. However, entering a PR file may generate multiple GR diagrams, depending on the contents of the PR file.
The Analyzer passes which are performed are:
The result from the PR to GR conversion is a number of SDL-GR binary files. Each diagram will be stored on one file.
To reconstruct the SDL diagram structure, the Organizer's command Import SDL should be used (see Import SDL).
The Analyzer has the ability to produce listings of SDL entities and references to these definitions. In one file, all definitions of entities in an SDL system will be gathered, along with cross references to these entities. Entities mainly used to indicate structure (such as system, block, substructure, process, procedure, and service), as well as entities defining objects (such as signals, variables and sorts) will be considered as definitions.
The file, which is described further below, is a plain text file.
|
Note: SDT has support for graphical presentation of a cross-reference file, using an SDL-like graphical notation. To achieve this, you can use the Index Viewer. See The Index Viewer. |
The file name will be <unitname>.xrf for the cross references file, where <unitname> is the name of the SDL unit selected for analysis. Alternatively, the file name is to be supplied by the user when running the Analyzer from the Organizer.
If an SDL system is selected for analysis, all definitions and cross references are generated; while if case of a non-SDL system unit, definitions and cross references in the following units are generated:
The following entities will be part of the files:
For each definition of any kind mentioned above the following information is generated:
ScopeLevel EntityType EntityName Reference
For each entity used to indicate structure (system, block, substructure, process, procedure, service) there is a header consisting of three additional lines, which should be considered as a comment to increase the readability.
2 SIGNAL Bump \ SDTREF(SDL,/usr/tom/demongame.ssy(1),122(40,30),3)
The definitions are generated in pre-order (prefix walk in the tree formed by the definitions). This means that an entity is always followed by the entities defined within the entity. It also means that an entity at level N is defined in the first entity at level N-1 found when scanning upwards in the file.
For each place where an entity is used, information about that cross reference is generated:
4 DCL Count \
#SDTREF(SDL,/usr/tom/game.spr(1),179(80,10),2)
TASK \
#SDTREF(SDL,/usr/tom/game.spr(1),137(30,40),1)
OUTPUT \
#SDTREF(SDL,/usr/tom/game.spr(1),128(80,55),2)
Cross references consist of a keyword, describing where the reference was found, and the SDL reference. In Example 173, the variable Count is referenced in a task symbol and in an output. All cross references for an entity are placed immediately after the line for the definition.
|
Note: Entities used to indicate structure can also have cross references (procedure call, process create). |
The Analyzer supports the generation of a so-called instance information file, with the file extension .ins. This file contains various kinds of information about an SDL system. Similar to a cross reference file, it is a plain text file. The file syntax is described in detail in File Syntax. The Analyzer invokes a tool called the SDT Instance Generator to produce the instance information out of an analyzed SDL system.
The information that can be found in an instance information file helps to answer many questions. For example:
The Analyzer provides two commands to use the SDT Instance Generator from the command line user interface. These commands are described in The Analyzer Command-Line UI but are repeated here for the sake of completeness.
[On/Off]
This command sets an option that specifies whether an instance information file should be generated or not when the SDL system is analyzed. The option is by default off.
<file spec>
This command sets the name of the instance information file. The default filename is <systemname>.ins, where <systemname> is the name of the analyzed SDL system.
The SDT Instance Generator can also be started from the Analyzer's graphical user interface. This is done in a way similar to how cross reference files are generated. In the Analyze dialog in the Organizer, you can check a button to make the Analyzer call the SDT Instance Generator when the system has been analyzed. From this dialog it is also possible to set the name of the generated instance information file.
|
Note: The SDT Instance Generator is automatically invoked to produce the information needed by tools such as the State Matrix Viewer. |
An instance information file consists of a fileheader followed by a list of records:
<fileheader> <record> <record> ... <record>
The <fileheader> is a string telling which version of the SDT Instance Generator that has generated the file. Each <record> describes an SDL entity according to the following format:
<level> <entity class> <name>
<attribute> = <value>
...
<attribute> = <value>
.
The <level> is a number that tells at what depth in the "instance tree" the entity was found. For example, the system entity has level 1, a block entity in the system has level 2, a process entity in the block has level 3, and so on.
Attributes can be divided into three distinct categories depending on the format of their values:
<attribute> = <single value>
<attribute> = ( <single value> <single value> ... <single value> )
<attribute> = ( <single value> <single value <single value> <single value> ... <single value> <single value> )
Sometimes an attribute is omitted from a record. This happens when the value of the attribute is an empty string or list.
The table below lists all entity classes for which information is generated in an instance information file. The attributes of the entities are also described, together with the category of the attributes (1, 2 or 3 according to above).
In the descriptions, the following terms are used:
| Entity class | Attribute | Category | Description |
|---|---|---|---|
BLOCK |
InstRef |
1 |
An SDT reference to the definition of this block. |
|
|
ConnectionOut |
2 |
The names of the channels that are on the outside of this block. |
|
|
ConnectionIn |
2 |
The names of the channels or signalroutes that are on the inside of this block. |
BLOCK_INST |
InstRef |
1 |
An SDT reference to the definition of this block instance. |
|
|
TypeRef |
2 |
SDT references to block type definitions. The first reference is to the block type from which this block instance is instantiated, followed by references to its supertypes all the way to the block type on top of the inheritance hierarchy. |
CALLED_ PROCEDURE |
InstRef |
1 |
An SDT reference to the definition of this called procedure. |
CHANNEL |
InstRef |
1 |
An SDT reference to the definition of this channel. |
|
|
SignalSet |
3 |
The signals that are conveyed on this channel in the direction from the From-entity to the To-entity. Each signal is described by its name followed by an SDT reference to the definition of the signal. |
|
|
SignalSetRev |
3 |
As SignalSet but for the signals that are conveyed in the opposite direction. |
|
|
From |
1 |
The name of the block or block instance from which this channel starts. If the channel starts from the environment surrounding the system, system instance, block or block instance where this channel is located, this attribute is "env". |
|
|
FromVia |
1 |
This attribute is specified when the From-entity is a block instance, and is then the name of the gate of that block instance to which this channel is connected. |
|
|
To |
1 |
The name of the block or block instance to which this channel leads. If the channel leads to the environment surrounding the system, system instance, block or block instance where this channel is located, this attribute is "env". |
|
|
ToVia |
1 |
This attribute is specified when the To-entity is a block instance, and is then the name of the gate of that block instance to which this channel is connected. |
CHANNEL_ SUBSTRUCTURE |
InstRef |
1 |
An SDT reference to the definition of this channel substructure. |
CONTINUOUS_ SIGNAL1 |
InstRef |
1 |
An SDT reference to the definition of this continuous signal. |
|
|
InType |
1 |
The name of the state-containing entity in which this continuous signal is defined. |
|
|
Outputs |
3 |
The output signals that might be sent in the transition that is initiated by this continuous signal. Each signal is described by its name followed by an SDT reference to one of the output symbols in the transition that contains that name. |
|
|
Calls |
3 |
The procedures that might get called in the transition that is initiated by this continuous signal. Each procedure is described by its name followed by an SDT reference to one of the symbols in the transition that contains a call to a procedure with that name. This name is also the name of a CALLED_ |
|
|
NextStates |
3 |
The states that might become the nextstate after the transition that is initiated by this continuous signal. Each state is described by a name followed by an SDT reference to one of the state symbols that contains that name. |
ENABLING_ CONDITION |
InstRef |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
InType |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Outputs |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Calls |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
NextStates |
3 |
See the description for CONTINUOUS_ SIGNAL. |
GATE |
InstRef |
1 |
An SDT reference to the definition of this gate. |
|
|
SignalSet |
3 |
The signals that are conveyed through this gate in to the block instance, process instance or service instance to which the gate belongs. Each signal is described by its name followed by an SDT reference to the definition of the signal. |
|
|
SignalSetRev |
3 |
As SignalSet but for the signals that are conveyed in the opposite direction. |
INPUT |
InstRef |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
InType |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Outputs |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Calls |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
NextStates |
3 |
See the description for CONTINUOUS_ SIGNAL. |
PRIORITY_ INPUT |
InstRef |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
InType |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Outputs |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Calls |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
NextStates |
3 |
See the description for CONTINUOUS_ SIGNAL. |
PROCESS |
InstRef |
1 |
An SDT reference to the definition of this process. |
|
|
IniNoOfInst |
1 |
The initial number of dynamic instances of this process. |
|
|
MaxNoOfInst |
1 |
The maximum number of dynamic instances of this process. If this attribute is omitted it means that there is no upper limit on the number of dynamic instances. |
|
|
SignalSet |
3 |
The signals that can be received by this process. This set of signals is commonly known as the valid input signal set of the process. Each signal is described by its name followed by an SDT reference to the definition of the signal. |
|
|
ConnectionOut |
2 |
The names of the signalroutes that are on the outside of this process. Naturally, this attribute is only present when the process consists of services. |
|
|
ConnectionIn |
2 |
The names of the signalroutes that are on the inside of this process. Naturally, this attribute is only present when the process consists of services. |
PROCESS_ INST |
InstRef |
1 |
An SDT reference to the definition of this process instance. |
|
|
TypeRef |
2 |
SDT references to process type definitions. The first reference is to the process type from which this process instance is instantiated followed by references to its supertypes all the way to the process type on top of the inheritance hierarchy. |
|
|
IniNoOfInst |
1 |
The initial number of dynamic instances of this process instance. |
|
|
MaxNoOfInst |
1 |
The maximum number of dynamic instances of this process instance. If this attribute is omitted it means that there is no upper limit on the number of dynamic instances. |
|
|
SignalSet |
3 |
The signals that can be received by this process instance. This set of signals is commonly known as the valid input signal set of the process instance. Each signal is described by its name followed by an SDT reference to the definition of the signal. |
SAVE |
InstRef |
1 |
An SDT reference to the definition of this save. |
|
|
InType |
1 |
The name of the state-containing entity in which this save is defined. |
SERVICE |
InstRef |
1 |
An SDT reference to the definition of this service. |
SERVICE_ INST |
InstRef |
1 |
An SDT reference to the definition of this service instance. |
|
|
TypeRef |
2 |
SDT references to service type definitions. The first reference is to the service type from which this service instance is instantiated followed by references to its supertypes all the way to the service type on top of the inheritance hierarchy. |
SIGNALROUTE |
InstRef |
1 |
An SDT reference to the definition of this signalroute. |
|
|
SignalSet |
3 |
The signals that are conveyed on this signalroute in the direction from the From-entity to the To-entity. Each signal is described by its name followed by an SDT reference to the definition of the signal. |
|
|
SignalSetRev |
3 |
As SignalSet but for the signals that are conveyed in the opposite direction. |
|
|
From |
1 |
The name of the process, process instance, service or service instance from which this signalroute starts. If the signalroute starts from the environment surrounding the block, block instance, process or process instance where this signalroute is located, this attribute is "env". |
|
|
FromVia |
1 |
This attribute is specified when the From-entity is a process instance or a service instance, and is then the name of the gate of that process instance or service instance to which this signalroute is connected. |
|
|
To |
1 |
The name of the process, process instance, service or service instance to which this signalroute leads. If the signalroute leads to the environment surrounding the block, block instance, process or process instance where this signalroute is located, this attribute is "env". |
|
|
ToVia |
1 |
This attribute is specified when the To-entity is a process instance or a service instance, and is then the name of the gate of that process instance or service instance to which this signalroute is connected. |
START2 |
InstRef |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
InType |
1 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Outputs |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
Calls |
3 |
See the description for CONTINUOUS_ SIGNAL. |
|
|
NextStates |
3 |
See the description for CONTINUOUS_ SIGNAL. |
STATE |
InstRef |
2 |
SDT references to the state symbols in the state-containing entity that contain the name of this state. If the state-containing entity is a process type, service type or procedure, occurrences in the supertypes are also included. |
SUBSTRUCTURE |
ConnectionOut |
2 |
The names of the channels that are on the outside of this substructure. |
|
|
ConnectionIn |
2 |
The names of the channels or signalroutes that are on the inside of this substructure. |
SYSTEM |
InstRef |
1 |
An SDT reference to the definition of this system. |
SYSTEM_INST |
InstRef |
1 |
An SDT reference to the definition of this system instance. |
|
|
TypeRef |
2 |
SDT references to system type definitions. The first reference is to the system type from which this system instance is instantiated followed by references to its supertypes all the way to the system type on top of the inheritance hierarchy. |
Information about the entities is generated in pre-order (prefix walk in the instance tree). This means that an entity is always followed by the entities defined within itself.
A formal and complete description of the general format of an instance information file would be rather complex, and is beyond the scope of this text. Instead, see Example 174:
Consider the SDL system below:
System ExSystem;
Signal Sig(Integer), Inp;
channel ExChannel
from ExBlock to env with Sig;
from env to ExBlock with Inp;
endchannel ExChannel;
block ExBlock referenced;
endsystem ExSystem;
Block ExBlock;
signalroute ExSignalRoute
from ExProcess to env with Sig;
from env to ExProcess with Inp;
process ExProcess referenced;
connect ExChannel and ExSignalRoute;
endblock ExBlock;
Process ExProcess;
DCL Counter Integer;
procedure ExProcedure referenced;
start ;
task Counter := 0;
grst4:
nextstate Wait;
state Wait;
input Inp;
task {
Counter := call ExProcedure(Counter);
};
output Sig(Counter);
join grst4;
endstate;
endprocess ExProcess;
Procedure ExProcedure;FPAR a Integer;RETURNS ret Integer;
start ;
nextstate Idle;
state Idle;
input *;
task {
ret := a+1;
};
return ;
endstate;
endprocedure ExProcedure;
The instance information file for this SDL system will look like this:
SDTINST V1.0
1 SYSTEM ExSystem
InstRef = #SDTREF(TEXT,ExSystem.pr,1)
.
2 CHANNEL ExChannel
InstRef = #SDTREF(TEXT,ExSystem.pr,3)
SignalSet = (
Sig #SDTREF(TEXT,ExSystem.pr,2)
)
SignalSetRev = (
Inp #SDTREF(TEXT,ExSystem.pr,2)
)
From = ExBlock
To = env
.
2 BLOCK ExBlock
InstRef = #SDTREF(TEXT,ExSystem.pr,10)
ConnectionOut = (
ExChannel
)
ConnectionIn = (
ExSignalRoute
)
.
3 SIGNALROUTE ExSignalRoute
InstRef = #SDTREF(TEXT,ExSystem.pr,11)
SignalSet = (
Sig #SDTREF(TEXT,ExSystem.pr,2)
)
SignalSetRev = (
Inp #SDTREF(TEXT,ExSystem.pr,2)
)
From = ExProcess
To = env
.
3 PROCESS ExProcess
InstRef = #SDTREF(TEXT,ExSystem.pr,18)
IniNoOfInst = 1
SignalSet = (
Inp #SDTREF(TEXT,ExSystem.pr,2)
)
.
4 START Start
InstRef = #SDTREF(TEXT,ExSystem.pr,21)
InType = ExProcess
Nextstates = (
Wait #SDTREF(TEXT,ExSystem.pr,24)
)
.
4 STATE Wait
InstRef = (
#SDTREF(TEXT,ExSystem.pr,25)
)
.
5 INPUT Inp
InstRef = #SDTREF(TEXT,ExSystem.pr,26)
InType = ExProcess
Outputs = (
Sig #SDTREF(TEXT,ExSystem.pr,30)
)
Calls = (
ExProcedure #SDTREF(TEXT,ExSystem.pr,28)
)
Nextstates = (
Wait #SDTREF(TEXT,ExSystem.pr,24)
)
.
4 CALLED_PROCEDURE ExProcedure
InstRef = #SDTREF(TEXT,ExSystem.pr,20)
.
5 START Start
InstRef = #SDTREF(TEXT,ExSystem.pr,36)
InType = ExProcedure
Nextstates = (
Idle #SDTREF(TEXT,ExSystem.pr,37)
)
.
5 STATE Idle
InstRef = (
#SDTREF(TEXT,ExSystem.pr,38)
)
.
6 INPUT Inp
InstRef = #SDTREF(TEXT,ExSystem.pr,39)
InType = ExProcedure
Nextstates = (
return #SDTREF(TEXT,ExSystem.pr,43)
)
.
Errors may be detected both during interaction with the user (command interpretation) and during analysis. Errors are displayed on the screen and optionally appended to an error file supplied by the user. When using the graphical UI, messages are directed to the Organizer log window.
Errors that occur during command interpretation are errors due to:
Errors may be found during the various steps of the analysis. The different types of diagnostics and the format of the messages are described below. The messages are listed in Error and Warning Messages.
Errors can be of the following types: warning, error, internal error, and information.
There are different types of warnings:
One type of error is detected; violation of an SDL rule.
Internal errors due to malfunction of the Analyzer are detected. An internal error often has its roots in an SDL error from which the Analyzer did not recover properly.
Often used to provide additional information to the other types of messages.
Messages generally consist of the following parts:
The message describing the error includes a text line where the illegal construct is indicated with a "?". If the trace back is common to many lexical or syntactic errors, the trace back will only occur after the last of these error messages.
The error also contains a reference to the source file.
#SDTREF(SDL,/usr/tom/game.spr(1),137(30,40),1,11)
ERROR 312 Syntax error in rule VARIABLE, symbol = found but one of the following
expected:
! ( :=
task Count=0 ;
?
The interpretation of the error message is that the Analyzer found the symbol "=" when it expected one of the symbols "!" (the field selector), "(" or ":=".
In the current example, the assignment statement can be found in position 11 the first line in the object with the ID 137 at position (30, 40) on page 3, on page 1 in the diagram stored on file /usr/tom/game.spr.
The message describing the error includes, if possible, a line containing the error, with a "?" immediately preceding the SDL item that caused the error.
The error also contains a reference to the source file.
#SDTREF(SDL,/usr/tom/game.spr(1),296(55,40),1) ERROR 88 Undefined procedure call ? ErrorHandler
The interpretation of this error message is that the procedure ErrorHandler is referred to but not is defined, and the call can be found in page 1 of the diagram stored on the on file /usr/tom/game.spr, in line 1 of the object with ID 296 and at position (55, 40).
When a diagram is being analyzed, a number of files are generated. The file names consist of the diagram name appended with a file extension. The following file extensions are used:
.pr
.prm .pr file is used as input and expanded into a .prm file, which includes the SDL macros in an expanded form. The appearance of this file makes it not suitable to be read by the human.
.sdl
.err
.xrf
.tsp
The file contains time stamp information from the last analysis..ins
The file containing instance information about the analyzed SDL system. Read more about the contents of this file in SDL Instance Information.
predef.sdl
This file contains predefined SDL entities that the Analyzer needs access to in order to function properly. The file is found using the procedure in Search Order for Included PR Files with the directory $sdtdir.