Basic Timing

One of the most difficult aspects of coding in hardware description languages is ensuring that all of your timings are correct. The purpose of this post is to provide some fundamentals in understanding how signal timing is simulated and how to think about it properly. If you understand this post, you should be able to make accurate predictions about when signals will get asserted in your designs.

Imagine some asynchronous signal A is asserted between two clock edges as shown below. Also imagine that A is an input to a positive edge triggered D flip-flop. The output of the flip-flop, B, will take on the same value as A shortly after the first rising clock edge following the assertion of A. Figure 1

Due to the propagation delay of a flip-flop, it will take some brief time before the output of the flip-flop begins showing the input. This can be seen in figure 1(a). Often times when simulating our designs, however, we will not model delays. This results in a waveform much like that seen in 1(b).

The fact that the output of the flip-flop and any combinational signals that depend on it appear to change simultaneously can be a big source of confusion. Consider the following example:

A finite state machine includes some state S that outputs a signal “count_inc”. This signal is a control signal to a counter, which causes the counter to increment by one. If the machine enters the state S on clock edge n, at what time would you expect the counter to increment? The correct answer is show in figure 2: the counter will not increment until clock edge n+1.

Figure 2

This may seem odd at first given that the count_inc signal appears to be going high on clock edge n. In fact, the reason for this behavior can be understood quite simply.

Recall that the outputs of a finite state machine come from a block of combinational logic that takes the current state as input (and, in the case of Mealy Machines, the external inputs). If the state register changes on (or soon after) clock edge n, then the combinational signal count_inc cannot change until after this point in time. Thus, count_inc cannot possibly be asserted in time for the nth clock edge as seen by the counter.

A general rule that can be followed when observing waveforms is that whenever any combinational signal has an edge on clock edge n, the corresponding sequential outputs will not change until clock edge n+1.

Let’s see an example of this with a simple FSM, one that merely counts up to a certain number when asked and returns a “done” signal upon completion. The waveform for the signals in the FSM-datapath above can be seen below:

Notice that while the start signal goes high on clock edge 0, the state does not actually change until clock edge 1. Likewise, while the “inc” signal goes high at clock edge 1, the counter does not actually increment until clock edge 2.

Once you understand these fundamentals, it should be clear to you prior to simulation what every signal in your design will be during simulation.

If you enjoyed this post and want to learn more about timing, I plan to create a post specifically about FSM timing. Stay tuned!