In Pong Chu's "FPGA Prototyping by Verilog Examples" he recommends using a periodic enable "tick" to divide the clock while maintaining a synchronous system (to avoid putting the system clock through combinational logic).

The example for a counter (r_reg) generating a "tick" uses a mux and comparator:

assign max_tick = (r_reg == TICK_VALUE) ? 1'b1 : 1'b0;

Example of generating the tick (simulated): example

Things seem to simulate fine using this description; But, is there any reason to be worried about violating hold time for the next element in series when using the output tick generated in this manner as an enable signal? If not why not?

To clarify, my understanding is that the enabled device would see the tick in the above example at the out=0000 rising clock edge, but the tick is already being driven low again by that clock edge - would there be a concern over violating the hold time?

  • \$\begingroup\$ LUTs in most current FPGAs have zero hold time for this reason. \$\endgroup\$ – The Photon Apr 16 '14 at 20:03

There is generally no hold time problem with this approach. What your simulation doesn't show is that there is actually a significant delay from the rising clock edge to the rising/falling edge of the tick signal. If you incorporate this delay into your simulation you'll see that the tick signal doesn't change at exactly the same time as the clock and there is no hold time problem.

This is a good design style, by the way. Most FPGAs have dedicated resources for routing the clock and it's much better to generate these "tick" enable signals than to try to create a gated clock.

| improve this answer | |
  • \$\begingroup\$ Thanks. I confirmed ~7ns delay using gate-level simulation (i.imgur.com/dFtDEr7.png) \$\endgroup\$ – Sharq Apr 18 '14 at 20:02

Your Answer

