We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎06-16-2019

Debugging Hardware?

I come from a software background where you can build an application with "debug info" embedded in a debug version of a program. You can single step through it and examine the source code and read/write variables etc.

Does Vivado have an equivalent to this where you can build an application (HW) with debug logic built-into it and single-step the "time" where a "step" is one or one/half clock cycles so you can examine all memory cells and logic levels in the design etc?


0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
Registered: ‎06-21-2018

Re: Debugging Hardware?

Hi Pablo,

You are describing Vivado Logic Analyzer, which basically probes the internal signals using an internal clock that you define.

There's also the VIO Core, which allows you to provide input as well.

To get started, take a look at this Tutorial:



0 Kudos
Scholar dgisselq
Registered: ‎05-21-2015

Re: Debugging Hardware?


There are a couple of different ways of debugging hardware, and knowing the trades of all of them is important;

  1. The first step is unit test/simulation.  This tends to be a very scripted interaction with a small piece of your design, with the goal being to convince yourself it works.  You can use $display and $monitor commands to make it feel like debug-by-printf, and output a trace when you are done so as to "see everything" within your design afterwards to know what went right or what went wrong.  I'm told Vivado has a very powerful simulation capability, although I've personally spent most of my time using Verilator.
  2. The problem with bench tests, as the first step is called, is that it can be really hard to anticipate all of the things that can go wrong with a particular piece of hardware.  For this purpose, I use formal methods.  Unlike software where formal methods aren't nearly as mature or as useful, formal methods are quite useful to find bugs within hardware designs.  Where formal methods really shine is where they exhaustively try all possible inputs to a given core in order to find a bug within that core.  This includes input combinations you could not have imagined in bench test above.  Indeed, I've personally become so addicted to this type of test, it uses only a small number of time steps, generates a minimal trace, stops as soon as it detects a bug, etc. that I've stopped doing unit tests myself--but this is really a much longer discussion.
  3. The third basic type of simulation testing is integrated simulation.  In this form of testing, you'll want to place your entire design in the simulator and interact with it as though it were the real hardware.  Are you testing an FFT spectrogram?  Run the simulator and "read" from your simulated A/D, process the simulated signal and produced a simulated VGA output on the screen.  Are you running a design with a CPU within it?  Run your program within that design when it gets into trouble.  Etc.
  4. There's also a post-synthesis type of simulation that Vivado offers that ... I still haven't gotten a good grasp of (yet).

All of these methods are more akin to running your code in a debugger than running within the ILA is.  That's not to knock the ILA.  On the contrary, each method has its purpose.  The big advantage of simulation is that you can get access to every register within your design at every time step to help yourself debug.  The problems with simulation are that it can take hours upon hours to do, create GB of information, and leave you wondering where within the trace the problem existed.  Formal methods can often find bugs faster, with 10s of kB of trace instead of GB, and point you directly to the bug instead of forcing you to search for it, but ... they struggle to handle large designs.

My whole point is that you should be using these tools before you find yourself stuck in hardware.

Yes, you can use an internal logic analyzer to debug your design within hardware.  Yes, there is a place for that.  But just like any good carpenter will have several sizes of chisels, the internal logic analyzer has it's place.

An internal logic analyzer takes up logic within your chip.  It requires resources.  It can capture some, not all, of the traces within your design.  How many?  That depends upon how much logic you wish to allocate to this purpose.  How long shall the traces be?  Again, that depends upon how much logic you wish to dedicate to this task.  There's a cost to doing this.  In general, debugging in this fashion should be your last resort.

That said, if I find myself struggling with an interaction between my design and something off chip, I often find myself needing some form of internal logic analyzer.  (I've actually never used Vivado's ILA.  It's not all that hard to make something for yourself that fits the bill, although it may not have all the bells and whistles of the professional quality software.)

Hopefully this fills in some more details for you.  Debugging hardware designs is much harder than it is in software, since you don't easily have insight into everything that's going on.


P.S.  I deal with the topic of debugging designs extensively on zipcpu.com.  Feel free to stop by for a visit.

Registered: ‎06-16-2019

Re: Debugging Hardware?

Thank you for the information. I'll be referring back to this post on occasion.
0 Kudos