The simulation program running on the target system must be built using a special library that includes a communication interface to the host system. On the host system, the simulation program is replaced by a gateway, a program that communicates with the simulation program on the target system. The host and target communicate via a standard RS-232C connection using a simple protocol. Figure 541 shows the set-up for target simulation.
Figure 541 : Target Simulation Set-up. ----- (fig) -----Target simulation can be valuable in the following situations:
----------------------------------------------------------------------- Caution! The following description of target simulation is not to be consid ered as generally applicable. The source code is provided "As is" and is intended to be used for the set-up described above. This set- up was chosen as a typical example of when target simulation may be useful. The use of target simulation for other set-ups is not docu mented. There is no commitment from Telelogic to support the example in this section. Telelogic has used the example in internal projects with successful results. -----------------------------------------------------------------------
---------------------------------------------------------------- Note: The target simulator can only be built by customers who have pur chased the Master Library. ----------------------------------------------------------------
The source code needed to build the gateway can be found in the directory $sdtrelease/examples/tarsim/gate. This directory also includes an already built executable for a SPARC system. To build the gateway for other UNIX platforms, use the provided UNIX makefile. In addition to the provided source code, the SDT library post.o and the SDT header files in $sdtdir/INCLUDE are used to build the gateway.
When building the gateway, the following compilation switches are recognized. If used, they should be included in the makefile in -D statements to the C compiler.
----------------------------------------------------------------- Switch Behavior if switch is defined ----------------------------------------------------------------- XNOPROTO Function prototypes according to ANSI-C are not used. (Should be defined for non-ANSI C compil ers.) XNO_STDARG_H Functions with variable number of parameters are handled according to the non-ANSI standard (varargs.h). (Should be defined for non-ANSI C compilers.) SENDSYNC The gateway will send "OK\r" to try to sync with the target. (Should always be defined on the host system.) ANSWER Return codes from functions for sending PostMas ter messages from the simulator are propagated back to the target. If not defined, all PostMaster messages from the simulator are assumed to be received correctly by the PostMaster on the host. Also see the subsection "Message Format" on page 1877. -----------------------------------------------------------------
------------------------------------------------------------------- Note: How to build the new Simulator library and the target simulator on UNIX systems is not described in this section. For information on building a new library on UNIX systems, see chapter 36, The Master Library, section "Creating a New Library" on page 2289. -------------------------------------------------------------------
-------------------------------------------------------------------- Switch Behavior if switch is defined -------------------------------------------------------------------- IC86 Code specific to the Borland or Microsoft C compiler on PC systems is used. XNOPROTO Function prototypes according to ANSI C are not used. (Should be defined for non-ANSI C compilers.) XNO_STDARG_H Functions with variable number of parameters are handled according to the non-ANSI stan dard (varargs.h). (Should be defined for non- ANSI C compilers.) SENDSYNC The communication interface will send "OK\r" to try to sync with the host. (Should not be defined on the target, since this slows down the simulator.) ANSWER Return codes from functions for sending PostMaster messages from the simulator are propagated back to the target. If not defined, all PostMaster messages from the simulator are assumed to be received correctly by the Post Master on the host. Also see the subsection "Message Format" on page 1877. TARGETSIM The <mode> parameter to the simulator is rec ognized (described below). (Should always be defined.) SCTDEBCOM
A Simulation library is used. (One of the three SCTDEBCLCOM
should always be defined.) SCTDEBCLENVCOM XCHECKALLOC Memory is checked when allocating; exit if all memory is used. XNOERRORTRACE No error messages are printed if trace is on and the connection to the host is lost. Also see the section "Executing and Terminating the Simula tion" on page 1875. --------------------------------------------------------------------
ln -s $sdtrelease/examples/tarsim/gate/sdtatgate \In this way, you can use the Simulator UI command from Organizer to start the simulation. The .sct file is then found and the gateway is started automatically.
DemonGame.sct
<simulator> -post <SPId> <mode>where
The target simulator is terminated by using the monitor command Exit or Quit. Terminating the graphical user interface to the Simulator (SimUI) by using the Exit command in the File menu, or by exiting SDT, does not terminate the target simulator. Instead, the following things occur:
Example 55 : PostMaster Message FormatA message consisting of the header "1" and the data "123" is sent by using the following characters:
+31313233-c7A received message is always acknowledged by sending a single "Y" back.
The possible messages from target to host are:
------------------------------------------------------ Header Data Description ------------------------------------------------------ "1" -- Call to PostMaster function SPInit "2" -- Call to PostMaster function SPExit "3" PostMaster Call to PostMaster function message SPSendToTool and / or SPSendToPid "4" PostMaster Call to PostMaster function message SPBroadcast ------------------------------------------------------The possible messages from host to target are:
-------------------------------------------------------------- Header Data Description -------------------------------------------------------------- "1" PId Response to target message "1". "1" -- Response to target message "2". "5" PostMaster Message to simulator received from message PostMaster (unless it is a SESTOP mes sage; see below). "6" -- Connection broken. Sent by the gateway before it exits, after receiving a SESTOP message from the PostMaster. "0" -- Response to target message "3" or "4", indicating no error from the PostMaster (SPOK). This is only sent if the compila tion switch ANSWER was used. "1" -- Response to target message "3" or "4", indicating an error from the PostMaster (SPERROR). This is only sent if the compilation switch ANSWER was used. --------------------------------------------------------------For information about PostMaster messages and functions mentioned above, see chapter 42, The SDT PostMaster, section "PostMaster Reference" on page 2484.
--------------------------------------------------------------- File Contents --------------------------------------------------------------- satgate.c Main program for communication between the SDT PostMaster and the communication port. sudisp.h Header file for sudisp.c sudisp.c Dispatcher for callback functions in satgate.c sp.h Header file for sp.c sp.c New implementation of all PostMaster functions used in the Simulator library. stack.c For changing the stack size for IC86. sumem.h Header file for sumem.c sumem.c Memory management routines. sat.h Header file for satgen.c and satread.c satgen.c Functions to Open, Close, Flush, Sync and Send to the communication port. satread.c Functions to Poll and Read from the communication port. sattty.c Open, set attributes and close of tty (not used for IC86). sulog.h Header file for sulog.c sulog.c Functions for error and debug logging. suos.h Header file for OS dependent definitions. postf.c PostMaster interface source code. Located in direc tory $sdtdir/INCLUDE This file is included in the Master Library distribu tion. ---------------------------------------------------------------This page intentionally left blank
Table of Contents Next Chapter