09-27-2018 05:55 AM
I have an 80Mhz clock generated from vivado PLL clock. I am attempting to generate a 5Mhz clock from the 80Mhz using a counter, and then use the generated 5Mhz clock as my system clock:
always @(posedge clk5mhz) begin ... end
However, Vivado is showing hold time issues on the generated 5Mhz clock.
I guess the timing issue can be resolved had I defined my generated 5Mhz clock as a clock in the constraints file, but how can I do so.
09-27-2018 06:03 AM
Is not the best practice using signals as clocks. Alternatives:
- Generate all clocks you need with the MMCM or PLL
- Generate an ENABLE waveform that passes 1 out of 16 clocks and use the 80 MHz one
09-27-2018 08:48 AM
As John says,
use a faster global clock, and send a one clock wide enable around at the frequency you require,
09-27-2018 02:18 PM
There are a number of solutions to generate a slow clock (slow_clk) from a faster clock (fast_clk) - some better than others.
1) Use an MMCM/PLL/DCM to generate the clock
This is probably the most foolproof mechanism. But it has a number of restrictions
- the minimum frequencies of the MMCM/PLL are relatively high
- this won't work for slow peripheral clocks
- the number of MMCM/PLL/DCM in an FPGA are finite
- it is possible to run out of them
- the MMCM/PLL/DCM must all have a "constant" clock - a clock that is always running, has a known frequency and doesn't change frequency (at least not by more than a little bit)
Unfortunately, these conditions do occur in systems, so this is not always a viable solution
2) (As others have suggested) Run all logic on fast_clk, but only update the flip-flops in the slow domain on every Nth clock (where N is the divider to generate the slow clock)
- generate the "terminal count" of a counter that counts from N-1 (slow_clk_en), and then only enable your flip-flops when this signal is asserted
always @(posedge clk) begin if (rst...) begin ... end else if (slow_clk_en) begin ... update logic for slow_clk flip-flops... end end
- all paths between flip-flops coded this way become N-cycle multi-cycle paths. If you want to take advantage of this (from the timing point of view) you need to declare them as such
set_multicycle_path -from <some_mechansim_of_enumerating_slow_clk_ffs> -to <some_mechansim_of_enumerating_slow_clk_ffs> <N> set_multicycle_path -from <some_mechansim_of_enumerating_slow_clk_ffs> -to <some_mechansim_of_enumerating_slow_clk_ffs> -hold <N-1>
3) Use a BUFGCE/BUFHCE to generate a decimated clock.
Take a look at this post on using the BUFGCE.
Again, the FFs in this domain need to be constrained to run at the slow_clk rate. The above post gives the command in ISE (UCF) - see this post for more about divided clocks and constraining them.
4) Use a fabric generated clock - this is not the recommended solution
You can generate a "clock" using a divider in the fabric of the FPGA; toggling a flip-flop every N/2 fast_clk clock periods.
There are a number of things you need to deal with for this
- this "clock" must come directly from a flip-flop
- generating a "clock" from a LUT has the potential to have your system fail due to glitches on the clock
- this clock is, unless dealt with otherwise, a local clock
- a local clock is not distributed on a dedicated clock resource.
- It has unpredictable insertion latency (phase delay with respect to the fast_clk)
- this will cause potentially significant setup and hold time issues on paths between the base (fast_clk) and generated (slow_clk) clocks
- it can have high clock skew
- this can cause setup and hold time issues even on paths that are exclusively on the generated (slow_clk) clock
- the generated clock (from the flip-flop) can be routed to a BUFG/BUFH or BUFR to put the clock on a dedicated clock network
- this solves the 2nd issue above (high clock skew), but actually makes the 1st issue (timing problems between the base and generated clock) worse
- you must constrain the generated clock, otherwise paths on this clock are untimed
- you need a create_generated_clock command on the output of the flip-flop
Again, this is not a recommended mechanism.
09-28-2018 01:13 AM
I can't use the clock enable waveform since i have a sub-module that expects getting a clock at a specific low rate, so I need to generate a clock at that rate.
09-28-2018 04:17 AM
You can still generate the Clockenable, but use it on another BUFGCE/BUFHCE - like avrumw said. That way, you'll have a clock at the required frequency, just with a pretty low duty cycle.