![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
VxSim, the VxWorks simulator, is a port of VxWorks to the various host architectures. It provides a simulated target for use as a prototyping and test-bed environment. In most regards, its capabilities are identical to a true VxWorks system running on target hardware. Users link in applications and rebuild the VxWorks image exactly as they do in any VxWorks cross-development environment using a standard BSP.
The difference between VxSim and the VxWorks target environment is that in VxSim the image is executed on the host machine itself as a host process. There is no emulation of instructions, because the code is for the host's own architecture. A communication mechanism is provided to allow VxSim to obtain an Internet IP address and communicate with the Tornado tools on the host (or with other nodes on the network) using the VxWorks networking tools.
Because target hardware interaction is not possible, device driver development may not be suitable for simulation. However, the VxWorks scheduler is implemented in the host process, maintaining true tasking interaction with respect to priorities and preemption. This means that any application that is written in a portable style and with minimal hardware interaction should be portable between VxSim and VxWorks.
The basic functionality of VxSim is included with the Tornado tools and is preconfigured to allow immediate access to the simulated target. The integrated simulator does not include networking and provides only single instance usage. The VxSim full simulator is an optional product providing for networking and multiple instance usage.
The key differences between VxSim and other BSPs are summarized below. For a detailed discussion of subtle implementation differences which may affect application development, see 6.4 Architecture Considerations.
VxSim has only a few differences from VxWorks:
The VxSim full simulator provides full network capability for your simulator. This optional product also allows you to run more than one instance of VxSim on your host.
In order to simulate the network IP connectivity of a VxWorks target, the VxSim full simulator includes special drivers that operate using IP addresses. The ULIP network interface is available for Windows hosts.
All interfaces provide an I/O-based interface for IP networking that allows VxSim processes to be addressed at the IP level. When multiple programs are run, they can send packets to each other directly. This is because the host hands the packets back and forth; that is, the host OS effectively becomes a router with multiple interfaces.
All the functionality of the integrated simulator is available with the optional full simulator. All the information in this section applies to both versions of VxSim. For information specific to the full simulator product, see 6.5 Configuring the VxSim Full Simulator.
VxSim automatically starts when you request a function that requires a connection to a target. For example, when you request download of a module, if you have not started a target server VxSim and a target server are automatically started.
You can also start VxSim from the VxSim icon in Tornado environment or from the command line or the Start>Run dialog box using the command vxWorks. Available options are:
|
|||||||||||||||||||
|
|
|||||||||||||||||||
System-mode debugging allows developers to suspend the entire VxWorks operating system.1 One notable application of system mode is to debug ISRs, which--because they run outside any task context--are not visible to debugging tools in the default task mode. For more discussion of system mode, see the chapters 7. Shell and 10. Debugger.
The Windows integrated simulator is configured by default for system mode debugging.
Particular care must be taken when using absolute symbols from loaded object modules in the simulators. The VxWorks simulators execute within the memory space of a host operating system. Their actual execution address space is more constrained than is the case for the real VxWorks operating system. Absolute references to addresses must be carefully chosen in order to point to memory areas actually existing and allocated to the simulator. The values of absolute symbols defined within object modules are not modified by the loader so these values (in other words, addresses) must be set correctly by the code developers.
VxSim can use any VxWorks file system.
The default file system is the pass-through file system, ntPassFs, which is unique to VxSim. ntPassFs allows direct access to any files on the host. Essentially, the VxWorks functions open( ), read( ), write( ), and close( ) eventually call the host equivalents in the host library libc.a. With ntPassFs, you can open any file available on the host, including NFS-mounted files. By default, the INCLUDE_NTPASSFS macro is enabled to cause this file system to be mounted on startup.
In the target shell, a path name should be prefixed by host: to prevent the Windows disk device from interpreting it as a VxWorks device. Moreover, you can use both / and \ in the path; be careful when using \ in a string as the next character will be interpreted as a special character. For example, all these usages yield expected results:
-> ld < host:c:/test/testFile.o -> ld < host:c:\test\testFile.o -> cd "host:c:/test" -> cd "host:c:\\test"
However, the following does not work:
-> cd "host:c:\test"
In WindSh, do not use the host: prefix in the path name.
For more information on ntPassFs, see the reference entry for ntPassFsLib. For more information on other VxWorks file systems, see the VxWorks Programmer's Guide: Local File Systems.
The following sections describe how to use the VxSim compilers. The recommended way to build VxSim modules is to use the project tool. For complete information on this tool, see 4. Projects. If you are using manual methods in your project, the information required for manual builds and loading is summarized below.
This information applies to using manual methods on both the integrated version of VxSim and the full simulator product.
|
|||||||||||||||||||
Only the GNU compiler is supported for SIMNT: the Diab compiler is not supported. If you compile using the IDE build facilities, default build settings are already in place. If you wish to modify the defaults, or if you wish to build from the command line, the following information may be helpful.
The following is an example of a compiler command line for VxSim development. The file to be compiled in this example has a base name of applic.
% ccsimpc -g -mpentium -ansi -DRW_MULTI_THREAD -D_REENTRANT -fno-builtin -fno-defer-pop -I. -IinstallDir/target/h/ -DCPU=SIMNT -DTOOL_FAMILY=gnu -DTOOL=gnu -c applic.c
The options shown in the example and other compiler options are detailed in the online version of the GNU ToolKit User's Guide. Wind River supports compiler options used in building Wind River software; see the Guide for a list. Other options are not supported, although they are available with the tools as shipped.
The information in this section highlights differences between VxSim (both the integrated and full versions) and other VxWorks BSPs. These differences should be taken into consideration as you develop applications on VxSim that will eventually be ported to another target architecture.
VxSim uses the VxWorks scheduler, which behaves the same way as for any other VxWorks architecture (see the VxWorks Programmer's Guide: Basic OS). The BSP is extensible; for example, pseudo-drivers can be written for additional timers, serial drivers, and so forth.
The rest of this section discusses some details of the VxSim implementation. Differences between VxSim and other VxWorks environments are noted where appropriate.
Occasionally a simulator session loses its target server connection due to the many things competing for CPU time on the host. If you find that your application is frequently losing its target server connection, adjust the back end timeout (-Bt) and back end retry (-Br) parameters when starting the target server with Tornado. To do this from the Configure Target Servers dialog, select Miscellaneous and set the appropriate options using the Other Options field. For example, you may want to increase the back end timeout from 1 to 3 and the resend parameter from 3 to 4:
-Bt 3 -Br 4
You can also add this string to the tgtsvr command when you start the target server from the command line.
Windows messages are used to simulate hardware interrupts. For example, VxSim uses messages 0xc000 - 0xc010 to simulate interrupts from ULIP, the pipe back end, and so forth. The messages are the VxSim equivalent to Interrupt Service Routines (ISRs) on other VxWorks targets. You can install ISRs in VxSim to handle these "interrupts." Not all VxWorks functions can be called from ISRs; see the VxWorks Programmer's Guide: Basic OS. To run ISR code during a future system clock interrupt, use the watchdog timer facilities. To run ISR code during auxiliary clock interrupts, use the sysAuxClkxxx( ) functions.
Table 6-2 shows how the message table is set up.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Pseudo-drivers can be created to use these interrupts. Interrupt code must be connected with the standard VxWorks intConnect( ) mechanism.
For example, to install an ISR that logs a message whenever host message WM_TIMER_CLOCK arrives, execute the following:
-> intConnect (0xc011, logMsg, "Help!\n")
Then send message 0xc011 to VxSim from a host task. Every time the message is received, the ISR (logMsg( ) in this case) runs.
If a VxSim task reads from a host device, the task would normally block while reading; however, this would stop the VxSim process entirely until data is ready. Instead the device is put into asynchronous mode so that a message is sent whenever data becomes ready. In this case, an input ISR reads the data, puts it in a buffer, and unblocks some waiting task.
Since VxSim uses the task's stack when taking interrupts, the task stacks are artificially inflated to compensate. You may notice this if you spawn a task of a certain size and then examine the stack size.
The execution times of VxSim functions are not, in general, the same as on a real target. For example, the VxWorks intLock( ) function is normally very fast because it just writes to the processor status register. However, under VxSim, intLock( ) is relatively slow because it takes a host semaphore, allowing other processes to run.
The clock facilities are provided by the Windows API SetTimer( ) for both the system and auxiliary clocks. The problem with using SetTimer( ) for the target system clock is that it produces inaccurate timings when VxSim is swapped out as a host process. On the other hand, the timing of VxSim is, in general, different than on an actual target, so this is not really a problem.
|
|||||||||||||||||||
The spy( ) facility is built on top of the auxiliary clock. The task monitoring occurs during each interrupt of the auxiliary clock to see which task is executing or if the kernel is executing. Because the profiling timer includes host system time and user time, discrepancies can occur, especially if intensive host I/O occurs.
Due to some specifics of the Windows emulator, there is a critical section at the end of the intUnlock( ) routine where interrupts can occur but scheduling is forbidden. If a reschedule is necessary at the end of the interrupt, it is not done when the interrupt is exited but is delayed until the end of the critical section of the intUnlock( ) routine.
This behavior can have an impact on a WindView graph. If a high priority task is made ready within an interrupt handler, this task may not be run when the interrupt is exited but instead may run slightly later.
|
|
|||||||||||||||||||
This section contains information pertaining only to the VxSim full simulator. (All information in previous sections also pertains to that product, as well as to the integrated version.) The VxSim full simulator provides networking facilities. Most of the special considerations associated with it are network considerations.
If you purchase the VxSim optional full simulator for networking, you must take additional configuration steps.
|
|
WARNING:
Project facility configuration and building of projects is independent of the methods used for configuring and building applications prior to Tornado 2.x (which included manually editing config.h and configAll.h). Use of the project facility is the recommended, and is much simpler. However, the manual method may still be used (see 5. Command Line Configuration and Build for details). Avoid using the two methods together for the same project except where specific BSP and driver macros are not available in the project facility.
|
||||||||||||||||||
tgtsvr.exe 192.168.255.1 -n vxsim -V -B wdbrpc
|
|
|||||||||||||||||||
As with any other BSP, adding components to VxWorks requires including them, rebuilding VxWorks, the downloading and restarting it. The easiest method for doing this is to use the project facility. However, if you have used manual methods in your project, you should continue to use those methods.
For a discussion of networking as it relates to VxSim, see 6.5 Configuring the VxSim Full Simulator.
For more information on using the configuration tool, see 4. Projects.
Edit target/config/simpc/config.h, and replace:
#if TRUE #undef INCLUDE_NETWORK <...>
#if FALSE #undef INCLUDE_NETWORK <...>
Then rebuild and download VxWorks.
You must also change your target server configuration from wdbpipe to wdbrpc.
Replace -B wdbpipe by -B wdbrpc in the target server command line, and add the IP address of the simulator. The target server launch options should include the following:
-V -B wdbrpc RW 192.168.255.1
tgtsvr.exe 192.168.255.1 -n vxsim1 -V -B wdbrpc
When you install the optional VxSim component, your system is automatically configured to run up to 16 simulators. When you start VxSim from the GUI, you can specify the processor number to use from the VxSim Launch window. The processor number must be a positive number ranging from 0 (first instance: vxsim0) to 15 (last instance: vxsim15).
To start VxSim from the command line, the command takes the following form (where n is the processor number):
c:\> installDir\target\proj\fullSimulator\default> vxWorks -p n
All of the networking facilities available under VxWorks--for example, sockets, RPC, NFS--are available with VxSim. For VxSim to communicate with the outside world, it must have its own target IP address as provided through a network interface.
Internet addressing is handled slightly differently among the available network interfaces. For each VxSim process, there are three associated IP addresses:
Addressing is according to processor number, such that when you run VxSim with processor number n (using the command vxWorks -p n), the network addresses packets as shown:
192.168.255.254 is the default host IP addr for the ULIP adapter; this configuration assigns IP addresses 192.168.255.1 through 192.168.255.16 to sixteen devices. If those IP addresses are not suitable, the address of the ULIP adapter may be changed, but do not use 127.n.n.n, which is reserved for other purposes on Windows. No change is necessary in the simulator configuration, since it gets its address dynamically from the ULIP adapter.
Aliases can be defined to assign names to simulator addresses, by adding the entries to the appropriate file:
The following example shows a typical hosts file:
192.168.255.1 vxsim0 192.168.255.2 vxsim1 ... ... 192.168.255.16 vxsim15
When you run VxSim with ULIP and specify processor number n (with the command vxWorks -p n), VxSim for Windows attaches to the IP number you specified when installing ULIP, which must not be 127.n.n.n.
Only one process at a time can open the same ULIP device; this is enforced in the ULIP driver. Thus, if you want multiple VxSim targets to use ULIP, you must give each of them a distinct processor number. If another VxSim process is already running with the same processor number, then the ULIP device cannot be opened (ulip0 corresponds to processor 0), and the following message is displayed during the startup of VxSim:
Error: There is already a simulator running with this processor number. Please restart with a different number (/p <number> option). Hit Any Key to Exit
When you run VxSim on NT, host entries are not automatically created until a simulator is started.
|
|
WARNING:
The VxSim ULIP driver will not attach to a network interface if it is already in use, that is, ul0 can be used by only one VxSim process. Use the -p flag to run VxSim with a different processor number; see Starting VxSim.
|
||||||||||||||||||
You can add host-specific routing entries to the local host to allow remote hosts to connect to a local VxSim "target." IP addresses are set up only for the host where the network simulation software is installed. The network interface does not have to be installed remotely; the remote host uses the local host as the gateway to the VxSim target.
In the example shown in Figure 6-2, host1 can communicate with vxsim0 or vxsim1 if IP forwarding is enabled. (See Installing VxSim Network Drivers for more information on how to enable IP forwarding.)
Contrast Figure 6-2 below with Figure 6-1 to see the way addresses are set up, paying particular attention to the addressing algorithm described in IP Addressing.
To communicate from host1 to vxsim0 and vxsim1, type the following commands from host1 (requires administrative privilege):
c:\> route ADD 192.168.255.1 90.0.0.1 METRIC 1 c:\> route ADD 192.168.255.2 90.0.0.1 METRIC 1
Verify the success of the above commands by pinging vxsim0 from host1:
% ping 192.168.255.1
|
|
|||||||||||||||||||
To allow a VxSim process on one host to communicate with a VxSim process on a different host, you must make sure that the two VxSim processes have different IP addresses. You must also make additional host-specific routes using unique addresses for each process.
For example, to ping vxsim2 from host0 above, you must add an additional route from host0 as follows:
c:\> route ADD 192.168.255.3 90.0.0.2 METRIC 1
|
|
|||||||||||||||||||
To enable remote access to a simulator, IP forwarding must be enabled. For more information on how to enable IP forwarding, see Installing VxSim Network Drivers.
1: System mode is sometimes also called external mode, reflecting that the target agent operates externally to the VxWorks system in this mode.
