cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kyzyl
Visitor
Visitor
22,817 Views
Registered: ‎12-05-2014

ILA core not recognized by hardware manager

Jump to solution

Hello. I'm having a very frustrating problem. Very recently I was able to debug my design using the ILA cores just like usual. Recently I opened up my project and the hardware manager won't let me debug any more. I'm using Vivado 2014.4, and I haven't upgraded anything (to my knowledge) since it was working. 

 

The ILA cores are very clearly visible and connected at synthesis and implementation, but when I generate the bitfile and open a hardware session, I am told "There are no debug cores" so I can't use the logic analyzer. The hardware target properties list the correct .itx file, and that file clearly contains the xml describing my probes. 

 

If I run the command 'report_debug_cores' I get the following output:

report_debug_core
Copyright 1986-2014 Xilinx, Inc. All Rights Reserved.
------------------------------------------------------------------------------------
| Tool Version : Vivado v.2014.4 (lin64) Build 1071353 Tue Nov 18 16:47:07 MST 2014
| Date         : Wed Dec 10 13:12:51 2014
| Host         : <name> running 64-bit Linux Mint 17 Qiana
| Design       : top_wrapper
| Device       : xc7z020clg484-1
| Speed File   : -1
------------------------------------------------------------------------------------

Debug Core Information

Table of Contents
-----------------
1. Debug Cores
1.1 dbg_hub: (labtools_xsdbm_v1, implemented, inserted)
1.2 u_ila_0: (labtools_ila_v5, implemented, inserted)

1. Debug Cores
--------------

1.1 dbg_hub: (labtools_xsdbm_v1, implemented, inserted)
-------------------------------------------------------

Channel Data for Debug Core "dbg_hub"
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+
| Port Name     | Port    | Port Spec     | Channel Name     | Net Name                               | Net Type | MARK_DEBUG |
|               | Type    |               |                  |                                        |          |            |
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+
| clk           | input   | clk           | clk[0]           | u_ila_0_FCLK_CLK0                      | signal   | false      |
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+


1.2 u_ila_0: (labtools_ila_v5, implemented, inserted)
-----------------------------------------------------

Channel Data for Debug Core "u_ila_0"
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+
| Port Name     | Port    | Port Spec     | Channel Name     | Net Name                               | Net Type | MARK_DEBUG |
|               | Type    |               |                  |                                        |          |            |
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+
| clk           | input   | clk           | clk[0]           | u_ila_0_FCLK_CLK0                      | signal   | false      |
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+
| probe0        | input   | probe         | probe0[0]        | dds_compiler_0_m_axis_data_tdata[0]    | signal   | true       |
|               |         |               | probe0[1]        | dds_compiler_0_m_axis_data_tdata[1]    | signal   | true       |
|               |         |               | probe0[2]        | dds_compiler_0_m_axis_data_tdata[2]    | signal   | true       |
|               |         |               | probe0[3]        | dds_compiler_0_m_axis_data_tdata[3]    | signal   | true       |
|               |         |               | probe0[4]        | dds_compiler_0_m_axis_data_tdata[4]    | signal   | true       |
|               |         |               | probe0[5]        | dds_compiler_0_m_axis_data_tdata[5]    | signal   | true       |
|               |         |               | probe0[6]        | dds_compiler_0_m_axis_data_tdata[6]    | signal   | true       |
|               |         |               | probe0[7]        | dds_compiler_0_m_axis_data_tdata[7]    | signal   | true       |
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+
| probe1        | input   | probe         | probe1[0]        | LINE_TRIGGER_OBUF[0]                   | signal   | true       |
|               |         |               | probe1[1]        | LINE_TRIGGER_OBUF[1]                   | signal   | true       |
|               |         |               | probe1[2]        | LINE_TRIGGER_OBUF[2]                   | signal   | true       |
|               |         |               | probe1[3]        | LINE_TRIGGER_OBUF[3]                   | signal   | true       |
|               |         |               | probe1[4]        | LINE_TRIGGER_OBUF[4]                   | signal   | true       |
|               |         |               | probe1[5]        | LINE_TRIGGER_OBUF[5]                   | signal   | true       |
|               |         |               | probe1[6]        | LINE_TRIGGER_OBUF[6]                   | signal   | true       |
|               |         |               | probe1[7]        | LINE_TRIGGER_OBUF[7]                   | signal   | true       |
+---------------+---------+---------------+------------------+----------------------------------------+----------+------------+

 

Am I missing something? This is a real show stopper so I would appreciate any help. I've already spent far too long stuck on this, and I have no path forward right now.

0 Kudos
1 Solution

Accepted Solutions
achutha
Xilinx Employee
Xilinx Employee
37,634 Views
Registered: ‎07-01-2010

Hi,

 

I see from the description you are using Zynq.I think you are seeing this issue as clock source is missing as the Zynq is not initialized.

 

Is the zynq processor configure/initialized before launching the hardware manager?

 

Please refer to lab2 in ug940 for details – note you need not have an application , you can use the ps7_init.tcl to configure.

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_4/ug940-vivado-tutorial-embedded-design.pdf

 

If you don’t have the application, do following. -- Make sure you export the hardware before doing this.

1. Launch Vivado tcl

2. Have the copy of .bit, ps7_init.tcl into a common folder

3. cd to the location in which you the .bit and ps7_init.tcl once the vivado tcl console/shell is launched

4. Type XMD  (make sure the board is connected)

5. Type fpga -f  system.bit

6.Type connect arm hw

7.Type source ps7_init.tcl

8.Type ps7_init

9.Type ps7_post_config

10. launch the hardware manager using vivado GUI – follow this in Lab2

 

Let us know if the issue is seen even after following the details.

 

Regards,

Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------

View solution in original post

7 Replies
gszakacs
Professor
Professor
22,813 Views
Registered: ‎08-14-2007

When this happens to me, it usually means that the .bit file actually loaded into the part isn't the one I just built.  It often happens if there is a configuration flash on the board with a non-debug copy of the design.  Did you try to reload the bit file?

-- Gabor
0 Kudos
kyzyl
Visitor
Visitor
22,805 Views
Registered: ‎12-05-2014

Yes I've reloaded the bitfile many times and in many different ways. If I regenerate the bitfile and check the timestamps, it seems to be targetting the correct one (i.e. the one I'm loading) and that one is paired up with the ITX file containing my probes. Still I get Implemented Design warnings: 

 

[Labtools 27-3123] The debug hub core was not detected at User Scan Chain 1 or 3.

[Labtools 27-1974] Mismatch between the design programmed into the device xc7z020_1 and the probes file <path>/debug_nets.ltx.
The device design has 0 ILA core(s) and 0 VIO core(s). The probes file has 1 ILA core(s) and 0 VIO core(s).

 

0 Kudos
vemulad
Xilinx Employee
Xilinx Employee
22,774 Views
Registered: ‎09-20-2012
Hi,

Is the timing met for your design?

Can you make sure that the jtag cable freq is less than the ila clock frequency?

Thanks,
Deepika.
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
achutha
Xilinx Employee
Xilinx Employee
37,635 Views
Registered: ‎07-01-2010

Hi,

 

I see from the description you are using Zynq.I think you are seeing this issue as clock source is missing as the Zynq is not initialized.

 

Is the zynq processor configure/initialized before launching the hardware manager?

 

Please refer to lab2 in ug940 for details – note you need not have an application , you can use the ps7_init.tcl to configure.

http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_4/ug940-vivado-tutorial-embedded-design.pdf

 

If you don’t have the application, do following. -- Make sure you export the hardware before doing this.

1. Launch Vivado tcl

2. Have the copy of .bit, ps7_init.tcl into a common folder

3. cd to the location in which you the .bit and ps7_init.tcl once the vivado tcl console/shell is launched

4. Type XMD  (make sure the board is connected)

5. Type fpga -f  system.bit

6.Type connect arm hw

7.Type source ps7_init.tcl

8.Type ps7_init

9.Type ps7_post_config

10. launch the hardware manager using vivado GUI – follow this in Lab2

 

Let us know if the issue is seen even after following the details.

 

Regards,

Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------

View solution in original post

kyzyl
Visitor
Visitor
22,723 Views
Registered: ‎12-05-2014

Thank you all for your responses. It seems Achutha was on to my problem. Last night I noticed that my debug cores were working when I was working on the firmware side of the design in the SDK, i.e. once the PS was initialized. Previously I had my ILAs configured with an external clock, but it seems at some point I re-ran the 'Setup Debug' wizard, which picked up the 100MHz PS-PL clock by default.

 

As a side note to the Vivado developers: The error messages are not at all informative as to the true problem, and the debug wizard just says "found 1 clock", so it's not alway clear which clock that is. Yes, you can look at the connections in the implemented design, but it's easy to miss. Perhaps a warning about trying to start a debug session while the PS is uninitialized would be prudent. Searching these forums, I'm clearly not the only person who has run into isuses related to this situation.

 

For posterity:

 

If you end up with the LabTools warnings/errors I listed above, and/or the 'There are no debug cores' message in the hardware manager of Vivado, while you can see that the ILA cores are present in your implementation, try troubleshooting with the following options:

 

1. If you're not intending to use the PS's clocks, check that your clock is present and is properly connected.

2. If you are intending to use a PS clock, and you have a software application to run on the PS, open the SDK, program the device and download the ELF (hit 'Run') to initialize everything. At that point you should be able to move back to Vivado and open a debug session from the hardware manager like usual.

3. If you are intending to use a PS clock but don't have a software application to use (i.e. you're doing something purely in the PL or using only built in hard functionality of the PS), then follow Achutha's instructions (see above). 

achutha
Xilinx Employee
Xilinx Employee
22,687 Views
Registered: ‎07-01-2010
On the messaging , there is already a change request in place and you can check the changes in the next vivado release.

Regards,
Achutha
---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
engll
Observer
Observer
18,941 Views
Registered: ‎03-05-2015

Thanks kyzyl and achutha for the very helpful info which enabled me to get ILA recognized by the hardware manager in 2015.2.

Just a couple of my notes:
1) In achutha's step #1, launch the Vivado tcl shell at the vivado project directory with command "vivado -mode tcl".
2) In achutha's step #4, use "xmd" (lower case) to get to xmd from Vivado tcl shell.
3) After achutha's step #9, first "exit" gets out of xmd, and second "exit" gets out of Vivado tcl shell.
4) In achtha's step #10, do not reprogram the device.  Just refresh the device.
5) On the messaging issue, it is not in 2015.2 yet.

0 Kudos