cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
3,381 Views
Registered: ‎01-22-2015

input-clock slower than specified

Jump to solution

I was recently told by a customer that he sometimes uses a slower-than-specified input-clock for one of my FPGA boards. He says that the board still works!?  -but things are just slowed down a bit.

 

The board uses a Virtex-5 FPGA and the associated ISE project uses a Digital Clock Manager (DCM) to convert the input-clock to other slower clocks.  Of course, I could reconfigure the DCM so that it is aware of the slower input-clock and then rerun (synthesis, implementation, timing analysis), and reprogram the FPGA. -but, I was wondering…..

 

Could using a slower-than-specified input-clock cause problems with DCM-operation or timing analysis or ….?

0 Kudos
Reply
1 Solution

Accepted Solutions
Guide
Guide
5,985 Views
Registered: ‎01-23-2009

In general, this won't cause a problem - particularly with the DCM.

 

The CLK0 output of the DCM is always the same frequency as the CLKIN, all the other clocks (CLK90, CLK180, CLK270, CLK2X, CLK2X180, CLKDIV and CLKFX) will all maintain their programmed relationships as long as you stay inside the legal ranges of the input and output clocks. The minimum clock frequencies for the DCM are pretty low, so this generally isn't a problem.

 

With PLLs and MMCMs you need to be a bit more careful, since the clock wizard has chosen the VCO frequency based on your inputs, and it is possible that a change of frequency could move the VCO (or PFD) frequency outside the legal range. But, even here, as long as that doesn't happen, they should work properly.

 

Also, in general, if timing is met at a given frequency, you should not have a problem at lower frequencies; hold checks within the same domain are not affected, and setup checks will always be better.

 

There could be some problems with clock domain crossing (CDC) circuits. Sometimes certain CDCs have strict requirements (like the destination clock is at least 2 times the speed of the source clock), so messing with the clock frequencies can break these relationships - but, again, you need to be right on the edge for "small" changes to make a difference.

 

Avrum

View solution in original post

Tags (1)
3 Replies
Guide
Guide
5,986 Views
Registered: ‎01-23-2009

In general, this won't cause a problem - particularly with the DCM.

 

The CLK0 output of the DCM is always the same frequency as the CLKIN, all the other clocks (CLK90, CLK180, CLK270, CLK2X, CLK2X180, CLKDIV and CLKFX) will all maintain their programmed relationships as long as you stay inside the legal ranges of the input and output clocks. The minimum clock frequencies for the DCM are pretty low, so this generally isn't a problem.

 

With PLLs and MMCMs you need to be a bit more careful, since the clock wizard has chosen the VCO frequency based on your inputs, and it is possible that a change of frequency could move the VCO (or PFD) frequency outside the legal range. But, even here, as long as that doesn't happen, they should work properly.

 

Also, in general, if timing is met at a given frequency, you should not have a problem at lower frequencies; hold checks within the same domain are not affected, and setup checks will always be better.

 

There could be some problems with clock domain crossing (CDC) circuits. Sometimes certain CDCs have strict requirements (like the destination clock is at least 2 times the speed of the source clock), so messing with the clock frequencies can break these relationships - but, again, you need to be right on the edge for "small" changes to make a difference.

 

Avrum

View solution in original post

Tags (1)
Guide
Guide
3,339 Views
Registered: ‎01-23-2009

By the way, this is one more of the real advantages of Vivado over ISE (and since this is a V5, you have to use ISE).

 

The question you are asking is "will this bitstream work at this frequency". In ISE, it is basically impossible to answer that question. In ISE, the constraints are read in during ngdbuild (which is very early in the process), but you cannot get meaningful timing results until after map (really after par). So, you can build a new implementation with the new constraints and see if that new implementation will run at that speed, but it really doesn't tell you anything (or much) about the old implementation.

 

In Vivado, though, you can directly answer this question. In Vivado you can open the post-route implemented design (or open the design checkpoint) and then change the constraints - you can either just change one constraint, or you can reset all the constraints (reset_timing) and add a whole new set of constraints. At that point, you can check the timing - this will be the checking of the timing of the old design against the new constraints. If it passes, you can go ahead and continue to use the existing bitstream at the new timing conditions.

 

Avrum

3,333 Views
Registered: ‎01-22-2015

Avrum,

 

Many thanks for the afterthoughts.  -one more reason for me to love Vivado.  To Live!

 

Mark

0 Kudos
Reply