PDF User Guide

Last updated: September 4, 2013

Support and prerequisites

This software is developed and tested on the following system: Processor: x86 64 OS: 64-bit-Linux Kernel: 3.4.33.-2.24-desktop Distribution: OpenSUSE 12.2 Desktop: KDE 4.8.5r2 Qt framework 4.8.1 (minimum: 4.7) Xilinx EDK 14.2 (minimum: 13.1) MentorGraphics ModelSim SE 10.1c (minimum: 6.6) EDK simulation libraries compiled with compedklib for the installed ModelSim version

I expect this to work on a lot of other constellations (e.g. other Linux systems, other Qt versions, Xilinx and ModelSim tool versions), but there has been no extensive testing. If you can report success, consider emailing me at [email protected] (please put [SimXMD] into the subject line).

You should have the Qt cross-platform application framework (version 4.7 or newer) installed (SimXMD has not been tested with versions 5.x). It can be downloaded at http://qt-project.org/downloads

Installation

To install SimXMD follows these steps: • Open a terminal

• Set the environment variable MODELSIM PATH to ModelSim’s installation path example for bash: > export MODELSIM PATH=/opt/Modelsim/10.1c/ • Enter the unzipped SimXMD source directory

• On the command-line, enter: > qmake > make > sudo make install SimXMD is installed into /usr/local/bin/simxmd by default. To change the installation path, set the environment variable SIMXMD PATH before calling qmake. If you install SimXMD to a location in your home directory, you don’t need to use sudo for make install.

NOTE: SimXMD needs the PATH variable to point towards various EDK commandline tools. Since the simplest way to start SimXMD will often be directly out of an EDK project, I suggest to add a path to SimXMD into the script(s) you use to setup a working environment for your Xilinx and ModelSim tools anyway. As an example, a bash script could be easily extended this way: export PATH=/usr/local/bin/simxmd/:${PATH}

A Quick Start

Debugging with SimXMD can always be started in four quick steps: • Generate a simulation model with XPS • Let SimXMD modify the simulation model • Initiate the simulation • Connect to the simulated MicroBlaze processor with a debugger of your choice The SimXMD sources include an example project for EDK versions 14.x, with all the project settings ready to jump right in. The later chapters will explain the limited number of steps necessary to make your own projects work with SimXMD. This example assumes that you start Xilinx Platform Studio with the path settings recommended above.

1. Extract the demo project in $SIMXMD SOURCE/xps demo project/SimXMD Demo v14.tar.gz

2. Start XPS and open the project. Depending on your EDK version, XPS will suggest to update certain pcores to newer versions, or in some rare cases even tell you it can’t auto-update because newer versions are not downwards compati- ble. In the latter case, try to edit the version in the system.mhs ﬁle by hand to an available one; there are rarely real compatibility issues.

Select Project → Export Hardware Design to SDK to launch the Xilinx SDK; make sure that Include Bitstream and BMM ﬁle is unchecked so that XPS does not implement the hardware. When prompted, enter the workspace path ./SDK. Make sure to re-build everything by selecting Project → Clean.... Close the SDK.

This is a simple project with a MicroBlaze, on-chip BlockRAM for code and data and two peripherals connected through Fast Simplex Links (FIFOs). The ﬁrst peripheral is a network component that will receive encrypted packets of 32-bit words. The second component is a co-processor that can decrypt the packets. 3. Export the simulation model by selecting Simulation → Generate Simulation HDL ﬁles. 4. Start SimXMD by pushing the left X-shaped custom command button.

SimXMD will start in GUI mode with three text ﬁelds logging debugger communication, processor- speciﬁc data and simulator communication. The GUI is purely optional for those logging purposes and for interactive changes of project options. Alternatively, you can start the console version of SimXMD by pushing the right X-shaped custom command button.

In the background, SimXMD automatically parsed the project data and modiﬁed the simulation model when it was started. The only indication of this is that the central logging window in the GUI shows some information about the selected processor and its assigned binary. 5. Go back to XPS. Start the simulator by selecting Simulation → Launch HDL Simulator 6. In the ModelSim console, type > do sx start.do

ModelSim now compiles the simulation model, starts the simulation and populates the wave window, all of it using the scripts generated for these purposes by XPS and SimXMD .

Additionally, SimXMD modiﬁcations add a few waveforms that illustrate the processor’s execution state. The added scripts also start a TCP server that can automatically receive ModelSim commands from SimXMD and run the binary execution to the beginning of main(). Finally, an extra SimXMD menu is added to ModelSim so that any control of SimXMD can be exerted through the ModelSim GUI. SimXMD itself, with or without GUI, can always stay in the background.

After the startup, SimXMD should automatically connect to ModelSim’s TCP port. This is visible in Modelsim’s wave window through a thin white cursor that marks the upcoming processor instruction (the ﬁrst instruction of main()). The white cursor is also designated RUN MODE in the bottom of the wave window (more about modes later). We can now connect a debugger! 7. Select the ModelSim menu entry SimXMD → Start command-line GDB.

A terminal window with the command-line version of the GNU debugger should open and indicate it is connected to the processor with the binary execution at the start of main(). You can now freely debug the program running on the simulated MicroBlaze. As an example, display the current program counter at main() with (gdb) display $pc

Now use the program counter value (e.g. 0x24c)) to read the ﬁrst instruction word in main() (gdb) x /1xw 0x24c

or disassemble that instruction with (gdb) disas 0x24c,+4

You can cross-check all three results in the top of the wave window at the white Run mode cursor.

8. Close GDB and select the ModelSim menu entry SimXMD → Start Xilinx SDK debugger.

Xilinx SDK starts in the workspace managing the Microblaze software project network rx test, which has also been assigned to the processor for simulation in XPS. A speciﬁc debug conﬁguration for the project named SimXMD microblaze 0 has been added to the workspace. You can activate it by press- ing F11 or clicking on the bug icon.

SDK will connect to the simulator through SimXMD, the same way that the command-line GDB did. It will display all the typical trappings of a graphical debugger, a source code window indicating the code position, variable and register displays etc.

Use the keys or buttons for step, step over, ﬁnish and continue (with breakpoints) to move code execution forward. In the simulator’s wave window, you can see how the simulation moves forward in the same steps. At any time, the debugger will display accurate register, variable and memory state of the moment that is marked by the white cursor in the waveform window.

Run Replay Run

x2 0x3 0x4 0x5 x2 0x3 0x4 0x5 x2 0x3 0x4 0x5 x2 0x3 0x4 0x5 0x6

(A) PC = 5 (B) PC = 5 (C) PC = 3 (D) PC = 6

int main() int main() int main() int main() { { { { a = functionA(); a = functionA(); a = functionA(); a = functionA(); b = functionB(a); b = functionB(a); b = functionB(a); b = functionB(a); c = b + 5 * d; c = b + 5 * d; c = b + 5 * d; c = b + 5 * d; return c; return c; return c; return c; } } } }

Debugging in Run and Replay modes SimXMD can run in two diﬀerent modes, the previously mentioned Run mode and Replay mode: • Run mode, which SimXMD starts in when connecting to the simulator, always transmits the most recently simulated processor state to the debugger. Any Step or Continue command from the debugger results in running the simulation up to the next break condition. • Replay mode parses earlier processor and memory state information and therefore allows “re-executing” earlier code in the debugger. This is useful because it allows to home in on earlier time stretches in simulation where problems have been identiﬁed in the hardware signals. These critical areas can be re-executed and debugged unlimited times.

The ﬁgure above illustrates how to use modes and switch between them: A. Debugging starts in Run mode as described. The ModelSim wave window will show a white locked cursor at the most recent instruction. The cursor name RUN MODE appears at the bottom of the window.

B. To switch to Replay mode, mark the moment in simulation that you would start debugging from with an active cursor. Choose the menu entry SimXMD → Debug from Cursor (Replay Mode) in ModelSim. SimXMD marks the time with a locked white cursor named GO TO CURSOR and pops up a dialog informing you to press Step or Continue in the debugger to complete the transition. At this point, the debugger is unaware of the change and still shows the most recent Run mode code position.

C. As soon as the user selects Step or Continue, SimXMD ﬁnds the next break time, positions the white locked cursor there and names it REPLAY MODE. The debugger gets updated processor state from that position; the transition to Replay mode is complete. The user can now employ further stepping to move forward in the previously simulated execution. D. When the debugging reaches the most recent simulation time without hitting upon a break condition, SimXMD automatically switches back to Run mode and continues to the next breakpoint. Alternatively, the user can choose SimXMD → Debug in Run Mode at any time to go back to Run mode. The same transition circumstances apply: The debugger will only update when Step or Continue is used the next time.

system_tb.v system.v BlockRAM Test MicroBlaze Network data Processor Interface receive_data.c

Crypto Co-processor

Debugging the demonstration system The figure above gives a simple overview of the demonstration system included in the project. A MicroBlaze processor has two peripherals connected through Fast Simplex Links (FIFOs). The first peripheral is a network component that will receive encrypted packets of four 32-bit words (the encryption key for all words in one packet is identical; the encryption is just an XOR operation). The second component is a decrypt co-processor; before the beginning of each packet, the decryption key is written through the FSL with the control bit asserted; afterwards, each of the 4 data words is written (control bit = 0) and read back in decrypted form. The decrypted packet is written into a memory storage buffer and also written out to an 8-bit GPIO called LED OUT (not shown in the figure). The testbench produces a steady stream of input words, starting with the decimal number 42 and counting up by one on each word. It automatically increases the encryption word after each four-word packet. After two packets have been decrypted, the testbench resets the processor (and the input generator) to test if the re-started system still works identically.

The system shows two issues, one of them caused by a hardware bug in Verilog, and one caused by the C code in network rx test.c: 1. The decrypted packet data is one word off, starting with an unexpected value (0). 2. After reset, the decryption produces completely wrong data. You can now use SimXMD to find these bugs. • If you change the hardware/fix a hardware bug, you can restart the simulation by selecting SimXMD → Re-start with updated HW project in ModelSim. • If you recompile the ELF file, you can restart by selecting SimXMD → Re-start with updated ELF file. • If you have just changed the wave window arrangement / added extra signals, you can restart with SimXMD → Re-start without changes. • If you want to keep the wave window format, save it into wave.do in the simulation folder (the default name and path) and the format will be used on following ELF and HW restarts.

If you’re getting sick of trying to ﬁnd the bugs (SimXMD not enough help...?) you can ﬁx them with the scripts fix HW.sh and fix SW.sh in the scripts folder of the EDK project. The scripts restore HW.sh and restore SW.sh let you re-introduce the bugs.

General usage Preparing your own EDK project for SimXMD use You will be able to skip the ﬁrst few steps if you already have an existing MicroBlaze system to use SimXMD with. Note that SimXMD so far only supports systems that initialize on-chip BlockRAMs with the program code.

1. Generate a Microblaze system in Xilinx XPS. 2. Export the system to Xilinx SDK. You can skip copying BMM and BIT ﬁles for simulation; this will save you the time (and possible failure) to implement a bitstream for the FPGA.

3. In SDK, generate a Xilinx C application of your choice for the exported system. Note that if your system includes external DRAM, SDK will by default use a linker script that locates the program code in DRAM. In this case, let SDK generate a new linker script for your project and make sure that it locates the code in BlockRAM. 4. For testing SimXMD, make sure that there is some example code that is useful to debug, like a for loop writing to memory. 5. When your C code compiles successfully to an ELF file, go back to XPS. 6. In XPS choose the menu entry Project → Select ELF File... 7. Under Choose Simulation Elf File, select the radio button next to the text field. Use the folder button to pick the path to your compiled ELF file (usually something like SDK WORKSPACE/elf project 0/Debug/elf project 0.elf). Click OK. 8. Go to the menu entry Project → Project Options... and choose the Design Flow tab. 9. Set the HDL to Verilog. Check Generate test bench template. Set Simulation Models to Behavioral. If appropriate, check Enable External Memory simulation (Note that, depending on the FPGA board you chose earlier, you might have to copy DRAM simulation models into the appropriate locations). Press OK. 10. Select the menu entry Simulation → Generate Simulation HDL files; XPS will generate a full system simulation model with testbench and input stimuli (clock and reset).

Starting SimXMD SimXMD is started from the command-line with > SIMXMD INSTALL PATH /simxmd options

You can of course omit the installation path if you’ve added SimXMD to the PATH variable in the way suggested above.

NOTE: A convenient way to start SimXMD is by customizing the custom tool buttons in XPS. Select Project → Customize Buttons... and enter simxmd --gui for the GUI version or xterm -e simxmd for the command-line version (add further options as necessary; see below). Check Run in a separate window for each entry. Using the buttons assures that SimXMD is started in the project path and automatically ﬁnds the project data to parse and modify.

On starting SimXMD with correct path information, it will initiate the following steps:

• Parse the project files and the binary for relevant information • Copy some tcl and Verilog files into the simulation directory; modify the Verilog testbench; generate a few scripts based on project-specific information (see Section “File Descriptions”)

• Try to connect to ModelSim as soon as a TCP socket opens

SimXMD command-line options Started from the XPS project path, SimXMD will in most cases work without any extra arguments. The following switches are available:

• --pp=PROJECT PATH Indicates the Xilinx EDK project path with the system.xmp and system.mhs ﬁles if SimXMD is not started there.

• --xm=SIMMODEL PATH Indicates the Xilinx simulation model path. It is by default derived as $PROJECT PATH/simulation/behavioral/ • --xw=SDK WORKSPACE Indicates the Xilinx SDK workspace that the debug conﬁguration is started in. It needs to include at least one software project, commonly (but not necessarily) the software project that is used in the simulation. By default, SimXMD tries to derive the workspace that the speciﬁed simulation ELF is associated with. If this fails, SimXMD cannot debug with Xilinx SDK.

• --ci=CORE NAME Instance name of the MicroBlaze core to debug. By default, SimXMD picks the first processor listed in the system.xmp file with a valid specified ELF file.

• --ds=DEBUGGER SOCKET TCP port number where SimXMD expects GDB to connect. Default is 7755.

• --ds=SIMULATOR SOCKET TCP port number where SimXMD tries to connect to the simulator. Default is 2233.

• --gui Start SimXMD with GUI. By default the console version starts, and all communication logging goes to stdout.

• --log Log a copy of all communication to the console if in GUI mode.

• --nolog Do not log all communication to stdout if in console mode.

Starting the simulation Select the XPS menu entry Simulation → Launch HDL simulator to start ModelSim in the simulation model directory.

The simulation model is compiled, started and connected to SimXMD by entering the following on the ModelSim command-line: > sx start.do

sx start.do options • --addr=0xHEXADDRESS Specifies what program counter to run the simulation up to when starting. By default SimXMD uses the address of main() extracted from the ELF file. If the processor does not hit the specified address, it stops after 20us. If the system is restarted with recompiled ELF or changed hardware from the SimXMD menu in ModelSim, the specified address is ignored since it might have changed in the re-compile, unless it was specified as 0x0, which is always valid.

• --wave=WAVE DO FILE PATH Speciﬁes a custom *.do to use to set up the wave display. This enables the user to re-arrange the wave window used during the debugging (deleting irrelevant signals, putting in others, reformatting in terms of radix and color) and keep that setup for future runs. The SimXMD scripts use the following priority for picking a wave setup ﬁle:

1. If a *.do is specified in this option, it is used. 2. If a file called wave.do is present in the simulation model folder, it is used (this is the default name and location under which to store a modified window setup with File → Save Format...). 3. If neither of the above exists, SimXMD uses the system wave.do file which was auto-generated with the model by XPS. SimXMD will always put the processor trace port signals on top, but they are in a debug group that can be closed to provide more space.

Starting and connecting a debugger SimXMD uses the GDB Remote Serial Protocol (RSP) for communication and therefore works with GDB directly as well as with most graphical debugger frontends that build on GDB. Below are instructions for using GDB in command-line mode as well as with the Xilinx SDK debugger, DDD, Nemiver or KDbg GUIs.

Command-line GDB In ModelSim’s wave window, select the menu entry SimXMD → Start command-line GDB. A terminal window will open and start GDB. You can now freely debug on the GDB command-line.

GDB can alternatively be started by opening a terminal and sourcing the script YOUR XPS PROJECT PATH/simulation/behavioral/sx run gdb.sh

Xilinx SDK debugger (Eclipse) The Xilinx SDK debugger is the most straightforward choice for a debugger GUI, since Xilinx SDK is also the vendor-provided tool to write and compile code for MicroBlaze systems. It is based on the popular Java and C/C++ IDE Eclipse.

Choose the menu entry SimXMD → Start Xilinx SDK debugger in ModelSim. Xilinx SDK will open in the associated workspace. Press F11 or the click the button with the bug symbol to start the debug conﬁguration and connect with SimXMD. The debug conﬁguration is always named in the format SimXMD PROCESSORNAME.

Two notes about Xilinx SDK debug: A. The debug configuration is written at the start of SimXMD or when the project data has changed (processor instance, ELF location and ELF source files are relevant here). If SDK is already open at that point, the debug configuration will either not be visible to SDK or outdated. In those cases, close SDK and start SDK again as described here.

B. While any save of changed code by default triggers an instant recompile of the MicroBlaze binaries in SDK, this obviously does not result in an updated binary in the simulation model or in SimXMD. If you are modifying your application, re-start your simulation environment with the ModelSim menu entry SimXMD → Re-start with updated ELF ﬁle.

Xilinx SDK can alternatively be started by opening a terminal and sourcing the script YOUR XPS PROJECT PATH/simulation/behavioral/sx run XSDK.sh

DDD DDD is a very popular GDB frontend that is either pre-installed on most distributions or can be downloaded through package and software managers. Choose the menu entry SimXMD → Start DDD GUI in ModelSim and DDD will open and connect to SimXMD. An initial step instruction is necessary for the GUI to start indicating the code position. In our experience, DDD will sometimes not correctly display disassembly; this is an issue in the current DDD release, not in SimXMD.

DDD can alternatively be started by opening a terminal and sourcing the script YOUR XPS PROJECT PATH/simulation/behavioral/sx run ddd.sh

Nemiver Nemiver is a more recent GDB frontend based on GTK+. Just choose the menu entry SimXMD → Start Nemiver GUI in ModelSim and Nemiver will open and connect to SimXMD.

Nemiver can alternatively be started by opening a terminal and sourcing the script YOUR XPS PROJECT PATH/simulation/behavioral/sx run nemiver.sh

KDbg KDbg is a more recent graphical debugger frontend based on Qt and KDE. Unfortunately KDbg cannot be conﬁgured completely by command-line; mb-gdb needs to be set as the debugger through the GUI: • If not installed, get KDbg through a software or package manager or from http://www.kdbg.org/download.php

• Open a terminal and run KDbg with > kdbg • Choose the menu item Settings → Global Options... • Locate the edit ﬁeld How to invoke GDB and enter $XILINX PATH/ISE DS/EDK/gnu/microblaze/lin64/bin/mb-gdb --nx --nw --fullname --command=sx mbgdb.init • Close KDbg

You can now activate and use KDbg through the SimXMD → Start KDbg GUI menu entry in ModelSim.

KDbg can alternatively be started by opening a terminal and sourcing the script YOUR XPS PROJECT PATH/simulation/behavioral/sx run kdbg.sh

File descriptions

During startup or when the project information is changed, SimXMD copies, modiﬁes and generates a group of ﬁles in the PROJECT/simulation/behavioral directory. These description should help you to understand how SimXMD works and how to customize a simulation without losing SimXMD debugging capability:

sx start.do (copied) This is the tcl script that users should run in the ModelSim transcript window to start a SimXMD simulation from scratch. It ends a possible existing simulation cleanly and runs all the steps that are necessary to initiate a full-system simulation in general and SimXMD debugging speciﬁcally. These actions are:

• Call system setup.do, which has been generated by XPS, to set the correct compile and simulation start commands

• Call the SimXMD-generated sx constants.do to set the server port and the default start address at main() • Parse possible arguments for start address and wave ﬁle

• Call sx tcpserver off.do to shut oﬀ pre-existing server ports • Quit a still-active simulation and delete related memory logging data • Shut oﬀ the waveform window • Compile all simulation model components

• Call sx pre sim start.do to link to a VPI shared library for memory logging • Start the simulation

• Call sx post sim start.do to activate the logging and waveform display of processor trace port signals and supporting signals • Purge the signals mentioned above from the selected waveform setup script, so that they don’t appear twice • Execute the selected waveform setup script • Run the simulation up to the speciﬁed instruction address • Format the wave window size and scope

• Call sx tcpserver on.do to establish a TCP server • Add SimXMD-speciﬁc menu entries to ModelSim

sx constants.do (copied/modified) This script defines global variables for the TCP server port to let the debugger connect and for the default start address for sx runtomain.do, which is the address of main(). This data is modified by SimXMD after it starts or parses a project.

sx tcpserver on.do / sx tcpserver off.do (copied) These scripts manage the TCP connection to SimXMD. sx tcpserver on.do sets up a server port waiting for client connections; the port number used can be modiﬁed through a SimXMD command-line argument (as is true for the debugger socket). When SimXMD connects, a request handler is set up. A few custom requests trigger special script functionality, but most requests are directly put onto the ModelSim commandline, and the return value from these commands is sent back unprocessed to SimXMD. The SimXMD menu entries in ModelSim will push corresponding command strings back to SimXMD asynchronously. When SimXMD disconnects, this script cleans up the SimXMD-speciﬁc wave window cursors.

sx tcpserver off.do closes the TCP socket cleanly.

sx pre sim start.do / sx post sim start.do (generated) These scripts take actions that need to execute before respectively immediately after the simulation is started. sx pre sim start.do only holds one command (and could be copied instead of generated): It sets the environment variable PLIOBJS, which lists shared libraries with C functions that can be called from Verilog code through the Verilog Programming Interface. See the sx vpi memlog.so entry for details.

sx post sim start.do Fullﬁlls two main tasks right after the simulation has started but before it is run for any time. First, it uses the log command to make sure that all simulation signals that are needed for SimXMD to function are being recorded, independent of whether they have been selected to be displayed in the wave window. Secondly, it opens the wave window and populates it with signals that are interesting to keep track of while debugging, a feature that is just intended for convenience. If they are stealing screen space needed for other signals, just add a noview wave command behind this script in sx start.do.

sx runtomain.do (copied) This script sets a breakpoint at the address of the ﬁrst instruction in main(). It is generated with information retrieved from the ELF ﬁle.

sx addmenu.do (copied) This script adds SimXMD menus to the ModelSim main and wave windows. Each of the menu entries sends a command back to SimXMD via TCP. There are menu entries for starting miscellaneous debuggers, re-starting the simulation in various conditions and for switching between SimXMD modes.

sx restart.do (copied) Similar to the simulators own restart command, this script restarts the simulation but keeps the current waveform setup. It also interrupts the SimXMD TCP connection, calls sx runtomain.do again and re- establishes the SimXMD connection.

sx new ELF.do (copied) This script is used to re-start the simulation after the processor’s ELF binary has been modiﬁed. It is similar to sx start.do, but instead of the whole system, it only re-compiles the simulated memory after updating the simulation memory ﬁles and SimXMD’s memory model.

sx new HW.do (copied) This script is used to re-start the simulation after hardware changes. It is largely identical with sx start.do, but keeps the previously specified wave file setting. system.v (modified) This is the top-level file of the whole FPGA design. SimXMD adds signals that connect to the Trace Port of the MicroBlaze instance do be debugged. These signal are needed by the testbench and by SimXMD for running the simulation from breakpoint to breakpoints and for monitoring the processor state. system tb.v (modified) This is the testbench file generated by XPS to instantiate a system and feed it with stimuli like clock and reset. XPS includes sections marked USER CODE that are kept when re-generating the simulation model and that can be used for modification like other input stimuli or output checks. SimXMD only adds two include directives for simxmd mods.v and simxmd disass.v (see below). They do not conflict with the user code sections.

simxmd mods.v (copied/augmented) This file is included into the testbench and holds all the code for managing breakpoints in Run mode, keeping track of the state of the register file and logging memory changes. Because the name of the clock signal clocking the MicroBlaze is system-specific, a name-specific clock assignment is added after parsing the system.v file.

simxmd disass.v (copied) This file is included as an extra module into the testbench file. The module is a complete disassembler for the MicroBlaze instruction set. It takes an instruction word and an instruction valid signal as inputs and outputs a large bit vector that can be displayed in ModelSim as an ASCII string. When the instruction valid signal is low, the module delivers an empty string. This module is not necessary for SimXMD purposes; it is only a convenience to track assembler instructions in the wave window. simxmd disass.v can be used in other simulations independently of SimXMD. sx vpi memlog.so (copied) This is a shared library with C functions that can be called through the Verilog Programming Interface. Its purpose is to keep track of all changes to memory that the processor makes. Every time the MicroBlaze Trace Port indicates an instruction writing to memory, the Verilog testbench calls the function $memlog in this library. The memory changes are stored in a block of shared memory that can also be accessed by SimXMD to retrieve the state of a memory location. This mechanism is necessary because ModelSim only keeps the most recent memory state (which is insufficient for Replay Mode), and it obviates the need to keep track of different memory structures like local BRAM, caches and external DRAM.

12 SimXMD User Guide (c)2013 Ruediger Willenberg, University of Toronto sx mb-gdb.init (generated) This is a GDB script that starts the MicroBlaze GDB with the correct big/little endian setting (changes between MicroBlaze variations), sets the ELF file, and initiates the remote TCP connection to SimXMD. It further defines an (essentially recursive) GDB custom command named sx connect. If GDB loses the connection to SimXMD (for example anytime the simulation model is re-started, and therefore temporarily disconnects from SimXMD), typing > sx connect on the debugger console will try to re-establish the connection by calling this same script. sx clean.do (copied) This script removes SimXMD modifications from the simulation model, so that it can be run as if unchanged. It is worth noting that regular simulation is always possible even with SimXMD modifications, however the removal of all changes might allow up to a single-digit percentage gain in simulation performance. sx clean.do cannot remove the SimXMD menus from ModelSim, however they will be gone after a restart of the ModelSim GUI.

Acknowledgements

Many thanks to my Ph.D. supervisor, Paul Chow, for indulging this pet project while paying me his hard- won research grant money.

Thanks to Steven Gurﬁnkel for suggesting the term Replay mode.