cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ptaddoni
Contributor
Contributor
9,988 Views
Registered: ‎03-07-2013

Vivado 2016.1 Virtex-7 ILA/Chipscope failing in many different ways

Jump to solution

Using Vivado 2016.1 with Virtex-7, ILAs created using “setup debug” in the synthesized design.

I get the following different errors, using Vivado 2016.1 Lab Tools hardware manager:
1)  WARNING: [Labtools 27-1973] Mismatch between the design programmed into the device ..... and the probes file
2)  ERROR: [Xicom 50-38] xicom: ERROR: [Common 17-70] Application Exception: Internal error: Invalid Trigger Condition size
3)  ERROR: [Xicom 50-38] xicom: CseXsdb_getParameter() - Unknown parameter name 'tc0_config'
4)  WARNING: [Xicom 50-38] xicom: No CseXsdb register file specified for CseXsdb slave type: 8, cse driver version: 17. Slave initialization skipped.
ERROR: [Xicom 50-38] xicom: Data structures not initialized for CseXsdb slave Device:0, user chain number/bus:1, slave index:1.
5)  I also get mysterious hardware malfunction in unrelated, well-tested and proven logic!!!

Note this design meets timing, and seems to have the correct frequency applied to each clock (viewed in TCL window: report_clock)

I must be missing something big. Can anybody help? I depend heavily on chipscope and it has always worked well for me. -Paul

0 Kudos
1 Solution

Accepted Solutions
ptaddoni
Contributor
Contributor
15,602 Views
Registered: ‎03-07-2013

I had a whole bunch of symptoms, I listed 5 things. It turns out there were two unrelated problems. 

 

The easy one first:

My #5 item mysterious failure of proven logic was a board-level timing problem due to Vivado not pushing flops to IOBs. The original ISE design depended on guaranteed pin-to-pin timing to interface to a CPLD.  However these datasheet numbers are not valid with Vivado unless one includes the following in the xdc file:     set_property IOB TRUE [get_ports USBDIO*]   

Unfortunately for me, the actual resulting malfunction never occurred, until the worst possible moment.

 

The hard one (items #1-4):

I experienced a spectacular array of error messages while using ILA. It turns out I was doing something much worse than having a non-free-running clock: I was generating clock multiplexing glitches within the FPGA.  I need to receive a clock from an LPDDR4 bus. Because this clock starts and stops, I use a "fast clock activity detector" which can sense clock presence within a couple of cycles, and switch in a Backup clock of similar frequency, using BUFGCTRL.  This would work fine except for the extremely capricious nature of the LPDDR4 "gated clock", which can turn off for just 1 cycle, or 2, or 3,4,5,6,7...basically all possible number of cycles. What would happen is, the LPDDR4 clock would go away, the BUFGCTRL would begin to switch, synchronous to the Backup clock, and using IGNORE, but LPDDR4 clock would eventually come back too soon, creating a glitch, when the phase difference between the two clocks is worst-case (they have PPM difference between so they walk through each other).  The glitch was never visible when driven out of the FPGA to a test point, but eventually its effect on logic was quite visible when internal signals were driven out to test points (remember I could not use ILA!).     

 

This is insolvable in Xilinx, as I would need my Backup clock to track the phase of the LPDDR4 clock, but no MMCM or PLL can deal with a clock that stops and starts.  My fix is a new architecture that does not depend on switching in a Backup clock.

View solution in original post

Tags (1)
0 Kudos
6 Replies
arpansur
Moderator
Moderator
9,979 Views
Registered: ‎07-01-2015

Hi @ptaddoni,

 

Can you please check the clocking structure?

I am assuming that ILA clock is free running. Please verify if the same clock is connected to dbg_hub.

 

If you are seeing an internal error if possible please give it a try in Vivado 2016.2

Thanks,
Arpan
----------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------
0 Kudos
ptaddoni
Contributor
Contributor
9,972 Views
Registered: ‎03-07-2013

Hello Arpan

 

I did verify that the ILA and the dbg_hub are both on the same clock.

This clock is free-running, BUT, this clock is a BUFGCTRL multiplexed clock and is switching between two asynchronous 400MHz sources.  I have observed this clock at a high-frequency test output, with a hi-freq scope, and it looks clean.

However that does leave a small chance there are glitches on the clock within the FPGA (I don't think that is happening).

 

-Paul

 

   

0 Kudos
ptaddoni
Contributor
Contributor
9,488 Views
Registered: ‎03-07-2013

I'm still investigating this, I just wanted to post that it does not look like a 2016.1 or 2016.2 tool problem, I get it with 2015.4. I am also seeing it on another V7 design.  Perhaps Vivado/V7/ILA is a lot less tolerant of clocking than ISE/V7/ILA was?

 

I have a variety of complicating factors at play here (including some extreme clocking functionality).  Will post the solution when I work it out.  BTW I have no issues with Vivado ILA in Ultrascale (but its a more normal clocking situation).  --Paul

0 Kudos
ptaddoni
Contributor
Contributor
15,603 Views
Registered: ‎03-07-2013

I had a whole bunch of symptoms, I listed 5 things. It turns out there were two unrelated problems. 

 

The easy one first:

My #5 item mysterious failure of proven logic was a board-level timing problem due to Vivado not pushing flops to IOBs. The original ISE design depended on guaranteed pin-to-pin timing to interface to a CPLD.  However these datasheet numbers are not valid with Vivado unless one includes the following in the xdc file:     set_property IOB TRUE [get_ports USBDIO*]   

Unfortunately for me, the actual resulting malfunction never occurred, until the worst possible moment.

 

The hard one (items #1-4):

I experienced a spectacular array of error messages while using ILA. It turns out I was doing something much worse than having a non-free-running clock: I was generating clock multiplexing glitches within the FPGA.  I need to receive a clock from an LPDDR4 bus. Because this clock starts and stops, I use a "fast clock activity detector" which can sense clock presence within a couple of cycles, and switch in a Backup clock of similar frequency, using BUFGCTRL.  This would work fine except for the extremely capricious nature of the LPDDR4 "gated clock", which can turn off for just 1 cycle, or 2, or 3,4,5,6,7...basically all possible number of cycles. What would happen is, the LPDDR4 clock would go away, the BUFGCTRL would begin to switch, synchronous to the Backup clock, and using IGNORE, but LPDDR4 clock would eventually come back too soon, creating a glitch, when the phase difference between the two clocks is worst-case (they have PPM difference between so they walk through each other).  The glitch was never visible when driven out of the FPGA to a test point, but eventually its effect on logic was quite visible when internal signals were driven out to test points (remember I could not use ILA!).     

 

This is insolvable in Xilinx, as I would need my Backup clock to track the phase of the LPDDR4 clock, but no MMCM or PLL can deal with a clock that stops and starts.  My fix is a new architecture that does not depend on switching in a Backup clock.

View solution in original post

Tags (1)
0 Kudos
8,678 Views
Registered: ‎05-13-2016

I am having a similar problem in 2015.4 on a simpler design with two ILA cores each with a free-running clock,  I am getting the invalid trigger size error.  I have changed the trigger source and window sizes and what not, to no avail!

0 Kudos
ptaddoni
Contributor
Contributor
8,531 Views
Registered: ‎03-07-2013

Paul, I learned a couple of things in my investigation you can look into:

1) Look for the debug_hub in your synthesized design schematic view and see what clock net is driving it, perhaps you can switch to the other clock your ILAs are running on. There is an XDC command to do this.

2) The debug_hub clock must be faster than the JTAG clock. The JTAG clock default frequency is very slow, 1 or 5 MHz.

Hope this helps.  -Paul