06-04-2015 07:35 AM
So, thanks to these forums and this answer record I managed to work out why my design wasn't able to be programmed in hardward manager earlier. My problem was that I was using a clock generated by an MMCM as the capture clock for an ILA I had instantiated in my HDL. And crucially this MMCM was depending on a reset that would deassert after configuration.
This is now causing a slight headache on what to do about the clock for the ILA core. I have had to make another free running version at the same frequency. The problem is that this is a different clock domain, technically, to the one that the ILA input signals are in. This then causes hold viiolations. I have fudged it for now by using clock domain crossing and ignores on the ila input signals.
Surely this can't be the intended way of doing things now in vivado (I'm pretty sure this limitation didn't exist in Planahead right?). Otherwise, how do I get a free running clock for the ILA if the clock domain of the signals I want to monitor with my ILA happens to be non-free running?
Am I misunderstanding?
06-04-2015 04:50 PM
I probably can't offer much, but I'd like to understand the problem more.
You have logic you're trying to debug that is running on a non-free running clock, let's call "clk1".
You connect the ILA core up to "clk1" (as you normally should - same clock as the logic you're debugging).
However, the ILA core doesn't like non-free running clocks, and you're having trouble? So you created "clk2" which is similar to clk1, but async, and thus have to deal with all the cross-clocking muck?
How is you're non-free running clock generated? I'm guessing not as simple as a free running clock with a CE? What frequency?
06-04-2015 05:19 PM - edited 06-05-2015 06:18 AM
To add a bit to the excellent post by @markcurry if you are creating clk1 with an MMCM that uses a reset and clk2 with an MMCM that does not use reset and the two MMCM's have the same source clock, the same feedback network and the same attributes, then you can safely set_false_path from clk1 to clk2: these are the same clocks for your purposes.
I always pull the ILA and dbg_hub into a separate (unused) part of the fabric, and I look for an area where I have a free MMCM and, of course, unused BUFH's and BUFR's. This keeps the ILA additions from causing timing issues with the main design.
06-05-2015 01:08 AM
Thanks for the good replies.
Well, you both have it correct really.
- I have a single input clock, free running, at 250MHz.
- The free running clock went to two MMCMs.
- MMCM 1 has no reset, MMCM2 now does (it didn't before, adding the reset broke it and stopped me debugging etc..)
- MMCM 1 outputs clk1 (and lot sof other clocks..). This is 250MHz.
- MMCM 2 outputs clk2.This is 156.25MHz.
- I have two ILAs. ILA1 uses clk1, ILA2 uses clk2.
So yes, I have had to add a third MMCM, essentially the same as MMCM2 but without the reset. And then like you say add a false path because I can assume the clocks are the same.
I can see this might/would probably work but it just seems like bad practise to me (using a different clock to the one the logic is created with). Plus I have to tie up an MMCM which I may need at some point. I don't like that I have to use it. These ILAs are in my design permanently because there is a whole set of signals I like to run checks on when I release new code revisions and it's just easier to instantiate them in HDL.
On a further note, even though the above is all necessary it seems, I was actually still having trouble getting my debug going. I'll see what today brings. None of the other suggestions with this ILA mismatch error were applicable so something is wrong I think.
01-03-2016 10:31 AM
this is a very serious issue for vivado and it should be solved by xilinx.
the important fact is that sometimes you will never have a free running clock in your entire system.
imagine a board which contains the zynq device, and the only clock generated by the oscillator has entered the PS.
how would you use ila in such a design? you have no free running clock!
01-03-2016 01:51 PM
it is already working fine in 2015.4.
You can directly connect ila to the clock coming from the PS, which is actually not a free running clock at all.
all you need to do is that at the time of debugging, first intialize the ps and then program the fpga (pl).
01-28-2016 11:13 AM
I have been battling this same issue for months on and off. My design has a MIG part that outputs a ui_clk at 100MHz, an Aurora block that outputs a usr_clk_out at 156.25MHz, and a Zynq PS with a 50MHz clock output. Each of these clocks run different parts of my system's logic, and I cannot get the Vivado 2015.2.1 tools to recognize the debug hub in Hardware Manager seemingly because it doesn't see a free-running clock.
Because I don't yet have firmware to run the PS, I generated a second output clock from the MIG at 50MHz and connected it to the logic that had been connected to the PS output clock. I have evidence (blinking LEDs) that this clock is running. I also have evidence that the 100MHz output clock is running. I don't yet have proof that the Aurora clock is running. But that is on the way.
In an older design, I was always able to get around the unfound debug hub by clicking Refresh Device after Vivado reported that it couldn't find the hub. Because presumably all of the clocks were then running, it was able to see the hub and bring up the ILA windows.
I tried using a Clocking Wizard to generate my own versions of these clocks, as others in this thread have. But the tool refused to build because it claimed that that location it selected for the MMCM device was not acceptably close to the clock input pins.
Anyone out there have an idea how to get this ILA working more reliably??
11-28-2018 08:59 AM
I was facing the exact problem when trying to debug using Vivado ILA. Below are my advise after trying every combinations for three days.
1. First the error statement provided by Xilinx tool is not clear and does not pin-point to the actual proble.
2. The free running clock can be provided using actual sysclk, or MMCM. (One of the documentation says PLL can also be used but I always faced free running clock error).
3. Used clocking wizard to implement - make sure there are no other control signals like reset, otherwise you will again face the same error.
4. Make sure your constraint file is also correct - pins are correct and the period exactly match the period you specify for input clock in clocking wizard.
Any mismatch and you will get same warning and will end up scratching your head.
Thanks and I hope it helps the community.