cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
1,565 Views
Registered: ‎09-27-2018

Define combinational logic signal as clock in the constraints file

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.

0 Kudos
6 Replies
Highlighted
Voyager
Voyager
1,556 Views
Registered: ‎08-16-2018

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

0 Kudos
Highlighted
Visitor
Visitor
1,548 Views
Registered: ‎09-27-2018

Well actually I want to generate a 2Mhz clock. The minimum frequency PLL clock can generate is around 4Mhz. 

0 Kudos
Highlighted
Teacher
Teacher
1,521 Views
Registered: ‎07-09-2009

As John says,

 

use a faster global clock, and send a one clock wide enable around at the frequency you require,

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Guide
Guide
1,508 Views
Registered: ‎01-23-2009

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.

 

Avrum

 

Highlighted
Visitor
Visitor
1,491 Views
Registered: ‎09-27-2018

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.

0 Kudos
Highlighted
Adventurer
Adventurer
1,484 Views
Registered: ‎05-23-2018

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.