03-17-2014 04:15 PM
I have an usb-ic connected to a spartan 6
The usb-ic generates a clock of 60MHz which I want to use as a clock signal in the fpga.
But I did not connect this signal to a clock dedicated pin, but to a normal input pin.
I use this signal directly in a process with this input in the sensitivity list and on the rising edge.
This however gives many data errors. I suspect this is due to jitter of the clock signal.
Can I use a PLL to make a well-defined clock signal out of this input?
Or should I use another method to avoid these problems?
03-17-2014 04:49 PM
> This however gives many data errors. I suspect this is due to jitter of the clock signal.
The problem is that the timing relationship is no longer guaranteed due to part of the clock path using standard interconnect and this route may vary from run to run.
> Can I use a PLL to make a well-defined clock signal out of this input?
Using a PLL or MMCM may help with phase shifting the clock to compensate for some of the timing.
> Or should I use another method to avoid these problems?
A board spin should be done to fix this, but you should start with verifying that you have your IO timing setup/hold correctly defined in your timing constraints.
03-17-2014 05:34 PM
I would guess that you are most likely seeing hold errors due to the long clock routing delay. It's possible that this could be fixed as easily as inverting the input clock (using the opposite edge), but I only suggest this because 60 MHz is pretty slow. Whether you can use this method also depends on the size of the data valid window. At higher data rates, or for smaller data valid windows you might need to use dynamic clock phase adjustment to compensate for the large min to max timing of the non-dedicated clock routes.
In any case I doubt that jitter is the primary cause of the problem. I wouldn't expect the non-dedicated route to add very much to the jitter. I does add to the uncertainty (min to max delay over process, temperature and voltage) with respect to using dedicated clock routes. That's why it's not recommended when you need to have a known phase relationship to external signals.
03-17-2014 06:55 PM
03-17-2014 09:40 PM
Ideally, it is only recommended to drive the clock signal through the clock capable IO's. If you are driving the clock signal through the normal IO's there can be jitter problems as this pins is not for clock driving.
However also check the timing constraints PERIOD and OFFSET IN/OUT constraints have been correctly set. You can find the information on these constraints from the UG612 - http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/ug612.pdf