Source files: src/MemSys/architecture.c, src/MemSys/mesh.c, src/MemSys/net.c, src/MemSys/module.c, src/MemSys/setup_cohe.c
Header files: incl/MemSys/arch.h, incl/MemSys/net.h
As mentioned in Chapter 9, RSIM uses the SystemInit function to set the desired characteristics of the multiprocessor architecture being simulated. After setting some global fields according to the modules present in the system, the SystemInit function calls dir_net_init.
First, dir_net_init constructs the multiprocessor
interconnection network. This is a 2-dimensional mesh network with a
square number of nodes (if a non-square system is desired, the user
should either round up to the nearest square or some other appropriate
square configuration size). dir_net_init calls CreateMESH
to construct the request and reply networks. This function initializes
all the buffers and ports of the network (described in
Section 15.3), calling the functions MeshCreate,
Create1DMesh, ConnectMeshes, ConnectComponents, and
NetworkConnect to set up the system. After creating these meshes,
dir_net_init next sets the mesh parameters of flit delay and
arbitration delay: if pipelined switches are being modeled, these
parameters are modified from the input parameters in order to simulate
the desired degree of pipelining. The network used in RSIM is
taken from the NETSIM interconnection network simulator [7].
More details on the network
interconnection and parameters are available in Section 15.3
and in the NETSIM reference manual (available from
http://www-ece.rice.edu/ 
rsim/rppt.html).
Next, dir_net_init creates the Delays data structures for many of the individual modules. Each module has parameters for access time, initial transfer time, and flit transfer time. Additionally, the directory module has parameters for the first packet creation time associated with a request and each subsequent packet creation time, which are used to effect delays when sending coherence messages from a directory. The access time and packet creation times of the DirDelays structures are configurable at run-time. These Delays are not currently used for the CPU, L1 cache, L2 cache, and write-buffer, but are provided for possible expansion. The actual latencies for the L1 and L2 caches are stored in the variables L1TAG_DELAY, L2TAG_DELAY, and L2DATA_DELAY.
Next, dir_net_init allocates all the needed modules for the individual nodes (e.g. caches, write buffers, network interfaces, busses, and directory banks). The system then initializes each of these modules, using NewProcessor, NewCache, NewWBuffer, NewSmnetSend (creates new network send interface), NewSmnetRcv (creates new network receive interface), NewBus, and NewDir to set the parameters for each module type. As caches are created, the setup_tables function is called to configure the coherence behavior of the system. Within the memory system simulator, the MESI states are referred to as PR_DY, PR_CL, SH_CL, and INVALID, respectively.
The ModuleConnect functions are then used to connect the various modules through their appropriate SMPORT data structures. The invocation ModuleConnect(src,dest,a,b,width) creates a bidirectional connection between the modules: output port a of module src is connected to input port b of module dest, and input port a of module src is connected to output port b of module dest. The output ports must have already been constructed by the ModuleInit function described in Section 12.1; ModuleConnect simply sets the input ports of one module to point to the same data structures as the output ports of the other module. The interconnection between these modules has a width of width bytes. (Currently, the width parameter for all module connections is a compile-time parameter, INTERCONNECTION_WIDTH_BYTES.)
As described in Section 12.1, the ModuleInit function initializes all output ports of a given module with queues of the same size. However, the user may override these through the runtime parameters specified in Section 4.2.7. These changes in queue lengths are incorporated using the QueueSizeCorrect function.