![]() |
![]() |
![]() |
![]() |
![]() |
Features
Partitioning
General Ideas
The partitioning concept is a way to divide one SDL system into several applications. As a special case this means also that it is possible to simulate and validate selected parts of a system. You should note the difference between partitioning and separation. The partitioning feature is a way to select the parts of an SDL system which should be handled, while the separation feature is a way to select the file structure for the generated files.
To select a partition (or a program) it is, in simple cases, possible to use selections in the Organizer, and in more general cases possible to work with build scripts, i.e. text files containing commands to the Analyzer (the syntax used when running the Analyzer stand-alone). The restriction in the Organizer view is that only one selection can be handled and that instantiation of OO types cannot be selected. In a build script on the other hand, several component commands can be used to select several parts of a system. As the component command takes an SDL qualifier as a parameter, instantiations can also easily be selected.
Using Selections in the Organizer
To start with the simple case when one block or process should be simulated, this is easy to perform directly from the Organizer: Select the proper block or process and press the Simulate button (or go via Make dialog).
Only the system, a block or a process can be selected for simulation. Types, including procedures, are only definitions and are not executable objects, while services depend on its enclosing process and cannot be simulated on its own because of these dependencies. Block and process instantiations can be simulated, but only using build scripts, as such objects cannot be selected in the Organizer. The discussion above is of course also valid for generation of explorers and applications.
Unconnected Diagrams
As another special case, there might be unconnected diagrams in the Organizer, i.e. objects not bound to a file. If such an object is a block, process, or a procedure, C code can anyhow be generated resulting in, for example, a Simulator or Explorer.
- If a block is unconnected, this is treated as an implicit partitioning excluding this block.
- If a process is unconnected, this is treated as an implicit partitioning excluding this process. If other processes try to "create" such a process, this will become a null-action just indicated in the textual trace. In an application, such a create action will cause a compilation error.
- If a procedure is unconnected, any call to this procedure is just indicated in the textual trace. In an application such a procedure call will cause a compilation error.
Build Scripts
In general cases, build scripts should be used to specify the build process. Using such a file there are a number of features that can be used.
- It is possible to generate code for several partitions, using independent options and potentially different code generators for different parts of the system, all in one build process.
- Each partition can consist of several objects, and objects might be instantiations.
There are two Analyzer commands, see Description of Analyzer Commands, that are of major interest for specifying a partition. First we have the Program command, which takes a name as parameter. Second we have the Component command, which takes a qualifier as a parameter. The Program command gives the start of a partitioning specification, while the Component command is used to select an SDL component that should be part of the partitioning. A partition specification can of course contain a number of components. The Component command is very similar to a selection in the Organizer when running directly from the Organizer.
A program section in a build script typically starts with a Program command and ends with a Generate command.
program MyExamplecomponent system example/block b1component system example/block b2/process p22target-directory /home/jk/example/targetset-env-header onset-modularity usergenerate-advanced-cIn Windows, the target-directory command could, for example, be:
target-directory c:\example\targetThe example above means that a program containing the implementation of the complete block b1 and the process p22 in block b2 is generated with the Cadvanced SDL to C Compiler. The modularity is user defined and a system header file (.ifc file) will also be generated.
Code from the code generators will be placed in a subdirectory with the name given in the Program command, to the directory given by target directory. If this subdirectory does not exist it will be created.
You should always include a target-directory command in a build script, as otherwise the target directory will depend on where the SDL Suite is started!
In the example above the generated C code can be found in the directory /home/jk/example/target/MyExample
(In Windows c:\example\target\MyExample).In the example below three programs are generated for three different partitionings, also using different code generators.
Example 354 : Build script with several programs
target-directory /home/jk/example/targetprogram MyExamplecomponent system example/block b1component system example/block b2/process p22set-env-header onset-modularity userset-kernel SCTDEBCOMgenerate-advanced-cprogram MyExample1component system example/block b2/process p21generate-micro-cprogram MyExample2component system example/block b3set-modularity nogenerate-chipsy-chillAnalyzer commands that are of the type "set up an option" can be placed outside of the Program commands. The options actually used at the generate commands, are the options set up after executing all the commands up to the generate command. All the possibilities in the Make dialog and the Analyze dialog in the Organizer are also provided as commands in the Analyzer. Please see The Analyzer Command Line UI, for a list of all commands.
When build scripts are used, all features in the Analyzer will have its hard coded defaults, if it is not set in the build script. Preferences and your settings in the Organizer are ignored. The default values are given in The Analyzer Command Line UI, or you can start a stand-alone analyzer (sdtsan) directly in an OS shell and issue the commands Show-Analyze-Options and Show-Generate-Options.
See also SDL Make, for handling of build scripts in the Organizer.
Behavior of Generated Partitioning
The basic idea is to redirect all channel going to objects not part of the current partitioning to the environment. This operation is performed by the code generator at code generation time. This means that all signals sent between objects in the partitioning and objects outside the partitioning, will be seen as signals to or from the environment. This is true everywhere, in simulations, validations, applications, in generated environment header files (.ifc files), and in generated environment functions.
Generation of Support Files
The Cadvanced/Cbasic SDL to C Compiler can generate a number of support files, together with the ordinary .c, .h, and makefiles. These files are
- System header file (.ifc)
- Skeleton to environment functions (_env.c)
- Signal number file (.hs)
- Coder/decoder framework files (_cod.c, _cod.h)
The generation of these files can be selected in the Organizer Make dialog, or as an Analyzer command, depending on which interface is used. The details on the system header files and the environment function can be found in The Environment Functions, while the signal number file can be used to assign numbers to all signals in the system. Signal number files are most used in connection with OS integrations.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |