UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
1,108 Views
Registered: ‎08-21-2013

How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

Since Intel is in the process of destroying Altera and the Altera SoC tools are unusable, I'm trying to switch to Xilinx. One of the features I really liked in Quartus was the SignalTap II Logic Analyzer. Among other things, it allowed me to store multiple debug configurations. Each .stp file had all the nets to monitor, trigger info, clock etc. I could switch between them by simply selecting the appropriate .stp file (and recompile) or turn off debug altogether.

 

I'm sure it's simple and I'm missing something obvious, but I'm having trouble figuring out how to do this with the Vivado logic analyzer.

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
1,013 Views
Registered: ‎02-09-2017

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

Hi @corestar,


Thank you for the clarification!

 

The process I described works for both methods (HDL Instantiation probing flow and Netlist insertion probing flow). All my previous explanation and commands are only to be used at run time (once you have finished your design, ran Synthesis, Implementation, and Bitstream and finally loaded the bitstream into the board). At that moment, you will have the HW Manager portion of Vivado open, which will allow you to program the board and to see the ILA data. Those commands will configure how the ILA data is displayed on the screen, as well as some basic ILA configuration, such as trigger.


Now, for actually inserting the ILA into the design and connecting its probes to nets, you can also have a TCL script to do that too. So really you have three options to insert an ILA (the two we mentioned before in UG908 + custom TCL script).

 

For example, once you have finished synthesizing your design (no ILAs yet), instead of clicking on the Set Up Debug button, you could just source a script like this:

 

create_debug_core u_ila_1 ila
set_property ALL_PROBE_SAME_MU true [get_debug_cores u_ila_1]
set_property ALL_PROBE_SAME_MU_CNT 1 [get_debug_cores u_ila_1]
set_property C_ADV_TRIGGER false [get_debug_cores u_ila_1]
set_property C_DATA_DEPTH 1024 [get_debug_cores u_ila_1]
set_property C_EN_STRG_QUAL false [get_debug_cores u_ila_1]
set_property C_INPUT_PIPE_STAGES 0 [get_debug_cores u_ila_1]
set_property C_TRIGIN_EN false [get_debug_cores u_ila_1]
set_property C_TRIGOUT_EN false [get_debug_cores u_ila_1]
set_property port_width 1 [get_debug_ports u_ila_1/clk]

connect_debug_port u_ila_1/clk [get_nets [list clk100MHz]]

set_property PROBE_TYPE DATA_AND_TRIGGER [get_debug_ports u_ila_1/probe0]
set_property port_width 4 [get_debug_ports u_ila_1/probe0]
connect_debug_port u_ila_1/probe0 [get_nets [list {my_bus[0]} {my_bus[1]} {my_bus[2]} {my_bus[3]}]]

create_debug_port u_ila_1 probe
set_property PROBE_TYPE DATA_AND_TRIGGER [get_debug_ports u_ila_1/probe1]
set_property port_width 1 [get_debug_ports u_ila_1/probe1]
connect_debug_port u_ila_1/probe1 [get_nets [list my_net1]]

create_debug_port u_ila_1 probe
set_property PROBE_TYPE DATA_AND_TRIGGER [get_debug_ports u_ila_1/probe2]
set_property port_width 1 [get_debug_ports u_ila_1/probe2]
connect_debug_port u_ila_1/probe2 [get_nets [list my_net2]]

set_property C_CLK_INPUT_FREQ_HZ 300000000 [get_debug_cores dbg_hub]
set_property C_ENABLE_CLK_DIVIDER false [get_debug_cores dbg_hub]
set_property C_USER_SCAN_CHAIN 1 [get_debug_cores dbg_hub]
connect_debug_port dbg_hub/clk [get_nets u_ila_1_clk100MHz]

The code above is a basic flow I copied from one of my projects. It creates an ILA with 3 probes, and connect the nets/bus in my design to it.

 

So you could have several scripts like this and just source the one you want after the synthesis. What is the catch? Just like in Altera's product, you have to re-compile it every time you source a new script. In Xilinx flow, you'd have to re-run the Implementation (Place & Route).

at this point you have to be aware that the Implementation process can take from a few minutes to complete to one or several hours (if your design is massive). If you do have a massive design, you might not want to wait for 1h+ every time you want to switch the ILA. That's why I suggested the process in my first message. My logic was, if you don't really want to re-Implement the project every time, just implement a single ILA with several probes (up to 1024 probes, each with a maximum width of 4096 nets) and use those scripts to organize the visualization (so you can only see the few probes you are interested at a time).

 

By the way, the script for ILA insertion that I provided above is also created by the Set Up Debug Wizard process. You can run the Wizard once and then check the sources XDC file. All those commands will be there and you can copy, modify and save them in a separate file, so you can source it next time and not have to go through the GUI again.

 

Please let me know if that helps you.

 

Thanks,

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
6 Replies
Moderator
Moderator
1,051 Views
Registered: ‎02-09-2017

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

Hi @corestar,

 

Thanks for the great question.

 

The ILA is treated as regular IP, which needs to be Placed & Routed and utilizes the FPGA resources. Therefore, there is not a simple way to just change the probes and clocks that are connected to it just by changing a file.

 

What you can do is to connect all the signals/nets you might want to probe to the ILA and in the HW Manager, when seeing the ILA Waveforms and Triggers,  you can configure which probes you want to see, configure Names, Radix and other options, and remove all the other probes from the view. This can be done either manually through the GUI or by running a TCL script. 

 

As an example, in the ILA below you can manually remove the probes (as shown).

ILA_delete_probes.jpg

 

Or you could issue the TCL command:

remove_wave { {axi_bready} {axi_bvalid} }

Similarly, you can add back those probes (or any other probe) with the command:

add_wave -into {hw_ila_data_1.wcfg} -radix hex { {axi_bready} {axi_bvalid} }

 

You can modify any pararameter for each probe with the command set_property. For example, renaming the probe axi_bvalid to MY_PROBE:

set_property NAME.CUSTOM MY_PROBE [get_hw_probes axi_bvalid -of_objects [get_hw_ilas -of_objects [get_hw_devices xczu9_0] -filter {CELL_NAME=~"u_ila_0"}]]

You can query all the available parameters for a probe with the command report_property:

report_property [get_hw_probes axi_bvalid -of_objects [get_hw_ilas -of_objects [get_hw_devices xczu9_0] -filter {CELL_NAME=~"u_ila_0"}]]

Property               Type    Read-only  Value
CAPTURE_COMPARE_VALUE  string  false      eq1'bX
CLASS                  string  true       hw_probe
COMPARATOR_COUNT       int     true       4
DISPLAY_AS_ENUM        bool    false      1
DISPLAY_RADIX          enum    false      HEX
HW_ILA                 string  true       hw_ila_1
IS_DATA                bool    true       1
IS_TRIGGER             bool    true       1
IS_VIRTUAL             bool    true       0
LINK_TO_WAVEFORM       bool    false      1
MAP                    string  true       probe29[0]
NAME                   string  true       axi_bvalid
NAME.CUSTOM            string  false      MY_PROBE
NAME.LONG              string  true       axi_bvalid
NAME.SELECT            enum    false      Custom
NAME.SHORT             string  true       axi_bvalid
PROBE_PORT             int     true       29
PROBE_PORT_BITS        int     true       0
PROBE_PORT_BIT_COUNT   int     true       1
SOURCE                 enum    true       netlist
TRIGGER_COMPARE_VALUE  string  false      eq1'bX
TYPE                   string  true       ila
WIDTH                  int     true       1

You can use the same command to query the available configuration options for the ILA:

report_property [get_hw_ilas -of_objects [get_hw_devices xczu9_0] -filter {CELL_NAME=~"u_ila_0"}]
Property                                       Type    Read-only  Value
CELL_NAME                                      enum    true       u_ila_0
CLASS                                          string  true       hw_ila
CONTROL.CAPTURE_CONDITION                      enum    false      AND
CONTROL.CAPTURE_MODE                           enum    false      ALWAYS
CONTROL.DATA_DEPTH                             int     false      1024
CONTROL.TRIGGER_CONDITION                      string  false      AND
CONTROL.TRIGGER_MODE                           enum    false      BASIC_ONLY
CONTROL.TRIGGER_POSITION                       int     false      512
CONTROL.TRIG_OUT_MODE                          enum    true       DISABLED
CONTROL.TSM_FILE                               string  false      
CONTROL.WINDOW_COUNT                           int     false      1
CORE_REFRESH_RATE_MS                           int     false      500
CORE_UUID                                      string  true       23E7D65A79BC59F7BC47406C1714DFAE
NAME                                           string  true       hw_ila_1
STATIC.ILA_CLOCK_FREQ                          int     true       0
STATIC.IS_ADVANCED_TRIGGER_MODE_SUPPORTED      bool    true       1
STATIC.IS_BASIC_CAPTURE_MODE_SUPPORTED         bool    true       1
STATIC.IS_TRANSITIONAL_CAPTURE_MODE_SUPPORTED  bool    true       0
STATIC.IS_TRIG_IN_SUPPORTED                    bool    true       0
STATIC.IS_TRIG_OUT_SUPPORTED                   bool    true       0
STATIC.MAX_DATA_DEPTH                          int     true       1024
STATIC.PORTS.COUNT                             int     true       37
STATIC.PORTS.PORT_0.COMPARATOR_COUNT           int     true       4
STATIC.PORTS.PORT_0.IS_DATA                    bool    true       1
STATIC.PORTS.PORT_0.IS_TRIGGER                 bool    true       1
STATIC.PORTS.PORT_0.WIDTH                      int     true       3
STATIC.PORTS.PORT_1.COMPARATOR_COUNT           int     true       4
STATIC.PORTS.PORT_1.IS_DATA                    bool    true       1
STATIC.PORTS.PORT_1.IS_TRIGGER                 bool    true       1
STATIC.PORTS.PORT_1.WIDTH                      int     true       2
STATIC.PORTS.PORT_2.COMPARATOR_COUNT           int     true       4
STATIC.PORTS.PORT_2.IS_DATA                    bool    true       1
STATIC.PORTS.PORT_2.IS_TRIGGER                 bool    true       1
STATIC.PORTS.PORT_2.WIDTH                      int     true       32
STATIC.PORTS.PORT_3.COMPARATOR_COUNT           int     true       4
STATIC.PORTS.PORT_3.IS_DATA                    bool    true       1
STATIC.PORTS.PORT_3.IS_TRIGGER                 bool    true       1
STATIC.PORTS.PORT_3.WIDTH                      int     true       4
STATIC.TIME_TAG_PORT                           int     true       -1
STATIC.TIME_TAG_WIDTH                          int     true       0
STATIC.TSM_COUNTER_0_WIDTH                     int     true       16
STATIC.TSM_COUNTER_1_WIDTH                     int     true       16
STATIC.TSM_COUNTER_2_WIDTH                     int     true       16
STATIC.TSM_COUNTER_3_WIDTH                     int     true       16
STATUS.CORE_STATUS                             string  true       IDLE
STATUS.DATA_DEPTH                              int     true       1
STATUS.IS_TRIGGER_AT_STARTUP                   bool    true       0
STATUS.SAMPLE_COUNT                            int     true       0
STATUS.TRIGGER_POSITION                        int     true       0
STATUS.TSM_FLAG0                               bool    true       0
STATUS.TSM_FLAG1                               bool    true       0
STATUS.TSM_FLAG2                               bool    true       0
STATUS.TSM_FLAG3                               bool    true       0
STATUS.TSM_STATE                               int     true       0
STATUS.WINDOW_COUNT                            int     true       1
TRIGGER_START_TIME_SECONDS                     string  true       
TRIGGER_STOP_TIME_SECONDS                      string  true       

 

You can also customize triggering options, such as:

set_property TRIGGER_COMPARE_VALUE eq1'b1 [get_hw_probes axi_bvalid -of_objects [get_hw_ilas -of_objects [get_hw_devices xczu9_0] -filter {CELL_NAME=~"u_ila_0"}]]

The command above is the same as configuring the ILA to trigger when the probe MY_PROBE == 1.

 

Since you are new to Vivado and ILA, you probably are not used to these commands and might find it overwhelming. So please realize that every configuration that you perform manually on the GUI automatically issues the equivalent TCL command in the console. This way, you can play around in the GUI and then just copy the TCL commands, modify as needed, and save then to a TCL script that you can source latter and have all those configuration be done at once.

TCL_console_commands.JPG

 

Once you have a script ready, you can just source then using the source command:

source source C://Users/anunesgu/Documents/my_script.tcl

 

In addition, the ILAs are created by clock domain, so if you are probing signals on two (or more) different clock domains, you will have two (or more) ILAs available for viewing in the HW Manager (two tabs named ila_0, ila_1, etc.). You will also need two TCL scripts to customize the visualization for each ILA.

 

Please let us know if you have any doubts or questions.

 

Thanks!

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Explorer
Explorer
1,018 Views
Registered: ‎08-21-2013

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

Hello @anunesgu,

 

Thanks for the great answer. I think I may need to clarify the question a bit. In SignalTap, there are two ways to work: 1) modify the HDL code to manually add debug cores, 2) Select nets from a list in the GUI and have it dynamically configure the debug cores with no changes to HDL source (except for occasionally having to tell it not to synthesize away a net of interest).

 

As I understand it, Vivado is similar and calls the first method "HDL instantiation probing
flow" and the second "netlist insertion probing flow" (see below from UG 908). It looks like your answer concerns the first option. Being the lazy sort, I almost always use the second method since I don't need to change the HDL code.

 

I played with the netlist insertion method and it in fact it lets me setup netlists, clocks, depth of ILA, triggers etc and seems to work. But I could not find any method of saving all the above to a file similar to the SignalTap .stp file.

 

I take it no such method exists and using tcl scripts might be the best option? If so, consider it a feature request :-). SignalTap is the one thing Altera did right. I used it routinely and have about 40 different .stp files for my current project that I'm looking at moving to Xilinx.

 

I think your answer gives me enough information that I can probably do it with tcl, but as you say, it's not very convenient.

 

 

 

vivado_logic_analyzer_flow.jpg

0 Kudos
Explorer
Explorer
1,032 Views
Registered: ‎08-21-2013

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

@anunesgu,

 

Thanks for the detailed response. I should clarify my question. SignalTap has two methods on specifying nets to debug 1) edit HDL code to insert debug cores, 2) choose nets in a GUI with no changes to HDL (except occasionally marking nets to stop them being synthesized away).

 

It looks like Vivado has similar options 1) "HDL Instantiation probing flow" 2) "netlist insertion probing flow" (see below from UG908).

 

Your answer seems to be for the first method. Being the lazy sort, I tend to use the second method. I tried it and it does in fact let me specify the nets, clocks, depth, triggers etc. But I could not find a way to save all this to a configuration file similar to the SignalTap .stp file.

 

I take it there is no way to do this. If so, consider it a feature request :-). SignalTap is the one thing Altera did right. They made it so easy to use, I do so routinely. The project I'm considering moving to Xilinx has about 40 .stp files.

 

Your answer provides enough info that I'm sure I can do this with tcl, but as you say, it is not very convenient.

 

 

 

vivado_logic_analyzer_flow.jpg

0 Kudos
Moderator
Moderator
1,014 Views
Registered: ‎02-09-2017

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

Hi @corestar,


Thank you for the clarification!

 

The process I described works for both methods (HDL Instantiation probing flow and Netlist insertion probing flow). All my previous explanation and commands are only to be used at run time (once you have finished your design, ran Synthesis, Implementation, and Bitstream and finally loaded the bitstream into the board). At that moment, you will have the HW Manager portion of Vivado open, which will allow you to program the board and to see the ILA data. Those commands will configure how the ILA data is displayed on the screen, as well as some basic ILA configuration, such as trigger.


Now, for actually inserting the ILA into the design and connecting its probes to nets, you can also have a TCL script to do that too. So really you have three options to insert an ILA (the two we mentioned before in UG908 + custom TCL script).

 

For example, once you have finished synthesizing your design (no ILAs yet), instead of clicking on the Set Up Debug button, you could just source a script like this:

 

create_debug_core u_ila_1 ila
set_property ALL_PROBE_SAME_MU true [get_debug_cores u_ila_1]
set_property ALL_PROBE_SAME_MU_CNT 1 [get_debug_cores u_ila_1]
set_property C_ADV_TRIGGER false [get_debug_cores u_ila_1]
set_property C_DATA_DEPTH 1024 [get_debug_cores u_ila_1]
set_property C_EN_STRG_QUAL false [get_debug_cores u_ila_1]
set_property C_INPUT_PIPE_STAGES 0 [get_debug_cores u_ila_1]
set_property C_TRIGIN_EN false [get_debug_cores u_ila_1]
set_property C_TRIGOUT_EN false [get_debug_cores u_ila_1]
set_property port_width 1 [get_debug_ports u_ila_1/clk]

connect_debug_port u_ila_1/clk [get_nets [list clk100MHz]]

set_property PROBE_TYPE DATA_AND_TRIGGER [get_debug_ports u_ila_1/probe0]
set_property port_width 4 [get_debug_ports u_ila_1/probe0]
connect_debug_port u_ila_1/probe0 [get_nets [list {my_bus[0]} {my_bus[1]} {my_bus[2]} {my_bus[3]}]]

create_debug_port u_ila_1 probe
set_property PROBE_TYPE DATA_AND_TRIGGER [get_debug_ports u_ila_1/probe1]
set_property port_width 1 [get_debug_ports u_ila_1/probe1]
connect_debug_port u_ila_1/probe1 [get_nets [list my_net1]]

create_debug_port u_ila_1 probe
set_property PROBE_TYPE DATA_AND_TRIGGER [get_debug_ports u_ila_1/probe2]
set_property port_width 1 [get_debug_ports u_ila_1/probe2]
connect_debug_port u_ila_1/probe2 [get_nets [list my_net2]]

set_property C_CLK_INPUT_FREQ_HZ 300000000 [get_debug_cores dbg_hub]
set_property C_ENABLE_CLK_DIVIDER false [get_debug_cores dbg_hub]
set_property C_USER_SCAN_CHAIN 1 [get_debug_cores dbg_hub]
connect_debug_port dbg_hub/clk [get_nets u_ila_1_clk100MHz]

The code above is a basic flow I copied from one of my projects. It creates an ILA with 3 probes, and connect the nets/bus in my design to it.

 

So you could have several scripts like this and just source the one you want after the synthesis. What is the catch? Just like in Altera's product, you have to re-compile it every time you source a new script. In Xilinx flow, you'd have to re-run the Implementation (Place & Route).

at this point you have to be aware that the Implementation process can take from a few minutes to complete to one or several hours (if your design is massive). If you do have a massive design, you might not want to wait for 1h+ every time you want to switch the ILA. That's why I suggested the process in my first message. My logic was, if you don't really want to re-Implement the project every time, just implement a single ILA with several probes (up to 1024 probes, each with a maximum width of 4096 nets) and use those scripts to organize the visualization (so you can only see the few probes you are interested at a time).

 

By the way, the script for ILA insertion that I provided above is also created by the Set Up Debug Wizard process. You can run the Wizard once and then check the sources XDC file. All those commands will be there and you can copy, modify and save them in a separate file, so you can source it next time and not have to go through the GUI again.

 

Please let me know if that helps you.

 

Thanks,

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Explorer
Explorer
1,003 Views
Registered: ‎08-21-2013

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

@anunesgu,

 

Thanks, I think I have my answer. Not nearly as convenient as SignalTap, but it will work. I'm not a big fan of the Vivado GUI and I tend to think I need to master the TCL script method (I think Xilinx calls it non-project mode) anyway. Seems like the GUI is a good way to generate example scripts.

 

 

0 Kudos
Highlighted
Explorer
Explorer
678 Views
Registered: ‎08-21-2013

Re: How to store multiple configurations for Vivado Logic Analyzer

Jump to solution

@anunesgu

 

I finally got around to actually trying this. Though it is still all a bit confusing, it effectively answers my question. I just need multiple TCL scripts to have multiple configurations. I really appreciate your detailed help.

I'll have to say, this is an area where Altera really shines. Although I've started to get used to it, the Vivado Logic Analyzer is excruciatingly difficult to use compared to Signal Tap II. I could do in minutes what will probably take hours with Vivado. I'm still trying to figure out how to display a state machine enum (button click in Signal Tap). I think many users would greatly appreciate a Xilinx version of SignalTap (though I had whined about it's quirks to Altera as well :-) ).