top of page

MicroZed Chronicles: ILA Debugging Outside IP Integrator

We have used Integrated Logic Analysers (ILA) several times in our blogs and Hackster projects to ensure our designs are working as expected. However, when we’ve used them in the past, we’ve always done so by inserting the ILA within an IP Integrator design. This makes identifying the signals for observation very simple. All we have to do is connect the signals and clock to the ILA and then configure the ILA itself.

However, we do not always design our FPGA using IP Integrator. Examples of two such cases are when our design is mostly HDL-based or if we want to look inside of a HDL module included in a IP Integrator design.

Of course, in the latter case, we could break out signals from the HDL so they could be used connected to an ILA in the IP Integrator diagram. That is not very efficient, however, because it means we need to make significant changes to the RTL which then makes the IP integrator design more complicated than it needs to be.

There are, however, alternative ways to observe signals within a RTL module. There are basically two main options. Our first option is where we synthesize the design and then use the set-up debug option to select the synthesized nets to be observed by an ILA.

This works well but you do need to be able to find the synthesized object in the netlist which is of interest.

The second option is when working with HDL designs, I prefer to include the ILA connections within the HDL itself as attributes.

In my opinion, this has several advantages to using the post-synthesis insertion flow:

  1. It allows for easy identification of the HDL signals I wish to observe.

  2. Changes to the HDL are minimal because they are inserted where signals, registers, and wires are defined in either VHDL or Verilog.

  3. Observing signals in hierarchical HDL designs is easier because there is no need to dive down hierarchies when searching in a post-synthesis implementation.

I tend to write VHDL so the attributes I use to mark signals for debug are as follows:

attribute mark_debug : string;
attribute mark_debug of <signal>: signal is "true";

For Verilog we can use the following code.

(* mark_debug = "true" *) wire [7:0] <signal>;

If we do not want to put the attributes in the HDL due to company coding rules, for example, we can simply add the attributes within the XDC constraints file using the commands below.

define_attribute {n:char_fifo_din[*]} {mark_debug} {"true"}

Once we have added the attributes into the HDL, we can synthesize the design and see the allocation of probes to observation signals in the debug view.

If we need to make any changes such as what the signal is being used for e.g. triggering, or data instead of trigger and data, we can also change the ILA settings in the cell properties.

With the ILA configured as desired and the ILA connections set up, we can run the implementation and start debugging on the hardware in question.

Regardless of if we insert the ILA commands using HDL or constraints, we can observe signals easily within our designs and debug the issues we might be experiencing.

We can use this approach for 7 series, UltraScale, UltraScale+ and Versal devices. Versal, however, has some slight differences in debugging which we will look at more in depth soon.

Workshops and Webinars

If you enjoyed the blog why not take a look at the free webinars, workshops and training courses we have created over the years. Highlights include

Embedded System Book Do you want to know more about designing embedded systems from scratch? Check out our book on creating embedded systems. This book will walk you through all the stages of requirements, architecture, component selection, schematics, layout, and FPGA / software design. We designed and manufactured the board at the heart of the book! The schematics and layout are available in Altium here Learn more about the board (see previous blogs on Bring up, DDR validation, USB, Sensors) and view the schematics here.

Sponsored by AMD



bottom of page