cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
scott.powell
Observer
Observer
562 Views
Registered: ‎08-31-2016

Clock a design slower than it passed timing for? (Hypothetical)

Jump to solution

Let’s say I have an FPGA design with a few clock domains that are all derived from a single external clock source – say 100 MHz.  I properly define all clocks and false paths, etc., so that I get trustworthy results from Static Timing Analysis, and I pass with setup and hold slack on all nets. Now let’s say that I use that same build to program the identical FPGA on the identical board, but I’ve swapped out the 100 MHz external source with a 90 MHz source…

Place & route satisfied all timing requirements with the faster clock, but does that mean that I’m 100% safe to run at the slower speed? Of course, I could re-run place & route having changed the definition of the source clock period, and the design should pass no problem at the slower speed, but let’s say I didn’t do that. Same bitstream that routed and passed for 100 MHz, but I’m going to intentionally under-clock it. Perfectly safe??? And if not (and I think many will say not), why?

0 Kudos
1 Solution

Accepted Solutions
barriet
Xilinx Employee
Xilinx Employee
546 Views
Registered: ‎08-13-2007

BTW, I've seen a design that ran at 2 different clock oscillator inputs depending on the board configuration/population... The RTL was the exact same -  except the DCM/DLL (this was a long time ago, pre PLL/MCMM) configuration to account for the input frequency and the associated clock block attributes.

View solution in original post

4 Replies
barriet
Xilinx Employee
Xilinx Employee
553 Views
Registered: ‎08-13-2007

The first question would be how to you generate these "few clock domains that all all derived from a single source"?

If they are all integer sub-multiples using something like a BUFGCTRL/BUFGCE, e.g. /4, /5, etc. - that is one likely ok (but unlikely in practice) approach.

HOWEVER, if as usual, you used an MMCM or PLL to generate these internal clock domains, note that both primitives have a FVCOmin and FVCOmax spec - depending on the multiply and divide #s you used, I can imagine a scenario where you suddenly find yourself out of spec here with a different clock input. It could likely still work, but wouldn't be guaranteed, especially across PVT.

There might be other scenarios but that's the first one that comes to mind here.

barriet
Xilinx Employee
Xilinx Employee
547 Views
Registered: ‎08-13-2007

BTW, I've seen a design that ran at 2 different clock oscillator inputs depending on the board configuration/population... The RTL was the exact same -  except the DCM/DLL (this was a long time ago, pre PLL/MCMM) configuration to account for the input frequency and the associated clock block attributes.

View solution in original post

barriet
Xilinx Employee
Xilinx Employee
534 Views
Registered: ‎08-13-2007

You also have to carefully consider impacts to other interfaces that the FPGA is handling...

-if you have an embedded processor (say MicroBlaze or PicoBlaze/kcpsm6) and a UART interface - you are now -10% on the baud rate... Most serial chips can likely handle +/-5%, but perhaps not 10% of on the remote end.

-it is pretty common for FPGAs to be driving external memory... I saw a design where the FPGA was intentionally underclocked and to keep things simple (same clock domain), they also ended up underclocking the DDR2 interface on one configuration... Which worked fine for a few years until the new rev of the memory came in (with an associated die shrink), they apparently didn't like running under spec and the memory interface now broke and had to rehandled on its own clock domain back into a valid operating range, adding async FIFOs on the boundary, etc.

So there are certainly come potential complications... In general, Fmax is Fmax and you can likely run from at Fmax downto DC/0Hz... But in practice, there's several considerations that can quickly come into play.

I'm sure there's a few others I'm overlooking initially.

scott.powell
Observer
Observer
534 Views
Registered: ‎08-31-2016

Greetings, and thank you for the reply. That makes sense, regarding MMCM/PLL particulars. 

Even in the case where the 'other domains' are integer sub-multiples done in a BUFGCTRL/BUFGCE, I'm having a hard time convincing myself that this is undeniably safe. 

0 Kudos