cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
184 Views
Registered: ‎04-23-2019

Using a different clock frequency than specified in the xdc file

Hello,

I was wondering what problems, if any, would arise from using a slower clock speed than specified in the xdc file?

Say I have a reference clock of 300MHz from an external source and I specify this in the xdc with the creat_clock statement. Now lets say after the FPGA is programmed I rewrite some registers in my external clock source and now my reference clock is 200MHz.

Thank you,

Jake

0 Kudos
3 Replies
Highlighted
Moderator
Moderator
162 Views
Registered: ‎02-09-2017

Hi @jakerson1004,

 

The main issue I see is the possibility that you design might be faulty due to timing issues.

Vivado Place & Route the logic based on the timing constraints for the clock(s). If you change the clock frequency, those timings may not hold anymore. Since you are lowering the clock frequency, it's likely that if the design worked well with 300MHz, it'll probably also work at 200MHz, but that's something you should test and confirm.

In addition, if anywhere in your design you are using an MMCM or PLL, those primitives are configured based on the input clock frequency. So if they were configured to work with 300MHz, they will certainly NOT work with 200MHz, and they will never achieve the LOCKED state. You would need to also do a DRP change on the settings for the MMCM/PLL to configure them to work with the new clock.

Thanks,

Andre Guerrero

Product Applications Engineer

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
140 Views
Registered: ‎04-23-2019

Andre,

Thank you for the quick response.

To remedy your first point, I will definitely make multiple builds to test that the desired frequencies don't run into timing errors, as well as test this switching in hardware.

Regarding the second point, I am using this clock to drive the GTH PLLs on the FPGA (I am working on a KCU105 dev board and the JESD204 PHY v4.0 IP core, if you're curious). Although, I do want the line rate of these GTHs to scale with the input frequency. Ex: if I have a line rate of 12Gbps with my 300MHz clock, I want to have a line rate of 8Gbps with the new 200MHz clock (12 * 200/300 = 8). This would mean the N, M, and D dividers in my PLL would all be the same in both cases. There wouldn't be a problem if that was my design, correct?

Jake

0 Kudos
Highlighted
126 Views
Registered: ‎01-22-2015

@jakerson1004 

Although I agree with Andre that “you should not do this”, I think the MMCM/PLL is a little more flexible than Andre has described. 

We delivered a FPGA board to a customer with a design that used the MMCM.  The customer fed a base clock to the FPGA slower than we specified and ran the board for quite a while.  When we asked him about the slower base clock, he said that “things worked fine, just a little slower than expected”.

I understand that the MMCM creates an output clock from an input clock as described on about pages 72-77 of UG472(v1.14).  This procedure involves parameters, M=CLKFBOUT_MULT_F,  D=DIVCLK_DIVIDE, O=CLKOUT_DIVIDE and the frequency, fVCO, of a VCO found inside the MMCM.  All the parameters are fixed, except fVCO which automatically changes to provide a fixed divide/multiply relationship between MMCM input and output clock.  So, if the VCO does not go outside its specified range of frequencies (see datasheet for your device) then the MMCM should work properly.

You can investigate this flexibility of the MMCM using the Clocking Wizard.  Start as usual, specifying desired input and output frequencies.  Then go to the “MMCM Settings” tab and check “Allow Override Mode”, which fixes the operating parameters of the MMCM.  Then, start changing the input clock frequencies until red things start appearing and you get an “invalid VCO freq” warning. 

Cheers,
Mark

0 Kudos