Trouble understanding timing simulations in Quartus?

I have tried my ALU on the functional simulation and I get the correct waveforms. However, I am confused about how to interpret the timing simulations.

What causes the ripples in the carry_out, and zero signals? Also, what causes the delays in the result?

• This is impossible to answer unless you show us the logic that you're simulating. – Dave Tweed Feb 4 '18 at 20:17

From the waveform it looks like you are doing a gate-level simulation. If so what you are seeing is the delay of the signal through the gates. As for the carry: that is why it is called a 'ripple carry' The carry of each stage depends on the carry of all the previous stages.

Suppose you add: 1111 with 0001.

Stage 0 => 1+1 = 0 carry-out = 1

Stage 1 => 1+0+carry
But initial the carry into stage is zero thus stage one first produces:
1+0+0 = 1 carry-out = 0
Some time 'DELTA' later the carry from stage 0 arrives and stage 1 now does:
1+0+1 = 0 carry-out = 1

Stage 2 => 1+0+carry
Again initial the carry into the stage is zero thus stage two first produces:
1+0+0 = 1 carry-out = 0
Two 'DELTA' times later the carry from stage 1 arrives and stage 2 now does:
1+0+1 = 0 carry-out = 1

Stage 3 => 1+0+carry
But initial the carry into stage is zero thus stage three first produces:
1+0+0 = 1 carry-out = 0
Three 'DELTA' times later the carry from stage 2 arrives and stage 3 now does:
1+0+1 = 0 carry-out = 1

This 'ripple' effect is valid for any cone of logic. Even a carry look-ahead adder needs some time to settle and in the mean time it can change value several times.

Your image also shows beautifully why you can not reduce the clock period arbitrarily. You have to wait for the last (slowest) signal to have settled otherwise you clock in a changing, wrong value.

Quartus II generates a timing netlist to perform timing simulations. There are logic elements in this netlist, so this is a gate-level simulation indeed.

Gate-level simulations mimic the real world and two paths can never have the same delay even if our simulators sometimes show the same due to limited precision.

In your circuit, each bit of result signal settles in different times. It is very normal to see spikes until all bits settle. The most important timing goal here is to settle all bits within a clock period (or until the next active edge of the clock).

Your clock period seems 100ns and result signal becomes stable in less time. This is good. The other signals (zero, carry_out) are generated from result signal.

While result bounces, it becomes zero and non-zero. This makes zero signal 0 and 1 during this time. Since it becomes stable within the clock period, there is no problem again.