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 jcadena
Visitor
5,591 Views
Registered: ‎08-11-2016

Probing a clock using ILA core

Jump to solution

I am a total beginner with the ILA core. 

I am trying to debug a simple design with the ILA core, and I thought it would be a good idea to debug the clock running my hardware as well. Timing failed and I could never fix it until I took out the clock probe.

I looked online but I could not find why this is the case

The ila clock is the same as the clock I was trying to debug (100 MHz), and I tried setting the debug hub clock to both 300MHz and 100 MHz with no success.  

 

Why is this?

What is a good way to debug the clock with the ILA core? I do not need to debug it now, but maybe in a future design I would like to see whether or not the clock is running.

 

Thanks for the help

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
9,621 Views
Registered: ‎01-23-2009

Re: Probing a clock using ILA core

Jump to solution

The ILA is a "Logic Analyzer" - the whole idea is to capture samples of synchronous signals using the same clock as the synchronous system. This way you get one sample per "state" of your synchronous system. For example, if you have a state machine, the ILA will show you the state of the state machine on each subsequent clock.

 

Sampling a clock with a logic analyzer has several problems.

 

First, if you sample the clock with an ILA running on that clock, you will always get a constant - the ILA will sample the clock once per clock period - but the clock makes two transitions per clock period (so you miss one, resulting in a constant).

 

The second is more of an FPGA issue. In an FPGA, the clock signals are always kept separate from the data signals. Within the FPGA there are dedicated clock distribution networks that are designed to bring a clock to the clock pin of all clocked elements (like flip-flops and RAMs and DSP cells...). The signals being sampled by the ILA are data signals - they go to LUTs and ultimately end up on the D inputs of flip-flops (not the clock pins of flip-flops). Any time you move a signal from the clock network to the data path you get strange routing results.

 

Furthermore, doing this messes up static timing. Static timing assumes a synchronous design; a path from the CLK input of a flip-flop to the data inputs of another flip-flop is a static timing path. The input of the flip-flop in the ILA that is sampling the clock is not a normal path (since it doesn't start at the CLK input of a clocked cell like a flip-flop/RAM/DSP...). Almost by definition, this "path" is going to fail timing.

 

So, in general, we don't sample clocks with ILAs. If you try and clock an ILA with a clock that isn't running, then the ILA will not run - the interface in Vivado will recognize that the ILA is not responding (and give you a message like "Slow or missing clock"). Assuming this doesn't happen, then you can assume your clock is running and you are getting one sample of your other signals per clock period.

 

If you really need to sample a clock, you must run your ILA on a different and significantly faster clock. To sample a 100MHz clock you should use something faster than 200MHz, and with this, what you will observe will not look nice. This will still create the latter two problems (routing from the clock network to the data network and getting timing violations), but these can be worked around. In general, though, you rarely need to sample a clock with an ILA...

 

Avrum

2 Replies
Historian
Historian
9,622 Views
Registered: ‎01-23-2009

Re: Probing a clock using ILA core

Jump to solution

The ILA is a "Logic Analyzer" - the whole idea is to capture samples of synchronous signals using the same clock as the synchronous system. This way you get one sample per "state" of your synchronous system. For example, if you have a state machine, the ILA will show you the state of the state machine on each subsequent clock.

 

Sampling a clock with a logic analyzer has several problems.

 

First, if you sample the clock with an ILA running on that clock, you will always get a constant - the ILA will sample the clock once per clock period - but the clock makes two transitions per clock period (so you miss one, resulting in a constant).

 

The second is more of an FPGA issue. In an FPGA, the clock signals are always kept separate from the data signals. Within the FPGA there are dedicated clock distribution networks that are designed to bring a clock to the clock pin of all clocked elements (like flip-flops and RAMs and DSP cells...). The signals being sampled by the ILA are data signals - they go to LUTs and ultimately end up on the D inputs of flip-flops (not the clock pins of flip-flops). Any time you move a signal from the clock network to the data path you get strange routing results.

 

Furthermore, doing this messes up static timing. Static timing assumes a synchronous design; a path from the CLK input of a flip-flop to the data inputs of another flip-flop is a static timing path. The input of the flip-flop in the ILA that is sampling the clock is not a normal path (since it doesn't start at the CLK input of a clocked cell like a flip-flop/RAM/DSP...). Almost by definition, this "path" is going to fail timing.

 

So, in general, we don't sample clocks with ILAs. If you try and clock an ILA with a clock that isn't running, then the ILA will not run - the interface in Vivado will recognize that the ILA is not responding (and give you a message like "Slow or missing clock"). Assuming this doesn't happen, then you can assume your clock is running and you are getting one sample of your other signals per clock period.

 

If you really need to sample a clock, you must run your ILA on a different and significantly faster clock. To sample a 100MHz clock you should use something faster than 200MHz, and with this, what you will observe will not look nice. This will still create the latter two problems (routing from the clock network to the data network and getting timing violations), but these can be worked around. In general, though, you rarely need to sample a clock with an ILA...

 

Avrum

Teacher muzaffer
Teacher
5,510 Views
Registered: ‎03-31-2012

Re: Probing a clock using ILA core

Jump to solution

@jcadena as always @avrumw has good advice. One thing I can suggest for sampling a clock properly without upsetting the timing analyzer is to use an output of a clock divider and detect transitions on the other side ie just implement a toggle flop which changes state at every clock edge and observe the output of this flop with your ILA. This will allow the STA to time the path properly. Of course this won't let you see the negedge of the source clock but I am not sure if that's your goal. It seems you only want to see if your clock is toggling at some rate.

Of course the sampling clock running at > 2x the source clock applies to make sense of the frequency you're observing.

- 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