This chapter describes how to run a simulator on a target and connect it to the SDT simulator interface (SimUI) on the host via TCP/IP communication.
A simulator executable (called simulator) communicates with the SDT tools, e.g. the Simulator UI (SimUI), via the SDT communication mechanism (the PostMaster). By using some special features it is possible to run the simulator on a target system (called target), while the SDT tools and Postmaster run on a host system (called host) separate from the target. This set-up is known as target simulation. This gives the possibility to test a simulator in its correct environment and still get the trace and debug possibilities offered by SDT.
For instance, the target could be a VME147 bus system running VxWorks, and the host is a Sun workstation running SunOS 5. The simulator running on the target is built using a special library, instead of the ordinary simulator library containing the simulator kernel. The special library contains the kernel for a simulator on VxWorks, as well as a communication interface to the host. On the host, the simulator is replaced by a gateway executable (called gateway) that communicates with the simulator on the target over the TCP sockets connection. Figure 464 shows the set-up for target simulation.
Figure 464 : Target simulation set-up
|
|
Simulators, as well as other executables communicating via the Postmaster, has a set of layers as shown in Figure 465, where the layers are represented by the files that implement them. All units (the Simulator, Postmaster and SimUI) are located on the same host machine.
Figure 465 : Architecture of an ordinary simulator
|
|
sctpost.c, post.o and a few other files are then linked into the simulator kernel used for making the simulator.
The basic principle of this target simulation is to direct the communication between the simulator and the Postmaster over a TCP sockets connection. This re-direction must be transparent to the simulator and to the Postmaster.
To direct the messages between the Simulator Monitor and the Postmaster through the TCP sockets, a new layer, implemented in the file tlayer.c, is introduced between sctpost.c and post.o according to Figure 466.
Figure 466 : tlayer.c is introduced
|
|
For the target, tlayer.c emulates post.o (the same interface), and for the host, tlayer.c emulates sctpost.c (the same interface). (In Windows NT there are other communication mechanisms on host than UNIX sockets.)
All configuration is made on host side in a file called tarsim.cfg. This file is searched by host.sct in a directory specified by the environment variables (searched in this order): $TARSIMPATH, $PWD, $HOME, $sdtdir.
In Windows NT, the only searched variables are %TARSIMPATH% and %sdtdir%. You set the environment variable %TARSIMPATH% as described below. You can also use the environment variable %sdtdir%, if you prefer having one single tarsim.cfg and want to put it there.
TARSIMPATH, and in the Value field enter the directory (including logical disk drive) where tarsim.cfg is located.The syntax of tarsim.cfg is described below. In the delivery, a sample tarsim.cfg is supplied.
tarsim.cfg #this is an example tarsim.cfg # locations are specified: #UNIT IP-ADDRESS (numeric) PORT NAME(optional, not used) TARGET 194.18.198.170 5000 VMEbus #host doesn't have to be specified, but can be done so by the following syntax: HOST 194.18.198.167 18000 mycomputer #type of communication, currently only TCP with target available. COM TARGET TCP # #you can make a signal log to trace signals sent between host and target. #Good for debugging and should be #used if you need to report problems to Telelogic. If you specify a file, #data is appended, you may need to #empty it if it grows too big.. You can also specify standard stdout and #stderr. If you don't use a file, stderr #is recommended, since host.sct is forked up by SIMUI and the output might end #up in an invisible subshell. Since stderr uses parent shell (terminal window #where SDT was started), you will see the output.. # NOTE!!! LOG and DEBUG in UNIX implementation only, not on Windows 95/NT LOG stderr #To set logging ON or OFF you do like this (default is OFF) DEBUG OFF # #USETIMEOUT makes it possible to halt or suspend the target in for instance #a C level debugger without the target terminating when it #gets out of synchronisation with the host. In stead it will try to #resynchronize and continue the simulation when the target #is running again. #USETIMEOUT ON/OFF (default on) # END
The last implemented command in tarsim.cfg is SDLPATH.
The reason for this is that when you generate C code from an SDL diagram with SDT, the absolute path to the various SDL source files is hardcoded into the C file. This path is passed to the MSC and SDL Editor if you have tracing to those. This can lead to difficulties if you have generated the code to the target system somewhere in the directory hierarchy where SDT editors cannot read. Provided you have a flat structure of your source code (i.e. all SDL files to one system in the same directory), you can instead in tarsim.cfg specify a new path where the editors should search for your source files. It is then up to you to make sure that both the original and the new path contains the same source code.
You must specify an absolute path. Example on UNIX:
SDLPATH /usr/home/myself/sdl/
The trailing path (the last slash) is optional; the parser will try to find it anyway and report problems upon invocation.
On UNIX, there is a very basic shell included in host.sct.
If you start host.sct without the target running, you will enter a shell where only the commands INIT (try contacting target again) and EXIT (quit session) are applicable. If you know your target is running and still do not get contact, please check that the specified IP address and PORT of the target in tarsim.cfg are correct. PORT is for the target hardcoded in tlayer.h, the header file for tlayer.c.
During simulation you can enter the tarsim shell by entering a ":" (colon). You can only leave the simulation if the simulator is not running with GO or FOREVER. If so, first stop the simulation with the Break button.
After entering the ":" you will see a welcome text to the shell. You can enter the command HELP to see the full command set, or STATUS to see the current simulation setup. You exit the shell by entering EXIT.
LOG and DEBUG has the same syntax and meaning as in .
tarsim.cfg
Addresses like TARGET and HOST, as well as the COM and SDLPATH statements, cannot be changed from the shell.
An additional facility for the logging is GREP, which gives a possibility to filter out up to 5 strings that you want to log and skip the rest.
To clear all GREP's and log everything:
GREP *
To add a string (this example looks for MSCE, i.e. signals to the MSC Editor):
GREP MSCE
Strings are not case sensitive by default. To search for the exact string MyPath/demo.sdt, prefix it with `=':
GREP =MyPath/demo.sdt
If you want to log everything except, for instance, signals to the SDL Editor you can use the prefix `!':
GREP !SDLE
|
Note: If you have GREP MSC active and then enter GREP !MSC, status will be changed of the previously entered argument, so you cannot enter two contradictions and have both active. |
You can also combine the inverse and exact functions:
GREP !=MyPath/demo.sdt
Up to five GREP arguments can be active simultaneously and each can be up to 25 characters long.
If the GREP buffer is full, empty the old with GREP *.
You can empty the buffer and enter new argument in one statement:
GREP * MSCE
When the simulator and gateway have been started, the simulator can be controlled from the Simulator UI on the host in the same way as an ordinary simulator. Differences may be seen in execution performance and in the printing of log messages. Using Open in the File menu in the SimUI, you specify the simulator file host.sct. After you have chosen this file, host.sct will try to establish contact with the target, according to settings in tarsim.cfg. This file must be in the same directory as host.sct, and SDT should also be started from this directory. (Setting Source Directory in the Organizer does not help SimUI find the target simulation file dependencies.)
The simulator on the target can be stopped by typing <Ctrl+C> on the console. It is though recommended only to stop the target by pressing the Exit button in the SimUI. The host.sct will then, before it finishes, send a stop signal to the target, and give it a chance to close all open file descriptors for TCP sockets. If not, you can get a bind error if you try to restart the target simulator without rebooting the target system.
The gateway on the host is terminated by issuing the command Exit or Quit in the SimUI.
fclose on open file descriptors upon kill. You will see the error message "bind (0x30)", meaning that bind fails since the target port address is busy. However, since enhanced shutdown and bind methods has been introduced, the risk of this has been reduced. host.sct <Ctrl+O> (shortcut for open file) to reopen the file. host.sct in the process list (ps -ef on Solaris) and kill it. Try 2-3 again. sdtsimui in the same way and restart it from the Organizer.
tarsim.cfg configuration file. Correct any incorrect IP address or port to the target (port is default 18000 except on VxWorks/VME) and restart host.sct like in step 2 above. The target's port is hardcoded into the file tlayer.h.Source code for the target contains of all the standard SDT Master Library, with the change that post.o does not contain any Postmaster, but a TCP socket communication program.
Both host and target use the same tlayer.c file, with the compile flags -DTARGET and -DHOST, respectively. Also the flag -DTCP need to be specified in both ends to get TCP functionality.
All other files in sctworld.o needs the flags -DTARGETSIM,
-D/compiler/, -D/rtos/, -DSCTDEBCLCOM and .
-DXMAIN_NAME=sdlmain
See the specific integrations for the RTOS and compiler specific flags.
The source file structure in tlayer.c is also documented in the top of tlayer.c in a comment.
To make the target you will need tlayer.c and tcp.c, along with the .h files which are supplied. A makefile is also provided.
Both target and host has been tested on Windows NT 4.0 and compiled with Borland C++ v5.0.
In the directory sdt/sdtdir/remsim/wini386 is a file called remsim.ide which is a Borland project file for generating targets. (Normally you will probably not run the target under Windows NT anyway; this is just for demo purposes).
The host part is called host.exe and is loaded into the SimUI the same way as on UNIX.
Both parts must be compiled as 32 bit applications, the target as a console and the host as a window application.
Due to the fact that there are no stdout or stderr when you run a Windows GUI application, together with the difficulties to determine the right directory to write to a file in, all debugging and logging facilities has been excluded. That means that the entries DEBUG, GREP and LOG in tarsim.cfg will be ignored. There is no extra Target Simulation Shell as on UNIX (which is not needed when you cannot do any message logging). None of this affects the target simulation as such.
It is considerably slower to do a remote simulation in Windows NT than on UNIX, even with the same system, same options, and running target and host on the same machine. There are ways to speed up the simulation. Recommended is to give set-tr 0 as the first command in SimUI. Then all textual tracing is stopped. Instead you can ask for the value of certain variables of interest. MSC trace and SDL trace works OK; MSC is the quicker of the two.
You can of course do a normal host simulation on the NT machine and then you have no limitations. Target simulation is not recommended to be used more than for the final fine tuning into the target environment.
It is especially important in Windows to use the option SDLPATH in tarsim.cfg if the target has been compiled on another system. The parser in host.exe can read NFS syntax "/path/" and will convert it to Windows/DOS syntax "\path\". The thing that cannot be fixed automatically is the correct logical drive letter. Hence you can specify where your SDL source files are with:
SDLPATH D:\path\sdlsource
in tarsim.cfg. Of course the source files must be the same as the ones the target was compiled from.