ChorusOS 4.0.1 Simulator Architecture

The ChorusOS 4.0.1 Simulator for the Solaris Operating Environment (SPARC Platform Edition) was designed to imitate the behavior of the ChorusOS operating system embedded on a physical target. In particular it:

• Supports remote Chorus IPC communication using Solaris UDP sockets.

• Supports Ethernet functionality allowing:

  • Solaris hosts to access the simulator with commands such as rsh and ping.

  • The simulator to access Solaris hosts' resources through standard Solaris daemons such as nfsd and rarpd.

The simulator is restricted to the flat memory model and supervisor actors.

Each simulator is a UNIX process running independently of other simulators, and up to 254 simulators can run and interact simultaneously on the same host or distributed over several hosts.

The simulator uses Solaris libraries in order to:

• Manage memory, interrupts, and process contexts.

• Access UDP socket functions for remote Chorus IPC data linking.

• Access stream functionality to allow communication between the ChorusOS Ethernet pseudo-driver and the Solaris Ethernet pseudo-driver.

Boot Mechanism

The simulator system image is booted with a utility called loader which:

1. Allocates 32 Megabytes of virtual memory for the simulator on the host.

2. Copies the system image to the allocated memory.

3. Configures the remote IPC-oriented UDP port and the IP address based on information in the site configuration file, site_number.conf.

4. Jumps to the entry point of the system image and runs the simulator.

Figure 1-1 illustrates the virtual address space of the UNIX process after loading the system image.

Figure 1-1 Loading Mechanism

Remote Inter-Process Communication

Remote IPC is based on Solaris UDP sockets which are used for sending, reading, and listening to IPC messages. Each simulator uses a single UDP socket to communicate with other simulators. The port number of this socket is specified in the site_number.conf file. Broadcasting is achieved by sending IPC messages to each simulator in this file.

Figure 1-2 illustrates the remote IPC mechanism.

Figure 1-2 Remote IPC Mechanism

Network Architecture

Each simulator on a Solaris host accesses remote machines in the same way that a physical target accesses the outside world: through a network interface. As the network is not directly accessible through a dedicated Ethernet device, a Solaris Ethernet pseudo-driver simulates a specific sub-network, grouping all the simulators running on the same host. In particular, the Ethernet pseudo-driver allows each simulator to:

• Have its own IP address.

• Access remote files via NFS.

• Be accessed with the rsh command.

The pseudo-driver also supports any additional Ethernet-based functionality.

Each simulator interfaces with the Solaris Ethernet pseudo-driver sub-network. All simulator-specific network requests on this sub-network are routed by this driver. Each time a request concerns a host outside this sub-network, the request is forwarded to the host Solaris IP stack to be processed.

Figure 1-3 illustrates the software architecture simulating the network. The Ethernet pseudo-driver manages communication between simulators located on the same host and between simulators and the host.

Figure 1-3 Software Architecture

This mechanism allows simulators to be accessed both from their host and also from any host on the network, after configuring the IP routing information.

Figure 1-4 illustrates the network data flow between simulators and the Ethernet network, with the Solaris IP stack relaying messages between networks.

Figure 1-4 Network Data Flow