Multi2Sim provides a tool to stress an interconnect given in the network configuration file using synthetic traffic patterns. This tool is referred to as the stand-alone network simulator, and is
integrated within the rest of the simulator functionality. It can be invoked using command-line option
––net-sim <network>, wherenetwork is the name of a network defined in the network configuration file passed with option––net-config <file>. The following additional command-line options are available for stand-alone network simulation:
• ––net-injection-rate <rate>(Default = 0.001). Packet injection rate for every end node in the network. Each end node injects packets in the network using random delays with exponential distribution, where lambda = rate. The destination end node of the packet is also chosen randomly among all reachable destination end nodes.
• ––net-max-cycle <cycle> (Default = 1M). Number of simulation cycles.
• ––net-msg-size <size> (Default = 1 byte). Packet size in bytes. An entire packet should fit in the smallest buffer created in the network. The transfer latency of a packet will depend on the bandwidth of the links it has to traverse, as well as the contention it experiences in every intermediate node.
Assuming that the example configuration file shown in Section 10.5 is stored in filenet-config, the following command line can be used to stress networkmynet during 1M cycles, having each node inject one packet to the network every 10 cycles on average:
m2s --net-config net-config --net-sim mynet --net-max-cycles 1000000 \ --report-net report-net --net-injection-rate 0.1
Network Commands
In the network configuration file, section [Network.<name>.Commands]can be used to manually inject messages to a network. The user can deterministically send packets from end nodes in the network to re-create desirable scenarios. Commands can also be used to perform sanity checks on state of packets in the network and verify their expected output. This section of the configuration file can be only used in stand-alone network simulation mode and without the––net-injection-rate option. Each variable in section [Network.<name>.Commands]represent one command. Commands are listed in increasing order starting at 0, with their index set off in brackets:
[ Commands ]
Command[0] = 1 send n0 n2 1 1 Command[1] = 1 send n1 n2 1 2 Command[2] = 2 outbuffercheck n0 1 Command[3] = 2 nodecheck n1 2 Command[4] = 3 inbuffercheck n2 1 Command[5] = 4 inbuffercheck n2 2 Command[6] = 3 receive n2 1 ...
Each command is a string formed of a set of tokens separated with spaces. The possible commands can be split into two different categories, depending on whether a message is sent or its location in the network is being checked. Commands with the following format send a message in the network:
• <cycle> send <source-node> <destination-node> <message-size> <message-id>. Using this command, a message of size message-sizeis sent fromsource-nodeto destination-nodein the specified cycle. Both message-sizeandmessage-idare optional fields. If the message size is not specified the transferred message will have the same size as specified by––net-msg-sizeoption.
Fieldmessage-idcan be used to refer to this message in subsequent commands.
The following commands perform sanity checks and validation.
• <cycle> inbuffercheck <node> <message-id>. This command validates that the message with the specified message-idis in one of the input buffers of the providednode at the specified cycle.
• <cycle> outbuffercheck <node> <message-id>. This command validates that the message with the specified message-idis in one of the output buffers of the providednodeat the specified cycle.
• <cycle> nodecheck <node> <message-id>. This command is the combination of the previous two commands and checks to validate if the message is in one of the buffers (either input or output) of the provided nodeat the specified cycle. This command is very useful for validating network configuration with so big number of nodes
• <cycle> exactposcheck <node> <buffer-name> <message-id>. This command validates that the message with the specifiedmessage-idis in a specific buffer of the nodewith the provided
buffer-nameat the specified cycle.
• <cycle> receive <node> <message-id>. Validates that messagemessage-idis received at the specified cycle.
The output of these checks is printed out on the standard output followed by messagePASS or FAIL, indicating whether the validation was successful or not.
Chapter 11
M2S-Visual: The Multi2Sim Visualization Tool
11.1 Introduction
M2S-Visual is a visualization tool, integrated in the Multi2Sim simulation framework, that provides visual representations for analysis of architectural simulations. The primary function of M2S-Visual is to observe the state of the CPU and GPU pipeline and the state of the memory, providing features such as simulation pausing, stepping through cycles, and viewing properties of in-flight instructions and memory accesses.
The state of CPU and GPU software entities (contexts, work-groups, wavefronts, and work-items) and memory entities (accesses, sharers, owners) are represented, along with the state of CPU and GPU hardware resources(cores, compute units) and memory hierarchy(L1 cache, L2 cache and the main memory). The main window shows the overview of the CPU, GPU and memory. Secondary windows can be opened, representing time or block diagram that the user can navigate through.
Compilation of M2S-Visual
M2S-Visual is integrated in the same executable file as the rest of Multi2Sim’s simulation features.
The tool requires the GTK 3.0 development packages to be installed in your system for correct compilation. If this library is missing, Multi2Sim will still compile successfully, but without support for the visualization features. During the compilation of Multi2Sim, theconfigurescript will detect the presence of this package, and output a warning message in case it is not found.
Running M2S-Visual
M2S-Visual acts as an off-line analysis tool. In a first execution of an architectural simulator, Multi2Sim generates a trace file containing a detailed report of all actions occurring in the modeled hardware. The generation of the trace file is configured with command-line option––trace <file>, where<file> is a plain-text file compressed with the gzip format. The name of the file should have the
.gz extension (e.g.,output-trace.gz).
When launching a detailed simulation with activated traces, one needs to be careful with the computational weight of simulated programs. The simulator dumps several lines of text in every execution cycle, and even if the output format is compressed, its size can reach gigabytes of information very quickly.
An example is given next on how to run thetest-threadsapplication1 using a CPU configuration with 4 cores. This mini-benchmark is an x86 program that takes a value n as an argument, and spawns n − 1 child threads. Each thread, including the parent, dumps its identifier, and exits. The first step is creating a CPU configuration file (x86-config) specifying the number of CPU cores:
[ General ] Cores = 4
The CPU detailed simulation is launched with the following command:
m2s --x86-sim detailed --x86-config x86-config --trace my-trace.gz test-threads.i386 4
The following code is an excerpt of filemy-trace.gz, generated during the simulation (command gunzip my-trace.gzcan be used to uncompress the trace):
...
The trace file is formed of a set of header specifying the configuration of the processor model for this specific simulation. For each simulation cycle, a set of lines represent all actions occurring in processor pipelines, GPU compute units, or memory hierarchy components. The specific format of the
simulation trace out of the scope of this guide, but is documented instead in code comments on the M2S-Visual source code.
Once the trace has been generated, the next step is launching M2S-Visual consuming it (using the compressed version, as generated by the previousm2s execution). To launch M2S-Visual, option
––visual <file>is used, where <file> is the compressed trace file.
m2s --visual my-trace.gz
Before the main window shows up, the trace is uncompressed, and simulation checkpoints are created.
The goal of the checkpoints is to allow for fast navigation through cycles. For example, if the user wants to navigate from cycle 1040 back to cycle 1039, a checkpoint-less implementation would need to reset the visualized machine state, and process the trace lines for all 1039 again. On the contrary, assuming a checkpoint frequency of 500 simulation cycles, M2S-Visual loads the visualized machine state at cycle 1000, and then processes only those trace lines for the following 39 cycles. In
simulations with millions of cycles, this feature is indispensable.
As an additional example, the following two lines of code show the code for the execution and visualization of a GPU program, using the OpenCL matrix multiplication implementation available in the AMD SDK benchmark suite (Section Benchmarks on the website):
1This program is available on Multi2Sim’s website, under Section Benchmarks, as part of the Mini-Benchmarks suite
$ m2s --evg-sim detailed --trace my-trace.gz MatrixMultiplication \ --load MatrixMultiplication_Kernels.bin -x 32 -y 32 -z 32 -q
$ m2s --visual my-trace.gz