07-29-2020 01:30 PM
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.
07-29-2020 02:05 PM
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.
07-29-2020 04:15 PM
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?
07-29-2020 05:03 PM
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.