CPRE 488X LAB01
Lab Conventions
The following conventions are used throughout the labs:
Location of additional information or tips.
An important error or step that you should be aware of.
A reference to a chapter in the book.
Lab Overview
In this lab you will be introduced to the hardware and tools you will be using the rest of the semester. We will put together a basic system and run some demonstrations on the development board.
There is A LOT of information in this lab. Please stick with it, as most of this lab is a step-by-step walkthrough with lots of screenshots and pictures. We hope that you will use this lab as a reference for later labs if your forget some steps, since some processes involve quite a few.
During the semester you will be keeping a “lab notebook,” writing down important information from each of the labs. You can feel free to keep your own notes in the notebook as well. Some of your lab notebook entries will be required and graded.
For this lab, make a list of the errors you may encounter while using the board and log them in your lab notebook. This will be graded.
Hardware
We will be using a development board from Digilent, Inc and Xilinx called the XUP Virtex-II Development System. This board has a Virtex-II Pro series FPGA, which consists of reconfigurable FPGA “fabric” and two PowerPC firm-cores. The FPGA fabric can be configured to represent any desired digital logic at the low level. When you combine many of these small FPGA pieces together, you can build very complex hardware. The two PowerPC cores connect to the reconfigurable fabric and provide a
1 powerful processor capable of running at up to 300 MHz. There are also several “off- chip” devices, meaning they are not included in the FPGA chip itself, but on the board and connected to the FPGA. These include some DDR RAM, an RS232 (serial) port, an ethernet port, a VGA port, a Compact Flash reader/writer, and several other peripherals. We will use most of these during the course of the labs.
A diagram taken from Digilent’s reference manual for the board is shown below.
You can refer to Digilent’s website, http://www.digilentinc.com , to get the user manual and look at example designs.
Power connector and on/off switch
USB programmer connection
Programming source selection
User-programmable / general-purpose LEDs, DIP switches, and push buttons
Highlighted on the picture are the power connector and on/off switch in the upper-left, the general-purpose DIP switches and LEDs in the bottom-center, the programming source selection DIP switches in lower-right, and the programming USB connector in the upper-right. These are the basic items that will be used during this lab.
2
Take a second now to make sure that the programming source selection DIP switches (the GREEN circle above) are set in the following way: the upper set of three DIP switches should be all UP, and the lower set of two DIP switches should be all DOWN, using the orientation given in the picture. You may have trouble getting the board to program if this is not done – specifically the DONE LED, located just to the right of the DIP switches, will not light. The DONE LED lights only when the board has been programmed with a valid programming bitstream.
Software
The software we will be using during the labs comes from several vendors, but our main tools will be Xilinx tools. The IDE for developing systems with Virtex-II Pro devices (FPGA devices having both FPGA fabric and PowerPC cores) is called Xilinx Platform Studio (XPS) . This program shows your projects at the component-level. Processor cores are used to run the software portions of your design, while FPGA hardware cores create the hardware portion of your design. When intermixed, we create a fully- functioning hardware/software system.
Several other tools, like XMD and the software debugger (GDB) will be mentioned below for completeness but discussed in more detail when it becomes necessary.
A standard use-case for the tool set is given below.
1) Choose the hardware cores you will be using and add them to your design. 2) Write the software portions of the system using XPS. 3) Synthesize and compile the hardware and software portions of your system, respectively. 4) Download the hardware bitstream to the development board. 5) Download the software to the development board (if necessary) using XMD. 6) Run software 7) If design is not correct, debug using GDB or ChipScope, and possibly revisit steps 1 or 2
XPS Base System Builder
Open Xilinx® Platform Studio (XPS) .
Select the Base System Builder Wizard.
3
Click OK .
Browse to a project path that you will use for your labs. Currently you cannot work from a network drive in XPS. Therefore you will have to work from a local directory and then transfer your files before you leave the lab. Some of the projects can be fairly large (60- 90MB) so it is recommended that you use your university account space, (which will be mapped automatically if your university password and your engineering password is the same), or a personal USB drive.
The directory you need use is:
“C:\temp\
1. The path cannot contain spaces! 2. It is important to make sure you put all your files in the C:\temp\
4
Then check “ User Peripheral Repository search…” and Browse to the library directory for the XUP V2Pro board “ C:\EDK\xup_2vp30 ”.
Click OK .
5 In Base System Builder, choose “ I would like to create a new design ”.
Click Next .
6 Choose “ I would like to create a system for the following development board ”.
Board Vendor: Xilinx® Board Name: XUP Virtex-II Pro Development System Board Revision: C
Click Next .
7
Choose “ PowerPC ” for our processor design.
Click Next .
8 For the next screen, we set the processor clock frequency, bus frequency, and JTAG interface. We’ll use the default settings.
Click Next .
9 The next window allows you to specify which hardware you will be using on the board. For future designs using base system builder you will want to decide all of the hardware you will need beforehand and add them using this screen. Everything added with these screens can be added manually later in the design, but it is much easier to specify the peripherals now.
For this system we will be using: o RS232 UART at 9600 baud (** Don’t forget this!) o LEDs (4-bits because there are 4 user-programmable LEDs on the board) o Push Buttons (5-bits for up, down, left, right, and enter) o DDR RAM (256 MB)
Select hardware to match the following screens:
10 11 12 Choose the amount of BRAM (Block RAM) you will be using in your design. This is a limited amount of very fast memory which is built into the FPGA (on-chip). For most of your systems this BRAM is not large enough to hold the actual program (max size is 128 kB), but instead it is used to boot the PowerPC processor and direct it to start executing the program stored in the DDR RAM.
At least one BRAM is required by all designs using a PowerPC processor.
Set the size of the included BRAM on the next screen to 64 kB.
13 In the next screen we set the device which will act as STDIN and STDOUT, the two standard interfaces in C/C++ to which all printf() commands write. We will also let Base System Builder generate a sample application.
If you do not correctly associate STDIN and STDOUT with a device, you will receive errors when compiling code using printf() statements or any other statement which attempts to write or read from the input or output. This can be changed later from the “Software Settings
Base System Builder will provide some test code for you if you want, however we will not be using this feature for our introductory lab.
If your system is not working and you think that bad hardware is to blame, you can run the “golden configuration” which is built into each Digilent board. Set the two lower Programming Source DIP switches to the UP position, connect to the serial port using TeraTerm (described later in this lab) at 9600 baud, and reset the power on the board to run the golden configuration.
14 The next screen allows you to review the system being built.
Click Generate .
15 Once finished, you should get the “Congratulations” screen.
Click Finish to load the generated project into XPS.
16
Select “ Start Using Platform Studio ”.
Click OK .
17 Now, you should have the system design loaded. Along the left side is a tree-list of your system. Each entry is a hardware element that is included in your design. We will learn how to add hardware cores in a later lab.
On the left side of the screen
Presentation Area - Source Code - System Information
System HW and Application SW tabs
Output - Compilation/Synthesis results - Project information
For now, click the “ Applications ” tab (in RED ) to switch to the applications view.
18 The initial project has no software applications included. We need to create a new application for our lab. Add a new SW Application project by right-clicking “Software Projects” and choosing “Add SW Application Project…”
Name your new project Lab_1 and leave the processor set to ppc405_0.
19 By default our project has been set to be initialized in BRAM. This means that the program will be stored in memory on the FPGA. However, our program will be larger than can fit in the BRAM memory, so we need to change it to use the DDR RAM. Additionally, we must set the “bootloop” program to be initialized into BRAM. This keeps the processor in a known state after we load the hardware and before we load the software. Right-click on “ Default: ppc405_0_bootloop ” and select “ Mark to Initialize BRAMs ”.
We also have to set our project, Lab_1 , to be stored into DDR RAM. To do this, first un- check the “ Mark to Initialize BRAMs” settings for Lab_1 .
20 After this step your Applications tab should look like this:
One final note before our system is complete: In order for the DDR RAM to work properly you will have to add the following two lines to the UCF file . This is very important , because if you forget these lines, the DDR RAM may appear to work and your program may even run, but it may fail in seemingly random parts and can be very hard to debug. Remember that you will always need to have the following lines in the UCF :
INST "dcm_1/dcm_1/DCM_INST" CLKOUT_PHASE_SHIFT = "FIXED"; INST "dcm_1/dcm_1/DCM_INST" PHASE_SHIFT = "80"; To open the UCF file, switch the left panel to the System view tab, and find the UCF File under the Project Files heading.
Add the above two lines anywhere in the file, then save and close it.
21
Now we are ready to compile and synthesize the software and hardware components of the system. Go to Tools -> Download . This will take about 5 minutes to synthesize the hardware for your design.
Be sure your board is connected and powered up so that when synthesis is finished, the bit-stream can be loaded on the FPGA. If you did not have the board on, simply turn it on and choose Tools -> Download again. If the hardware of the design has not changed, XPS will realize this and will download the bitstream that you just completed building – it will not take another 5 minutes to synthesize.
When you are finished, you should see the following output in the XPS output window, note the Programmed successfully line about 7 lines from the bottom:
Once the bit-stream is loaded, the hardware portion of our design is loaded. Check that the DONE LED – next to the programming source DIP switches - is lit. This means that a valid hardware bitstream has been successfully loaded.
Software Now we need add and compile the software portion of our design and load it onto the PowerPC core.
We use a linker script to tell the compiler (the linker, technically) where to put the software in memory. The generate linker script dialog shows many different sections of the program and where they will be put in memory. You don’t have to understand what these sections mean, just understand that they represent where parts of the program are stored in memory.
22 To place the program in DDR, set all of the sections including the heap and stack , but not .boot and .boot0 into DDR RAM.
Make sure to also set the Heap and Stack to be stored in DDR RAM. The settings for the head and stack are in the upper-right corner of the Generate Linker Script… dialog.
In general, we will put all of the sections in the left-hand side of the generate linker script dialog into DDR EXCEPT .boot and .boot0, which must ALWAYS be placed in BRAM.
Our program also requires a larger stack and heap than the default - change the stack and heap size (in the upper-right corner) to be 0x4000 .
The final linker script after modifications should look like:
Click “ Generate ” to complete the process.
Now copy the provided system.c file to the project directory. Place it in a new directory called “ code ”. This directory should be inside your project directory, so the path will be: “C:\temp\
23
Then add the new system.c file to the project. Add the file by right-clicking on “Sources ” and choosing “ Add File…”.
Before we build the program, we will disable optimizations because they can make debugging difficult. Double-click on “ Project: Lab_1 ” and find the “ Optimization ” tab. Change the “ Optimization Level ” to “ No Optimization ”. Also make sure that in the Debug Options section, the Create symbols for debugging checkbox is selected.
24
For a more detailed explanation of these options, you can look at GNU compiler tools section of the EDK documentation at file:///C:\EDK\doc\est_rm.pdf or the GNU GCC compiler’s user manual, located online at http://gcc.gnu.org/onlinedocs/ . We are using GCC version 3.4.1.
To build the program, choose Tools -> Build All User Applications . This will build the libraries needed to access the hardware we will be using, as well as building our actual application. When it is done, you will see this in bottom of the log window:
There is a bug in XPS that sometimes does not display errors and may look like compilation is correct, when it is not. There is an easy way to check if this is happening, however: make sure you see the lines starting with “text” and the size of the program (as the number 2622 above, but your programs may be different). If you simple see the line “Done.” without any numbers and sections breakdown, you are probably experiencing the bug and should assume your compilation failed.
25 Also, the name of your .elf file will not be displayed and it will not physically exist on the hard drive. If you experience this bug, try cleaning your software and trying again by going to Tools -> Clean -> Program. Then recompile using Tools -> Build All User Applications.
Now you have a completed software application (executable.elf) and it is time to load it onto the processor. This will be done using the Xilinx® Microprocessor Debugger (XMD) . Choose Tools -> XMD . A box will come up asking you chose a processor instance. The Virtex II Pro FPGA we are using has two PPC405 processors on it.
Select “ ppc405_0 ” and click OK .
A message stating “ Please set the XMD Debug Options in Options->XMD Debug Options before running xmd” will appear.
Click OK.
When the next window “XMD Debug Options ” comes up, do not change any settings and just click “ Save ”.
XMD will now try to connect to the PowerPC target. It should not be able to connect and will look like this:
In order to make the connection we must use the proper connection type and baudrate. Currently XPS does not support our boards through the GUI, so we have a quick and easy workaround.
Type connect ppc hw -cable type xilinx_platformusb frequency 12000000
26 If it connects to your board correctly, XMD should look something like this:
Note the “ XMD: Connected to PowerPC target ” message.
If you do not get this message when you connect to your board, then the bit-stream was not loaded correctly. Sometimes an INCORRECT XMD connection looks like the following:
To minimize the time you spend trying to debug this, the following strategy is suggested: 1. Close XMD by typing “exit”. 2. Flip the power switch off, wait 2 seconds, then flip it back on.
27 3. Double-check the DONE LED is NOT lit. If it is, then check that the programming source DIP switches (the 2- and 3-switch ones) are set for programming from USB – the 3 switches all UP and the 2 switches both DOWN. If you make a change to the DIP switches, go back to step 2. 4. Download the bitstream again from XPS using Tools->Download. 5. Double-check the DONE LED is now lit. 6. Try to connect through XMD using the command given above or the xmd.ini file described below.
Instead of typing the long connect command in every time you start XMD you can create a script that will run when you start XMD. To do this, just use a text editor such as WordPad to create a new file and type in the command. Then save the file in your project folder as “ xmd.ini ” (remove any other extensions if they are added by renaming the file).
Once you have a good “ xmd.ini ” file you can copy this into your future project directories.
Now you need to tell XMD which .elf file to load (.elf files are executable files for the PowerPC). Type “ dow
You can verify the path to your executable.elf file by going to Tools -> Get Program Size in XPS and looking at the “ filename ” column. If no size is given, you might need to clean your program files using Tools -> Clean -> Program and recompile using Tools - > Build All User Applications .
Now XMD should look like this:
28 The hardware and software are now both loaded, but simply loading the software in XMD with the “ dow ” command does not start the program. To start the software, type “con ” to (con)tinue running the program.
The LEDs should blink slowly. You can stop the process by typing “stop ” in the command line for XMD. Also, “rst ” will reset the board and will stop the process as well.
In the normal case, you will be writing software, compiling it, downloading it to the board, and running it. When downloading the software to an already-running board, the following procedure is recommended in XMD: 1. Type “stop” to stop any previously running program. 2. Type “rst” to reset the board. 3. Type “dow
Now we will complete the code to allow us to change the rate of blinking using the push buttons.
In order to include the push buttons, we have to know what functions are available to interface with the hardware – i.e. we need to determine the API (Application Programming Interface) for the hardware. Documentation for each “driver” (software library to access hardware) is available from Help -> EDK Online Documentation . On the left there should be a list of links under the heading EDK Links. Click on the Documents link then scroll down to “ Driver Reference Guide”.
Click on “Driver Reference Guide ” and choose “ API Links ” in the left-hand menu. You can now see a list of all of the software drivers. The one we’re interested in is the
29 GPIO (General Purpose I/O) drivers. This same GPIO driver is used for the push- buttons, LEDs, and DIP switch inputs and outputs on the board. Click on the newest version of the gpio drivers.
This will open a webpage which you can use to find all of the functions available to interface with a GPIO piece of hardware. Click “ Globals ”, and then select “ Functions ” in the menu that appears to show all of the available functions.
Clicking on the source file link after any of the functions gives you an in-depth explanation of what each functions does. You should now be able to use this documentation to help you fill in the skeleton code given to you in the lab. We will be expecting that you know how to use this documentation system to find out how functions work and what parameters they take throughout the labs.
Software Design
When completed, pressing “ UP ” (name located directly underneath the button on the board) should increase the rate of the blinking, and pressing “ DOWN ” should decrease the rate of blinking.
30 The pushbuttons are read as a 0 when they are pressed and a 1 when they are not pressed . This is called an active-low signal, because the button is “active” when it reads as a logic level 0 from the C code.
Pushbutton “RIGHT ” is read as the least significant bit, and “LEFT ” is the second-to least significant bit by the XGpio_DiscreteRead() function (there is no way to read them individually). Use channel number 1 when you use the XGpio_DiscreteRead() function – more details are available in the XGpio_DiscreteRead() documentation.
Pushbutton bits in the push button GPIO register are arranged as follows:
Name ENTER UP DOWN LEFT RIGHT Bit 7 6 5 4 3 2 1 0
Software Debugging with printf() and xil_printf()
From here we will also show you two simple tools for debugging.
The first is the trusty printf() – however, because the normal printf() has a fairly large footprint (it takes a lot of space in memory), a special stripped-down version of printf() has been created by Xilinx. This version can be called using xil_printf() The rest of the syntax is the same as printf(), with the major exception being that there is no floating point support in xil_printf() .
You can use the TeraTerm to print debug messages from the board. To get to TeraTerm click on the TeraTerm Pro link on your desktop.
Next, set the baud rate of TeraTerm to match the baud rate of this design. Remember back in the Base System Builder we chose 9600 as the baud rate.
31
Click OK and TeraTerm should be connected to your board.
Add lines to the while(1) loop to print out ON when the LED’s are on and OFF when the LED’s are off to make sure that your serial connection between the board and the PC is working.
Software Debugging with GDB
Now we will introduce you to a very useful tool, the software debugger. The following is just a quick tutorial. It is recommended that you spend some extra time to learn the different features of the debugger to make it a more effective tool for you.
To start the software debugger, make sure that the hardware has been downloaded to the board first. Then you must start XMD and make sure that it connects to the board. After starting XMD go to Tools -> Software Debugger . This will bring up a GUI for GDB (the GNU debugger) which will serve as our debugger. This debugger has all of the standard debugging functions you might expect: breakpoints, watch windows, assembly / source code view, register viewing, memory dump, etc. It will be an important tool to finish your labs efficiently and on time. In the GUI breakpoints can be set by clicking on lines on the left part of the window.
In order run your program you must first connect to the board. To connect to the board go to Run -> Connect to Target . The connect to target dialog can be left at defaults – just click OK . This creates a connection from the debugger to XMD, and XMD forwards messages from the debugger to the board.
32 o Your program must be compiled with debugging symbols enabled for the source code to be displayed, otherwise you will only see assembly code. For Lab 1 we walked you through this already when we compiled your code, but it is not the default. o XMD must be opened and connected to the board, otherwise the software debugger will not be able to connect. o Enabling optimizations makes your code run faster, but makes debugging harder because the cursor may jump around erratically because code has been moved during compilation. Disabling optimizations while debugging is usually a good policy.
Simulation
Now we will simulate the Lab 1 LED-Blinking design.
Close the project, and then make a copy of your LAB01 project, name it “LAB01_SIM”, and work on this one instead
To simulate, we use an external simulator called ModelSim® . First we have to generate the simulation files using XPS, then we call ModelSim® from XPS. Lastly, we have to provide a clock and a reset signal for the simulation. Once this is done we can run the simulation and evaluate the system.
Since simulation takes a long time (e.g. 1 second of real time for every 10 us of simulation time), it would take a long time to simulate enough time to view the LED blinking at its current rate.
To decrease the delay by set the DEFAULT_DELAY to 100 in the C code. Also change the MIN_DELAY to 50 . Then define a new clock variable SIM_CLKS to be 100 . This new variable is the new multiplier for the delay variables. When finished your defined variables should look like this:
#define NUM_CLKS_IN_1_MS (XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ / 1000) #define SIM_CLKS 100
#define MAX_DELAY 1000 *SIM_CLKS //Maximum delay allowed in ms #define MIN_DELAY 50 *SIM_CLKS //Minimum delay allowed in ms #define DELAY_STEP 50 *SIM_CLKS //Amount delay changes from one button press in ms #define DEFAULT_DELAY 100 *SIM_CLKS //Default delay between blinks in ms
The next step to prepare your code for simulation is to comment out any xil_printf() statements in the C code. This prevents us from having to simulate every character being sent out the serial port at 9600 baud.
Next, because our design uses the SDRAM on our board to store the program instructions and data, a simulation model is not available in our tools to simulate the SDRAM. For large programs which must be run on the SDRAM, we would have to make a VHDL
33 model of the SDRAM for testing. In our case, our program is small and we can move the program to BRAM for simulation.
To do this, choose Tools -> Generate Linker Script… then move all sections of code to reside within the BRAM . This is necessary because we don’t have a core to simulate the DDR RAM therefore we need the entire program, stack & heap, to fit into BRAM. Don’t forget to move the heap and stack .
Now click “ Generate ”. The linker script places your program in memory. This tool allows us to easily change which memory our program goes into.
Next, we have to tell XPS to include the program with the bit-stream (.bit file) that contains the hardware information for the FPGA. In this sort of configuration, the software and hardware are contained in one file (.bit file) which is downloaded. XMD is not necessary in this configuration because our software is already loaded with the .bit file.
In order to include our project with the bit-stream, right-click our “ Project: Lab_1 ”, and then select the “ Mark to Initialize BRAMs ”. We also have to deselect the “ Mark to Initialize BRAMs ” line for the bootloop code (which is only necessary when our program is in external memory).
Note how the icon next to the project changes to indicate whether a program resides within the bit-stream. Make sure that your project looks like the one below (bootloop not included, Lab_1 is included) before you move on:
34
Choose Tools -> Build All User Applications to make sure that your code is updated to reflect your recent changes.
Next, setup the project for simulation. Choose Options -> Project Options .
In the “ HDL and Simulation ” tab, leave the library paths blank (default paths), be sure your settings are set as shown:
Next, choose Tools -> Generate Simulation HDL Files to begin the process of creating VHDL wrappers for your system. This process may take a few minutes.
Once complete, choose Tools -> Start HDL Simulator .
The ModelSim® program will be loaded. In ModelSim®, “.do” files are simply text files with multiple ModelSim® commands on each line. When we exported the project from
35 XPS, a “.do” file called “system.do” was created which loads and compiles all of the VHDL wrappers for our system. To run a “.do” file, you type “do
In the Transcript window of ModelSim®, type the command “ do system.do ”. This will take a few minutes
The output in the Transcript window is colorized. If you see red or yellow output during the compilation, chances are your simulation models did not compile correctly. You should go back and check out the errors, and call over your TA if you don’t understand what the problem is. ModelSim is very robust and will often times fail to compile, but will still run the portion of the system that it managed to compile. This often is confusing because the system will not behave as expected.
Once the design is finished compiling, we need to create a new “.do” file which will provide a clock and a reset signal to our system, since these are not provided by default. We want to place this .do file in a directory which won’t be wiped out when XPS regenerates another simulation. Each time XPS generates simulation files it wipes the project’s simulation directory. So a suitable directory to store your run.do file is the root directory of your project:
“C:\temp\
Get the file “run.do ” from the lab website and save it to “C:\temp\
Placing the script in the root of the project directory keeps it from getting deleted when a Tools -> Clean -> All or Tools -> Clean -> Simulation is executed. The current directory when you start ModelSim is the same place where system.do exists, in
A .do file is a script of ModelSim commands. In our case, the run.do script is where we setup some basic simulation items for you. This includes providing the clock input for the system and providing a reset signal. A screen-shot of the script is shown below for reference – of course you can open your own copy if you’d like to explore or modify the script.
36
Note : At the end of the two “force” lines the symbols surrounding the times are curly brackets, not parenthesis.
Now in ModelSim® run the do file you just created by typing “ do ../../run.do ”. This will begin the simulation and run it for 100 ns with the reset enabled. Before we let the simulation run further, we are going to add the LED and push-button signals to a waveform for easy viewing and modification.
The signals can be selected in the Objects window select View -> Debug Windows -> Objects . Note that these signals are for the module that is currently selected in the Instance sub-window within the main ModelSim® window. For instance, to view signals specific to our LEDs, select the “leds_4bit” module in the instance sub-window. The “signals” window will automatically update to show only signals in the “leds_4bit” module once it is highlighted. Find the signal “ gpio_d_out ” and add it to the waveform by right-clicking on it and select Add to Wave -> Selected Signals .
37
A waveform window will appear showing the LEDs signal.
Next we need to specify the pushbutton inputs. Find the signal “ gpio_io_i” from the pushbuttons_5bit instance and add it to the waveform just as you did for the LED signal. Note that when you add this signal, it appears as all X values. This is because this is an input and we haven’t specified any value – thus the simulator has a special value X which it assigns to all unset values. We need to fix this because the simulation cannot handle reading an input where the value is set to X.
In ModelSim terminology, setting a signal to a specific value is called “forcing” a signal to a value. For the beginning of our simulation, we want it to look like no buttons are pushed. Since our buttons are active-low , and we have 5 bits (corresponding to the 5 buttons) to set, what is the correct value to force the gpio_io_i signal to in order to simulate no buttons being pressed?
Your simulation will fail if you do not force the pushbuttons correctly. In general, if you are simulating a system from EDK in ModelSim, any inputs that your program will read cannot be X – they must be forced to a 0 or a 1. The processor simulation model does not know how to handle this case and stops execution. If this happens, the LED value will never change because your program is no longer running.
Right-click on the gpio_io_i signal which should have been added to the wavefore and select Force…
38
Then set the value to simulate that no pushbuttons are pressed – “11111”.
Then to continue running the simulation, type “ run 650us ”. This will take several minutes. As the simulation is running, you can click the “ Zoom Full ” button (the magnifying glass button just above the wave window) to view the progress of the simulation.
Next to simulate the ‘UP’ pushbutton being pressed by forcing just that bit low 10111 . Then run for another 200us. This is to give the processor time to check the status of the pushbuttons. Remember that the processor is still executing every assembly instruction, one by one, during this simulation. We are looking at microseconds, so it takes the processor what may seem like a long time to get through even a single iteration of the while() loop from our program.
39
After the 200us we just ran, the processor should be inside the while loop waiting for the pushbutton to be released. Simulate releasing the pushbutton by forcing it back to 11111 . Then run for another 200us.
Now you can use the cursors to determine whether or not the delay decreased. In order to add a new cursor right-click at the bottom of the signal window and select New Cursor . The number in white is the difference between the cursors. As you can see from the picture above the off-time for the LEDs reduced from about 218us to 115us.
ModelSim® is a very powerful tool for debugging. It can show you any signal in the entire system.
Try adding all of the signals at the top level of the system by first selecting “ system ” in the “ Instance ” sub-window, then typing “ add wave * ” in the ModelSim® Transcript window. You can also simply drag and drop the “ system ” instance into the “ wave ” window.
There is no need to run the simulation again – the data was already captured for these extra signals because of the “log” line in our run.do file. Notice the large amount of signals added to the waveform viewer. Scroll around the signals, taking special note at the signals with “plb” in the name. These are the signals which connect the PowerPC 405 core to the PLB (Processor Local Bus), to which the instruction memory is attached. We will learn more about the PPC bus architecture in the next lab.
40
If you’d like to try the simulation with a different set of inputs, restart the simulation by typing “ restart ” and click OK on the box that appears. Then go through the previously described process, starting by running the run.do file, then adding waves to the waveform, then simulating. If you change your program you must build it in XPS, then regenerate simulations files, then run the system.do file again from ModelSim.
To save your waveform setup between simulation runs, you can export it to a .do file by first making sure the waveform window is selected, then going to File -> Save As…
To quit the simulation, first type “ quit –sim ” into the ModelSim® window, then type “quit ”.
41