Scribd
Upload
135 views12 pages

Lab 5: Debugging

This document provides an overview of debugging methods for an FPGA project using Xilinx tools. It discusses: 1) Using ChipScope ILA cores to monitor signals in the FPGA design and analyze them using the ChipScope software for both the XPS and ISE flows. 2) Adding ChipScope peripherals to a project in XPS through the debug configuration GUI or manually editing a CDC file in ISE. 3) Setting triggers and analyzing captured data in the ChipScope software by setting trigger conditions and examining waveforms. 4) Remotely debugging software on the PowerPC CPU using the XMD shell interface or graphical GDB debugger launched from XPS.

Uploaded by

Ssgn Srinivasarao
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
135 views12 pages

Lab 5: Debugging

This document provides an overview of debugging methods for an FPGA project using Xilinx tools. It discusses: 1) Using ChipScope ILA cores to monitor signals in the FPGA design and analyze them using the ChipScope software for both the XPS and ISE flows. 2) Adding ChipScope peripherals to a project in XPS through the debug configuration GUI or manually editing a CDC file in ISE. 3) Setting triggers and analyzing captured data in the ChipScope software by setting trigger conditions and examining waveforms. 4) Remotely debugging software on the PowerPC CPU using the XMD shell interface or graphical GDB debugger launched from XPS.

Uploaded by

Ssgn Srinivasarao
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

18-545

VERSION 2.0

Lab 5: Debugging
Overview
This lab will give you a chance to explore different methods of debugging your project on
the FPGA board. It covers both the XPS and ISE flows. If you are using XPS look at parts
1 and 3 for hardware debugging, and part 4 for software debugging. If you are using ISE
look at parts 2 and 3 for hardware debugging.

Theory
ChipScope is the program we will use for hardware debugging. The main use of
ChipScope is for its ILA (Integrated Logic Analyzer) cores. Based on some trigger
condition the ILA will capture all the input data into an attached BRAM, and then feed
the data to the ChipScope program to be analyzed. You can have multiple ILA cores with
multiple inputs. The ILA cores feed into an ICON core that controls everything. There
are also VIO (virtual IO) cores for interacting with the FPGA internals.

For software debugging XPS provides a method of doing remote debugging of the CPU
using GDB. This allows the host to control the FPGA, stepping through and analyzing
instructions.

PAGE 1 OF 12

18-545

VERSION 2.0

Part 1: ChipScope in XPS


Step 1: Top-level ports
The first step to debugging hardware in XPS is to get the signals you want to monitor to
the top level. For this lab we will be using the adder module from Lab 4, after doing Part
2. You should have top-level ports like this:

Step 2: Add ChipScope peripherals


The easiest way to add ChipScope peripherals is to go to Debug Debug Configuration.
On the screen select Monitor Hardware Signals and then Add ChipScope Peripheral.

There are monitors for the OPB and PLB bus (useful if your device is a bus master and
generates requests of its own). We are interested in the ILA which can monitor arbitrary
signals.
Now that the ILA has been added, specify signals for it to monitor. There are up to 16
trigger groups, each of which can monitor different signals and can trigger a capture.
Select TRIG0 and add slv_reg0 to it. Likewise for TRIG1 and slv_reg1 and the rest.

PAGE 2 OF 12

18-545

VERSION 2.0

For the number of signal samples, increase it as high as reasonable, keeping in mind
that our boards have only 136 BRAMS (there is a count of how many are used at the
bottom).
Note that the default trigger units can only match on == and !=. You can change
them to match on conditionals (<, >, <=, >=) and also ranges, but it takes more logic. To
change this select the Advanced tab, then Trigger Unit. For each Trigger Unit you can
change the Match Type from basic to extended (conditionals) or range.

PAGE 3 OF 12

18-545

VERSION 2.0

Part 2: ChipScope in ISE


If you are using ISE there are two methods of adding ChipScope cores to your project.
One is to use the ChipScope Pro Generator (its a separate program on the start menu).
Using this Generator you can create the cores and instantiate them by hand. The other
option is to use the IE flow within ChipScope. This is the flow that will be explained as it
is easier to use.

Step 1: Create a CDC file


From the processes menu select Create New Source. Select ChipScope Definition and
Connection File for the type and name it something like chipscope. Associate this with
your top-level source file. Click finish to create it.

Step 2: Edit the CDC file


Now that youve created the CDC file, double click on it to edit it. This loads the
ChipScope Pro Core Inserter. Click next on the first screen (there are no options). On
the next screen select New ILA Unit. Select U0:ILA from the left.

Now configure the ILA to meet your needs. First select the number of Input Trigger
Ports, and the size of each port. You can also select the type of matching that will happen
for that port.
PAGE 4 OF 12

18-545

VERSION 2.0

Next configure the Capture Parameters for the ILA. You want to have Data Same As
Trigger, and all of the trigger ports check to be used as data. The one thing to change is
the Data Depth of the capture. The more samples captured are better, but keep track of
the BRAM Count on the left (these boards have 136 BRAMs).

PAGE 5 OF 12

18-545

VERSION 2.0

Finally go to the Net Connections tab and select Modify Connections. First connect a
clock signal from the design on the left to the clock signal channel. Next connect up the
individual ports from the left to each of the channels on the right.
You can click on ICON on the left tree and select New ILA Unit to add another analyzer.
Once you are done click on Return to Project Navigator or File Save and then File
Exit.
Now when you recompile the design it will automatically create the ChipScope cores for
you and place them within the design. If you no longer want any ChipScope cores simply
delete the CDC file and recompile.

PAGE 6 OF 12

18-545

VERSION 2.0

Part 3: Using ChipScope Software


Now that you have a project with a ChipScope peripheral in it, you can analyze it using
the ChipScope software.

Step 1: Connecting to the board


Open up ChipScope Pro Analyzer. If you are using XPS start ChipScope from the start
menu. If you are using ISE select Analyze Design Using ChipScope from the Processes
list. Once you open the program click on this button to connect to the board:

Click Unblock if a Windows Firewall warning pops up. You should then see a screen
with information of what ChipScope is connected to. Click OK

You are now presented with 3 main screens you are interested in: A list of all the signals
on the left, Trigger setup on the top, and Waveforms on the bottom.
Useful trick to start: expand the Trigger Ports, hit F2 (for rename) and hold down enter.
This will rename the data ports to match the trigger ports, making them easier to use.
Next you can make busses out of the individual wires. Highlight the wires you want to
join into a bus, right click, select Add to Bus and New Bus.

PAGE 7 OF 12

18-545

VERSION 2.0

Now that you have busses defined right-click on the Waveform window under Bus/
Signal and select Clear All. Now drag your busses from the left into the Waveform
window.

Step 2: Setting a Trigger


Now that you have the data setup you have to decide which trigger to capture. You can
simply hit the T! button at the top to cause a trigger right now. You can also cause
arbitrarily complicated trigger conditions. For each trigger select a value to match
against (in binary, hex, etc) and the function for that match (equal, less than, etc).

PAGE 8 OF 12

18-545

VERSION 2.0

Next you selected the matches, you can select how to trigger based on those. Click on
TriggerCondition0. You can make an equation for triggering based on your matching
units or trigger after a sequence of matches happens.

You can have more than one trigger condition, but only 1 can be active at any time.

Step 3: Analyze data


Once you have set up a trigger click the play button at the top:

You will now have data in your waveform screen. The waveform screen is fairly similar
to any other waveform view, like in ModelSim. You can change the radix of each bus
(right-click on it). You have two cursors to move (O and X). you can expand a bus to see
individual wires. There are also the normal zoom controls on the top menu bar.

PAGE 9 OF 12

18-545

VERSION 2.0

Part 4: Software debugging with GDB


XPS is setup to remotely debug the PowerPC CPU. This allows you to step though the
program as if you were running it within GDB on your local machine.

Step 1: Check JTAG hardware


First make sure you have the JTAG controller connected to the CPU, as shown below.

If your project does not have the jtagppc_ctrl module, you will have to add it, a 2nd
ppc405 core, and wire up the JTAG to the external ports. Its probably easier to create a
new project selecting FPGA JTAG debugging and copy everything to the new project.

PAGE 10 OF 12

18-545

VERSION 2.0

Step 2: Launch XMD


Before you launch XMD you have to configure it the first time. Go to Debug XMD
Debug Options. Select ppc405_0 as the processor (the 1st CPU). The default options are
all correct so simply click ok.
Now go to Debug Launch XMD, selecting ppc405_0 again. You should see it connect
to the FPGA and give you a basic shell prompt.

Type help to see a list of options you can type on this prompt. While you can use the
shell, its not very friendly. An easier system to use is the graphical GDB environment.
To launch that go to Debug Launch Software Debugger. Note that XMD must be
started first.

PAGE 11 OF 12

18-545

VERSION 2.0

To connect go to Run Connect to Target. This will cause a breakpoint on the CPU
wherever it is currently executing. You can also select Run Run to re-download the
program and restart it from main(). By default it sets a breakpoint at main() so you can
step the program from the start.
Within this GUI you have a full GDB environment. You can walk the execution, go to a
gdb text console, view registers, the stack, set break and watch points, etc.

Part 5: Demonstration
We are going to trust that you have worked through this lab and learned lessons that will
be very helpful on your project. Simply tell a TA that you have completed the lab. The
TA may ask you a few questions, so be prepared.

PAGE 12 OF 12

You might also like