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!
07-11-2014 04:23 PM
Hello,
Is there a way to make ILA work with an oversampled clock in Vivado?
Specifically, let's say I clock a V7 with a 100MHz external clock; inside the FPGA I have an MMCM that generates out of the 100MHz two clocks: 25MHz and 300MHz. Let's say I use the 25MHz in a gated mode to clock a simple N-bit counter (up-counting) and I would like to use the 300MHz to clock an ILA to observe both the outputs of the counter and the gated 25MHz clock (this way I stand a better chance to capture e.g., eventual unwanted pulses on the 25MHz gated clock, i.e., narrower than the 40 ns period of that clock; of course, the capture would still be limited to pulses at least 3.333ns wide). Normally I would select (in the Debug Wizard) the clock domain of the ILA observing the counter outputs to be 25MHz, since the counter is clocked at that frequency, and I would not be able to observe the 25MHz clock itself. Is there a way to select the ILA clock domain to be 300MHz and this way observe both the counter outputs and the 25MHz clock, therefore in an oversampling mode?
Cheers!
07-14-2014 11:25 AM - edited 07-14-2014 11:26 AM
Unless something fundamentally changed with ChipScope for Vivado, there should be nothing preventing you from selecting a different clock than the one that sourced the signals you are analyzing. However you will then have a lot of paths crossing between the 25 MHz and 300 MHz domains that will be checked for setup and hold because the two clocks are related. So you could have some trouble meeting timing. The only other issue is routing the 25 MHz clock as a non-clock input to the ILA. Typically this type of path is not supported in newer FPGA families, i.e. buffered clock nets should only drive clock loads. You could work around this in a couple of ways. One is to find an unused IO pin, drive a DDR output flop to forward the clock to that pin, and monitor the feedback from the pin's IBUF. Alternately you could build a simple piece of logic using two flip flops and an XOR gate like (Verilog):
always @ (posedge clk_25M) q_rise <= !q_fall;
always @ (negedge clk_25M) q_fall <= q_rise;
assign reconstituted_clock = qfall ^ q_rise;
While the second method doesn't require an IOB and pin, it has the issue of possibly unconstrained timing on the output gate as well as a requirement to place a KEEP attribute on the reconstituted clock net.
07-14-2014 11:25 AM - edited 07-14-2014 11:26 AM
Unless something fundamentally changed with ChipScope for Vivado, there should be nothing preventing you from selecting a different clock than the one that sourced the signals you are analyzing. However you will then have a lot of paths crossing between the 25 MHz and 300 MHz domains that will be checked for setup and hold because the two clocks are related. So you could have some trouble meeting timing. The only other issue is routing the 25 MHz clock as a non-clock input to the ILA. Typically this type of path is not supported in newer FPGA families, i.e. buffered clock nets should only drive clock loads. You could work around this in a couple of ways. One is to find an unused IO pin, drive a DDR output flop to forward the clock to that pin, and monitor the feedback from the pin's IBUF. Alternately you could build a simple piece of logic using two flip flops and an XOR gate like (Verilog):
always @ (posedge clk_25M) q_rise <= !q_fall;
always @ (negedge clk_25M) q_fall <= q_rise;
assign reconstituted_clock = qfall ^ q_rise;
While the second method doesn't require an IOB and pin, it has the issue of possibly unconstrained timing on the output gate as well as a requirement to place a KEEP attribute on the reconstituted clock net.
07-14-2014 03:04 PM
Hi Gabor,
Indeed, that was my issue: couldn't meet timing (was complaining about SU &/or H violations).
So, if my understanding is correct, the idea to make it work is to make the 25MHz clock appear as a regular signal to the ILA, isn't it?
A potential problem may be with the fact that the monitored 25MHz signal is not the 25MHz clock, and so eventual glitches on the original 25MHz clock may not appear on the reconstituted signal (be it throug and ODDR + IBUF or through 2 FFs + XOR=LUT), and that would defeat the purpose of the exercise all together.
Worth trying, though.
I was wondering whether there's any way of modifying the phase of the 300 MHz clock (vs. the 25MHz one) so as to satisfy the SU & H requirements; knowledge of the ILA architecture would help do that...
Many thanks.
Paul
07-15-2014 07:46 AM
Any glitch on the original clock that is wide enough to trigger the ODDR flop or in the case of the internal approach, wide enough to trigger a fabric flop should make it through to the sampled signal. On the other hand, any glitch less than 3.3ns is not guaranteed to be seen when you sample at 300 MHz.
On the other hand, maybe there's a better way to debug your design. You say the 25 MHz clock is gated. Is there also an ungated 25 MHz clock available? If you could use that and sample the signal that gates the clock you could see if the logic gets messed up when the clock gate switches. That would indirectly show that there are clocking issues even if you don't actually capture the glitch. By the way, how do you gate the clock? Are you using a BUFGCE or some other approach?
07-15-2014 06:21 PM
Yes, the 25MHz ungated clock is also available, and that doesn't have any glitches. The gating originally is done through that classical circuit that involves a latch (please see the attached pic), and that gets converted by Synplify Premier into BUFGCE, so I may have to look at the CE pins in order to monitor what's happening there.
Paul
07-15-2014 09:49 PM
Moving to Design-Tools and Others board.