Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

Timing Closure with a Gated Clock

I'm making a design that processes data in several stages. In the first stage data is clocked in at 60MHz, but is only present some of the time. Once 50 samples are received a resulting value is passed to the next stage.

Right now my second stage is having difficulty meeting timing. I'm clocking it with the same 60MHz clock as the first stage, and using an enable signal to mark when the first stage results are updated. The fastest this can happen is 1.2MHz, though in actuality it will always be a random slower delay.

What is the best way to handle this? Should I use a clock control block with an enable line? How do I specify the timing of the output clock? Is it easier to just declare all of the logic as taking multiple cycles? Any advice for writing the SDC file to specify that for a whole module?

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Logic generated clocks (gating, clock dividers) are best avoided in FPGAs because those clocks tend to have large skews.

    It's not forbidden, but timing closure can get difficult.

    Use PLLs to generate other clocks or use clock enables if you can't/don't want to use a PLL.

    Use clock enable instead of clock gating.

    So, two options for you.

    a) generate a slower clock (1.2 MHz for example?) using a PLL and use that to drive your slow logic.

    Just add the derive_pll_clocks and derive_clock_uncertainty commands to your SDC.

    b) run everything in the 60 MHz clock and use a clock enable and add multi-cycle exceptions to relax the constraints.

    So, if I have an enable condition that's common to regAA and regBB and is only active one in every 50 cycles, I can use

    set_multicycle_path -setup 50 -from [get_registers regAA] -to [get_registers regBB]

    set_multicycle_path -hold 49 -from [get_registers regAA] -to [get_registers regBB]

    You can also automate it a bit

    http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    When I mentioned using an enable I wasn't referring to gating the clock with combinational logic. Altera provides an ALTCLKCTRL megafunction that allows you to enable and disable a clock without skew. The advantage of this to a PLL is that I wouldn't have to worry about buffering all the signals that need to cross the clock boundary since it would still launch at the right time. It seems like this would be the most hardware efficient way to achieve what I'm trying, but I haven't used this feature before. Seems like the best solution might be to use the clock controller along with setting the multicycle timing paths. It would be nice if there was a way to declare that the output of the clock controller was slower though so I didn't have to flag every downstream net.

    On the other hand it seems like the PLL might be the simplest solution from an analysis perspective.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Oh yeah, using a ALTCLKCTRL block is also ok.

    In any case, if you go with a gated clock, I'd use the same kind of multi-cycle exceptions as with clock enable.

    If you fiddle enough with get_fanouts, you might be able to find to automatically constrain every affected path.

    OTOH, I'm not sure if this is correct but here's an idea to constrain the gated clock:

    create_generated_clock -source clk60M -divide_by 50 -edges {0 8.333333}