Application Note
Simplifying Xilinx and Altera FPGA Debug
Debug Your FPGA Design At Full Speed
Solutions such as mixed signal oscilloscopes (MSOs) and logic analyzers with FPGAView™ enable you
to instantly move probe points within your Xilinx and Altera FPGAs without the need to recompile your
design. Plus the ability to correlate internal FPGA signal activity to board-level signals can make the
difference between hitting your schedule and missing your time-to-market window.
Introduction process of the design cycle. You can easily spend the
The phenomenal growth in design size and complexity majority of your design cycle time debugging and
continues to make the process of design verification a verifying your design. To help you with the process of
critical bottleneck for systems based on Field Programmable design debug and verification, new tools are required
Gate Arrays (FPGAs). Limited access to internal signals, to help debug your design while it is running at full
advanced FPGA packages, and printed circuit board speed on your FPGA.
(PCB) electrical noise are all contributing factors in This application note focuses on the issues and
making design debug and verification the most difficult techniques that can help you become more efficient
when debugging your FPGA systems.
Simplifying FPGA Debug
Application Note
Design Phase Debug & Verification
Phase
Verilog, Entry
VHDL
Functional Modelsim
Simulation Active-HDL,
VCS
Sinplify,
Leonardo Spectrum, Synthesis
Design Compiler FPGA
Implementation Static Timing
Analysis
Place
Vendor
Specific
Tools
Route Timing Modelsim
Back Active-HDL,
Annotation Simulation
VCS
ILA,
SignalTap,
Dynamic
Download to In-Circuit FPGA Probe,
FPGA Device Verification Logic Analyzer,
Mixed Signal
Oscilloscope
Figure 1. FPGA Design Flow.
FPGA Design Process Overview In the Design Phase you also need to look ahead to the
There are two distinct phases in bringing an FPGA Debug and Verification Phase and plan how you will
system to market: the Design Phase and the Debug and debug your FPGA in-circuit and at-speed. This should
Verification Phase (See Figure 1). The primary tasks in lead you to define the overall debug approach, help
the Design Phase are entry, simulation, and implementation. identify any test and measurement tools required, and
The primary tasks in the Debug and Verification Phase identify any impact that the chosen debug method has
are to validate the design and correct any bugs found. on the design of the board.
The Design Phase The Debug and Verification Phase
Not only is the design captured in this phase, but During the Debug Phase, you need to find the hard
debugging begins with the use of simulation tools. The problems that were not caught by simulation. Doing this
proper use of simulation has proven to be an effective in a time-effective way is the challenge.
way of finding and correcting many design errors. In this application note, we will look at how to select the
However, simulation should not be relied upon as the proper FPGA debug methodology, how to effectively
only tool to debug a FPGA design. There are too many plan for debug during the design phase, and how to
things that simulation just can not catch. harness the power of new methodologies that allow you
see many internal FPGA signals using just a few FPGA
pins. Done properly, this will allow you to breakthrough
your most difficult FPGA debug problems.
2 [Link]/fpga
Simplifying FPGA Debug
Application Note
FPGA Debug Methodologies Pins vs. Internal Resources
The key choice that needs to be made in the design Embedded logic analyzer cores use no additional pins
phase is which FPGA debug methodology to use. since they are accessed via the existing JTAG pins. This
Ideally, you want a methodology that is portable to all of means that you can use this method even if your design
your FPGA designs, provides you insight into both your is pin-constrained. The trade-off is that you use internal
FPGA operation and your system operation, and gives FPGA logic resources and memory blocks that could be
you the power to pinpoint and analyze difficult problems. used to implement your design. Also, since internal
There are two basic in-circuit FPGA debug methodologies: memory is used to capture the data, memory depths
the use of an embedded logic analyzer and the use of tend to be relatively shallow.
external test equipment, such as a mixed signal oscillo- Probing vs. Operating Mode
scope or logic analyzer. The choice of which methodology
The probing for an embedded logic analyzer core is
to use depends on the debug needs of your project.
simple. It uses the existing JTAG pins, so you do not
Embedded Logic Analyzer Core need to worry about how to connect an external logic
The major FPGA vendors offer embedded logic analyzer analyzer to your system. The trade-off is that while the
cores. Examples include SignalTap® II from Altera and embedded logic analyzer gives you visibility into the
ChipScope™ ILA from Xilinx. These intellectual property operation of your FPGA, you do not have a way of
blocks are inserted into your FPGA design and provide correlating that information to board-level or system-
both triggering capability and storage capability. FPGA level information. The correlation of signals inside the
logic resources are used to implement the trigger circuit FPGA with those outside of the FPGA is often critical
and FPGA memory blocks are used to implement to solving the toughest of debug challenges.
the storage capability. JTAG is used to configure the
Cost vs. Flexibility
operation of the core and is used to pass the captured
data to a PC for viewing. Most FPGA vendors offer their embedded logic analyzer
cores for less than the cost of a full-functional external
Because the embedded logic analyzer uses internal
logic analyzer. As you would expect though, embedded
FPGA resources, they are most often used with larger
logic analyzer cores offer less functionality than a
FPGAs that can better absorb the overhead of the core.
full-function logic analyzer – functionality that is often
Typically you want the core to take up no more than 5%
needed to capture and analyzer your tough debug
of the available FPGA logic resources.
challenges. For example, embedded logic analyzers
As with any debug methodology, there are some trade-
can only operate in state mode – they capture data
offs that you should be aware of:
synchronous to a specified clock that is present in your
FPGA design and therefore can not provide accurate
signal timing relationships.
[Link]/fpga 3
Simplifying FPGA Debug
Application Note
External Test Equipment easiest technique is to add a debug connector to your
Because of some of the limitations of the embedded board. This will also enable you to easily correlate your
logic analyzer methodology, many FPGA designers have FPGA signals with other signals in the system.
adopted a methodology that uses the flexibility of the
Cost vs. Flexibility
FPGA and the power of an external mixed signal oscillo-
While it is true that external test equipment may have
scope such as the MSO4000 Series, or logic analyzer
a higher initial cost than an embedded logic analyzer,
such as the TLA Series.
you can also solve a wider range of problems with it.
In this methodology, internal signals of interest are
Not only is the MSO or logic analyzer useful for FPGA
routed to unused pins of the FPGA, which are then
debug, it can be used to solve your other digital and
connected to the external test equipment. This approach
mixed signal design challenges. You also get more
leverages the very deep acquisition memory in the
flexibility in acquisition modes and trigger capability.
external test equipment, which is useful when debugging
With an external MSO, you have the ability to trigger on
problems where the symptom and the actual cause are
and capture a wide variety of analog, digital, and serial
separated by a large amount of time. It also offers the
signals with very high timing resolution. With an external
ability to correlate the internal FPGA signals with other
logic analyzer, you have access to as many as 16 different
activity in the system.
trigger states and can capture very long buffers of data
As with the embedded logic analyzer methodology, in timing mode with very high timing resolution.
there are trade-offs to consider:
Selecting the Appropriate FPGA
Pins vs. Internal Resources Debug Methodology
The external test equipment approach uses very few (if Both methodologies can be useful depending on your
any) logic resources and no FPGA memory. This frees situation. The challege is to determine which approach
these resources to IMPLEMENT your functionality. The is appropriate for your design. Ask yourself the
trade-off is now that you need to dedicate some number following questions:
of incremental pins for debug. These are, obviously, pins
What are the anticipated problems?
that could have been used by your design.
If you think they will be isolated to functional problems
Probing vs. Operating Mode within the FPGA, the use of an embedded logic analyzer
The probe connections to the external test equipment is may be all the debug capability that is required. If, how-
a little more involved than the probing required for the ever, you anticipate larger debug problems that require
embedded logic analyzer approach. Rather than being you to verify timing margins, correlate internal FPGA
able to reuse the JTAG connector that is already on activity with other activity on your board, or require more
your board, you need to determine how to access your powerful triggering capability, the use of external test
FPGA signal with the MSO or logic analyzer probes. The equipment is more suited to your debug needs.
4 [Link]/fpga
Simplifying FPGA Debug
Application Note
Feature Embedded External Mixed External
Logic Analyzer Signal Oscilloscope Logic Analyzer
Sample Depth √√
Debugging Timing Issues √ √
Correlation √ √
Performance √ √
Triggering Capability √ √√
Output Pin Usage √
Acquisition Speed √ √ √
Table 1. Selecting the right FPGA Debug Methodology that meets your needs.
Will you have a need to look at at-speed timing which is a device constraint. However, with an external
information in addition to just state data? MSO you can capture up to 10M samples, and with a
An external MSO or logic analyzer allows you to see the logic analyzer you will be able to capture up to 256M
detailed timing relationships of your FPGA signals with samples. This can help you see more of the problem
resolution much less than a nanosecond. This helps and its potential cause, thus shortening your debug time.
verify that events are really happening as they are Are you more pin-constrained or resource-
designed to and allows you to verify the timing margins constrained in your design?
of your design. An embedded logic analyzer can only
Using an embedded logic analyzer requires no additional
capture data synchronous to a specified clock that is
output pins but internal FPGA resources must be used
present in your FPGA.
to implement the logic analyzer functions. Using external
How deep of a capture will you need? test equipment requires the use of additional output
You will have access to a greater sample depth with an pins but minimizes (or eliminates) the need to use
external MSO or logic analyzer. In SignalTap II for internal FPGA resources.
instance, the maximum sample depth is set to 128 Kb, Table 1 summarizes the relative strengths of each approach.
[Link]/fpga 5
Simplifying FPGA Debug
Application Note
FPGAView™
PC Board Software
FPGA Tektronix
Logic Analyzer Probe
Test Mux
USB Converter
JTAG
Figure 2. Typical FPGAView implementation.
The FPGAView™ Advantage To overcome these limitations, a method of FPGA debug
Overview of FPGAView has been created that delivers all of the advantages of
the external test equipment approach while removing its
The external test equipment method makes effective
primary limitations. First Silicon Solution’s FPGAView,
use of the “P” in FPGA to reprogram the device as
used with a Tektronix MSO4000 Series mixed signal
needed to route the internal signals of interest to what is
oscilloscope or TLA Series logic analyzer, provides a
typically a small number of pins. This is a very useful
complete solution for debugging your Xilinx and Altera
approach but it does have limitations:
FPGAs and surrounding hardware (See Figure 2). This
– Every time you need to look at a different set of
combination allows you to:
internal signals, you need to change your design
– View internal activity and external activity simultaneously
(either at the RTL-level or using an FPGA editor tool)
to route the desired set of signals to the debug pins. – Quickly change your FPGA probe points without
This is not only time-consuming but, if it requires a recompiling your design
re-compile of the design, can change the timing of – Monitor multiple internal FPGA signals per pin
the design and potentially hide the problem you need
In addition, FPGAView can handle multiple test cores in
to solve.
a single device (useful for monitoring different clock
– Typically there are a small number of debug pins and domains) and multiple FPGA devices on a JTAG chain.
the 1:1 relationship between internal signals and
debug pins limits visibility and insight into the design.
6 [Link]/fpga
Simplifying FPGA Debug
Application Note
Specify number of
debug pins
Specify Number of
Banks
Specify Mode
Specify Clock
(if using State Mode)
Power-Up Mode
Figure 3a. Example of Altera's Logic Analyzer Interface Editor used to define and insert test core.
Using FPGAView With most test cores you can specify the following
Using FPGAView consists of these easy steps: parameters:
Step 1. Configure and insert the appropriate test core Pin Count: Signifies the number of pins you want
into your FPGA design dedicated to your external test equipment interface.
Step 2. Configure FPGAView to match your Bank Count: Signifies the number of internal signals
debug environment that you want to map to each pin.
Step 3. Establish the mapping of FPGA pins to MSO Output/Capture Mode: Selects the type of acquisition
or TLA logic analyzer channels you want to perform. You can select Combination/Timing
or Registered/State.
Step 4. Make your measurement
Clock: If you selected a capture mode of
Each of these steps is described in more detail in the
Registered/State, this allows you to select the
following sections.
sample clock for the test core.
Step 1. Insert Core After selecting the appropriate parameters for your
The first step is to configure the test core and insert it debug requirements, you need to select which pins will
into your design. For example, when using Altera be used by the test core for output. You will also need
devices, you use Altera’s Logic Analyzer Interface Editor to select which signals are to be probed and groups
to create a test core that best suits your need (See those signals into banks.
Figure 3a). FS2's On-Chip Instrumentation Generator
(OCIGEN) is used to specify and insert a test core into
Xilinx devices (See Figure 3b).
[Link]/fpga 7
Simplifying FPGA Debug
Application Note
Figure 4. Configuring the connection to the
JTAG Programming Cable.
Figure 3b.
Figure 5a. Configuring the connection to the TLA.
Step 2. Configure FPGAView to
match your debug environment
From the FPGAView window, you
establish the connection to the JTAG
programming cable (See Figure 4) as
well as connecting to the external test
equipment. Figure 5a and 5b show
the connection to the TLA Series logic
analyzer, MSO4000 Series oscilloscope,
or PC workstation. These configurations
provide you with the flexibility needed
to match your debug challenges.
Figure 5b. Configuring the connection to the MSO4000.
8 [Link]/fpga
Simplifying FPGA Debug
Application Note
Figure 6. FPGAView maps pins quickly and easily.
Step 3. Map FPGA Pins to Mixed Signal Oscilloscope To do this, simply click on the Probes button to bring up
or Logic Analyzer
a drag-and-drop window for connecting the test core
The next step is to map the physical connection output signal names with the correct channels on the
between the FPGA pins and the MSO4000 Series mixed logic analyzer (See Figure 6). This assignment process
signal oscilloscope or TLA Series logic analyzer. This will is only necessary once for a given target connection.
allow FPGAView to automatically update the signal
names displayed on the MSO or logic analyzer to match
those of the signals in the FPGA design currently being
monitored by the test core.
[Link]/fpga 9
Simplifying FPGA Debug
Application Note
Figure 7. Select desired Bank of signals to measure.
Step 4. Make Your Measurement FPGAView also programs the MSO4000 Series mixed
The Bank list pull-down lets you select which Bank you signal oscilloscope or TLA Series logic analyzer with
want to measure. Once the Bank is selected, FPGAView these names into the assigned channels making it easy
communicates to your FPGA via the JTAG interface and to interpret your measurement results. To measure a dif-
configures the test core so that the desired Bank is selected. ferent set of internal signals, you simply choose a differ-
ent bank of signals (See Figure 7). Correlating these
FPGA signals with other signals in your system
is done automatically by the full-featured MSO4000
Series (See Figure 8a) or TLA Series (See Figure 8b).
10 [Link]/fpga
Simplifying FPGA Debug
Application Note
Figure 8b. TLA Series logic analyzer automates and simplifies
Figure 8a. MSO4000 Series mixed signal oscilloscope and many measurements.
FPGAView simplify FPGA system debug.
Summary FPGAView make the external test equipment approach
By carefully considering your debug needs during the even more appealing. The ability to instantly move
design phase, you will be able to select the appropriate probe points without the need to recompile your
debug methodology that will both simplify the process design and the ability to correlate internal FPGA signal
and help save you time. The embedded logic analyzer activity to board-level signals can make the difference
and external test equipment approaches have their own between hitting your schedule and missing your
strengths and weaknesses, but new methods such as time-to-market window.
[Link]/fpga 11
Contact Tektronix:
ASEAN / Australasia (65) 6356 3900
Austria +41 52 675 3777
Balkan, Israel, South Africa and other ISE Countries +41 52 675 3777
Belgium 07 81 60166
Brazil & South America (11) 40669400
Canada 1 (800) 661-5625
Central East Europe, Ukraine and the Baltics +41 52 675 3777
Central Europe & Greece +41 52 675 3777
Denmark +45 80 88 1401
Finland +41 52 675 3777
France +33 (0) 1 69 86 81 81
Germany +49 (221) 94 77 400
Hong Kong (852) 2585-6688
India (91) 80-22275577
Italy +39 (02) 25086 1
Japan 81 (3) 6714-3010
Luxembourg +44 (0) 1344 392400
Mexico, Central America & Caribbean 52 (55) 5424700
Middle East, Asia and North Africa +41 52 675 3777
The Netherlands 090 02 021797
Norway 800 16098
People’s Republic of China 86 (10) 6235 1230
Poland +41 52 675 3777
Portugal 80 08 12370
Republic of Korea 82 (2) 6917-5000
Russia & CIS +7 (495) 7484900
South Africa +27 11 206 8360
Spain (+34) 901 988 054
Sweden 020 08 80371
Switzerland +41 52 675 3777
Taiwan 886 (2) 2722-9622
United Kingdom & Eire +44 (0) 1344 392400
USA 1 (800) 426-2200
For other areas contact Tektronix, Inc. at: 1 (503) 627-7111
Updated 1 June 2007
Our most up-to-date product information is available at: [Link]
Copyright © 2007, Tektronix. All rights reserved. Tektronix products are covered by U.S. and foreign
patents, issued and pending. Information in this publication supersedes that in all previously
published material. Specification and price change privileges reserved. TEKTRONIX and TEK are
registered trademarks of Tektronix, Inc. All other trade names referenced are the service marks,
trademarks or registered trademarks of their respective companies.
06/07 FLGWOW 52W-20065-1
