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: 
Visitor xpress
Visitor
10,766 Views
Registered: ‎02-25-2011

How do you get sensible probe names in Vivado Analyser for ILA?

I have seen other posts regarding this so it does seem like the vivado support for chipscope is not 100%.

I have added the suggested MARK_DEBUG which does not seem to do a lot.

 

 

    ATTRIBUTE MARK_DEBUG : string;

 

    signal ncs_i       : std_logic := '1';
    attribute MARK_DEBUG of ncs_i               : signal is "TRUE";

 

    signal ila_data    : std_logic_vector(63 downto 0) := (others=>'0');

 

    ila_data(11) <= ncs_i;

 

    ila0 : ila64
        port map (
            clk     => clk,
            PROBE0  => ila_data
        );

 

I have tried to manually edit the debug_nets file as a last resort, that doesn't work either.

The names of the debug probes are not reloaded when refreshing the device.

 

A different issue is the dbg_hub which I can't find a component/module for in the libraries but that appears as by magic.

The magic is a bit flawed though, it is always connected to a clk that is not running from start so I can't use the ILAs that are are clocked by free running clocks. Could you please add a component for the dbg_hub so that I can place it in my design myself and choose a clock that is free running, I can't possibly do worse than Vivado. Also make it recognize the frequency from the input clock, why should I have to set this in Vivado, at least pull the default from the constraint on the input clock with a possibility to manually override.

screenshot.png
2 Replies
Scholar dwisehart
Scholar
10,750 Views
Registered: ‎06-23-2013

Re: How do you get sensible probe names in Vivado Analyser for ILA?

I feel your pain: I have had similar problems.  I use a multi-prong approach to dealing with these problems.

 

First, under Synthesis Settings, I change flatten_hierarchy from "rebuilt" to "none", which eliminates some renaming that happens right at the beginning.

 

Next, I run all of my ILA probes to VIO inputs, even when the VIO module is not interesting.  The reason is that anything that goes to a VIO will not be optimized away; the VIO module is there from the beginning--unlike ILA and dbg_hub which appear magically--meaning it can be located away from the design; it gives me a change to get a few registers between what I am measuring and ILA; it allows me to reclock the ILA inputs, which is especially interesting if I want to see signals together that are from different clock domains.

 

I give all of my VIO inputs common names so the constraints do not have to change and I put all of my constraints related to VIO and ILA into a separate constraint file so they can be enabled and disabled just by enabling or disabling the contraint file.

 

In my top level (Verilog) module I have (I am only showing two probes here, but normally I have 10 or so):

 

wire wVioClk;
ClockVio mVioClk
.iClk ( wExtClk ),
  .oClk ( wVioClk ) );

 

wire wPreClkA = wClkTx2;
wire [31:0] wPreA = wTxD[2];
reg [31:0] rPreA, rVioA;

 

wire wPreClkB = wClkRx2;
wire [9:0] wPreB = wRxD[2];
reg [9:0] rPreB, rVioB;

 

always @( posedge wPreClkA )
  rPreA <= wPreA;

always @( posedge wPreClkB )
  rPreB <= wPreB;

 

always @( posedge wVioClk ) begin
  rVioA <= rPreA;
  rVioB <= rPreB;
end

 

Vio mVio
.clk ( wVioClk ),
  .probe_in0 ( rVioA ),
  .probe_in1 ( rVioB ) );

 

In my debug.XDC file I have (some boiler plate removed for clarity):

 

set ILA u_ila_A
create_debug_core $ILA ila
set_property C_DATA_DEPTH 16384 [get_debug_cores $ILA]

 

set_property C_CLK_INPUT_FREQ_HZ 312500000 [get_debug_cores dbg_hub]
connect_debug_port dbg_hub/clk $CLK

 

set CLK [get_nets mFPGA/mVioClk/wVIO]
set_property port_width 1 [get_debug_ports $ILA/clk]
connect_debug_port $ILA/clk $CLK

 

set VIO [get_nets mFPGA/rVioA*]
set_property port_width [llength $VIO] [get_debug_ports $ILA/probe0]
connect_debug_port $ILA/probe0 $VIO

 

create_debug_port $ILA probe
set VIO [get_nets mFPGA/rVioB*]
set_property port_width [llength $VIO] [get_debug_ports $ILA/probe1]
connect_debug_port $ILA/probe1 $VIO

 

Then to make a change in what I am debugging I only need to change the lines that have "wire xxx =" for the clocks and signals.  You can change the width of the signals without modifying VIO: you will get a VIO warning, but the design will continue to synthesize and implement the ILA portions just fine.

 

Normally I limit signals to 10 bits wide and break larger signals into multiple ILA inputs because Chipscope seems to break them up and not in ways that are easy to recombine.

 

Last I create PBLOCK locations for the VIO, dbg_hub and my "Pre" logic, leveraging the fact that I have used consistent naming in my top level module.  This again does not have to change as I vary what I am probing with ILA, so long as I keep the names the same.

 

create_pblock Vio
set PB [get_pblocks Vio]
add_cells_to_pblock $PB [get_cells -hier -filter [list NAME =~ *Vio*]]
resize_pblock $PB -add {SLICE_X60Y389:SLICE_X97Y399}
resize_pblock $PB -add {MMCME2_ADV_X0Y7}
resize_pblock $PB -add {BUFHCE_X0Y84:BUFHCE_X1Y95}

create_pblock Dbg
set PB [get_pblocks Dbg]
add_cells_to_pblock $PB [get_cells -hier -filter [list NAME =~ dbg_hub*]]
resize_pblock $PB -add {SLICE_X52Y350:SLICE_X97Y355}

create_pblock PreVio
set PB [get_pblocks PreVio]
add_cells_to_pblock $PB [get_cells -hier -filter [list NAME =~ rPre*]]
resize_pblock $PB -add {SLICE_X138Y250:SLICE_X141Y499}

 

I find that by moving the VIO and dbg_hub blocks to a different clock region, I pull ILA into that new clock region and get all of them out of the way of my design, simplifying timing.

 

Hope this helps,

Daniel

 

 

 

 

Visitor xpress
Visitor
4,085 Views
Registered: ‎02-25-2011

Re: How do you get sensible probe names in Vivado Analyser for ILA?

I have found a workaround for one of the issues I had back in 2014.

 

The solution for selecting the input clock to the debug_hub is here:

 

https://www.xilinx.com/support/answers/64764.html

 

connect_debug_port dbg_hub/clk [get_nets <clock_net_name>]

 

 

0 Kudos