Delays in Logic Circuits

Delays in Logic Circuits#

Source

Exercise 104

It takes some time for a logic gate to switch its output from high to low or vice-versa. What is the reason for this?

Note

Gate delays are important for determining the critical path in a sequential circuit. The critical path determines the maximum frequency of a circuit and thus the data that can be processed per time in a circuit.

Sequential circuits will be covered later.

Learning Goals#

  • understand how hazards and glitches are formed

  • know how to simulate a circuit with delays to illustrate glitches and other timing issues

  • know how to modify a circuit to remove glitches

Background#

Delay of Combinational Circuits#

Source

Propagation Delays#

Note

Propagation delay can have different meanings depending on the context.

For example in networking it is known as the transmission delay, but in electronics the gate delay.

Exercise 105

Which is more significant in integrated circuits?

A) signal transmission delay B) gate switch delay

Note

The \(t\)s are not rendered correctly in the subfigures in Figure 1.

Exercise 107

  • What is fan-out?

  • What is the relation between the fan-out and capacitance in the output of a gate?

Circuit Delays and CAD Tools#

Exercise 108

Why does it take more time to drive an output to high compared to low?

Exercise 109

You have a behavioral description of a circuit. How would you calculate the real propagation delays?

Exercise 110

What is the purpose of an SDF file in FPGA development?

Glitches#

Source

Exercise 111

  • What is a glitch?

  • When does a glitch typically happen?

Exercise 112

How can we (1) spot (2) avoid glitches in a K-map?

Exercise 113

The rightmost circuit cannot glitch, because no coupled variable exists. There is another source of glitch though. What is it?

CC-BY SA 4.0, Clint Cole

Requirements#

Illustrate the formation of a glitch in the simulator#

Solution

See Iverilog minimal example.

Note

Glitch only happens if the following two conditions apply:

  1. both A and C are 1, because only in this case B and ~B both effect the output. In other words, we create two paths to the output which are unbalanced.

  2. B transitions from 1 to 0, because only in this case the slow path (~B) can modify the output. Why? If B is 1, then the top and bottom AND gate outputs are 1 and 0, respectively, leading to a 1 in the output. If we transition to 0, then the fast path will deliver a 0, but the slow path won’t be able to deliver the 1 timely to hold the output at 1. After the delay of the inverter the 1 will come to the rescue and set the output to 1 again.

    The glitch does not happen if B transitions from 0 to 1, because the fast path will deliver 1 and will override the output to 1. There will be a pulse feeding the second input of the OR gate, but the fast 1 delivered in the first input will override the output and make the second input powerless.

This is the last and fourth part of the simulation.

Change the OR Gate Delay and simulate again#

Solution

If we increase the delay of the OR gate at the output, we observe that the glitch is gone. This is also true for longer delays. If we remove the delay, the glitch can be seen though. What could be the reason?

The reason is described in 10.3.3 Continuous assignment delays – SystemVerilog 2017:

In situations where a right-hand operand changes before a previous change has had time to propagate to the left-hand side, then the following steps are taken:

…

a) The value of the right-hand expression is evaluated.

b) If this right-hand side value differs from the value currently scheduled to propagate to the left-hand side, then the currently scheduled propagation event is descheduled.

c) If the new right-hand side value equals the current left-hand side value, no event is scheduled.

…

This description is also consistent with the simulator behavior:

  • \(t=0\): The output of the first AND changes (because B changes from 1 to 0) and the OR’s change to 0 is scheduled for \(t=2\).

  • \(t=0\): The output of the second AND changes (because ~B changes from 0 to 1) and OR should change to 1. The previous change to 0 gets descheduled (refer to b) above) and because 1 corresponds to the current value of OR, no event is scheduled (refer to c) above).

Why is this model chosen in Verilog? Probably because gates tend to have some inertia. In other words, the pulse must have a minimum length to cause a state change. This is also called inertial delay model. The alternative is the transport delay model. For a short comparison refer to Transport/Inertial delay. For more info about delay types and a physical gate simulation with different pulse durations refer to Timing & Concurrency III – Joanne DeGroat

Note

VHDL supports specifying both delay types on assignments. There is a workaround for transport delays in Verilog. Maybe transport delays are not common on logical blocks and that is the reason why Verilog does not have it.

There are also net delays in Verilog (wire #10 w;), and net delays seem to be treated as TODO (inertial or transport) delays too (TODO test it, but this SO reply seems to say no):

From 10.3.3 Continuous assignment delays – SystemVerilog 2017:

wire #10 wireA

This syntax, called a net delay, means that any value change that is to be applied to wireA by some other statement shall be delayed for ten time units before it takes effect. When there is a continuous assignment in a declaration, the delay is part of the continuous assignment and is not a net delay. Thus, it shall not be added to the delay of other drivers on the net. Furthermore, if the assignment is to a vector net, then the rising and falling delays shall not be applied to the individual bits if the assignment is included in the declaration.

Change the Delay of all gates and simulate again#

Solution

After increasing the delays in the gates, it is also a good idea to increase the delay for each k in the testbench. Doing so we will leave room for the propagation delay for at least three gates after we change B (15 ns).

...
for(k = 0; k < 4; k=k+1)
begin
	{A,C} = k[1:0];
	#5 B = 1;
	#5 B = 0;
	#20;  # Leave more room for observations
...

We observe that the output has a glitch of 5 ns. If we decrease the delay of the NOT, then the glitch disappears due to the inertial delay model. If we increase its delay, then the glitch increases the same duration.

We should not mistake the pulses of 5 ns in the output when A or C is high (when k is 0 or 2). These are changes due to the change of B. Note from the first requirement also applies here.

What happens if we would increase the delay of the top AND gate to 10 ns but leave others at 5 ns? Then we observe that there is no glitch anymore. The reason is that we balanced now both AND paths. If we instead increase the AND below to 6 ns, then we see that the glitch is now 11 ns (bottom path) - 5 ns (top path) = 6 ns. So the glitch duration does not only depend on the delay of the inverter.

What happens if we change the delay of the inverter (or any other gate) to 6 ns? We won’t see any glitch, because the gates won’t bother about the pulse which is less than their propagation delays.

Challenges#

Delay in Decoder#

Solution
module decoder(
	input [3:0] i,
	output [15:0] o
	);
assign o = 1 << i;
endmodule

`timescale 1 ns/1 ps
module decoder_tb;

reg [3:0] i;
wire [15:0] o;

decoder dut(i, o);

integer k = 0;

initial begin
	$dumpfile("signals.vcd");
	$dumpvars();

	for (k=0; k<16; k=k+1)
	begin
		i = k[3:0];
		#20;
		if (o != 1<<i)
			$display("assertion error");
	end
	// SW0 deassertion for measuring the 1->0 delay
	i = 1;
	#20;
	i = 0;
	#20;
	$finish;
end
endmodule

# Set Bank 0 voltage
set_property CFGBVS VCCO [current_design]
# Configuration bank voltage select
set_property CONFIG_VOLTAGE 3.3 [current_design]
# These attributes help Vivado to spot for errors
# More info: https://support.xilinx.com/s/article/55660

# On-board LEDs
set_property -dict {PACKAGE_PIN G1 IOSTANDARD LVCMOS33} [get_ports {o[0]}]
set_property -dict {PACKAGE_PIN G2 IOSTANDARD LVCMOS33} [get_ports {o[1]}]
set_property -dict {PACKAGE_PIN F1 IOSTANDARD LVCMOS33} [get_ports {o[2]}]
set_property -dict {PACKAGE_PIN F2 IOSTANDARD LVCMOS33} [get_ports {o[3]}]
set_property -dict {PACKAGE_PIN E1 IOSTANDARD LVCMOS33} [get_ports {o[4]}]
set_property -dict {PACKAGE_PIN E2 IOSTANDARD LVCMOS33} [get_ports {o[5]}]
set_property -dict {PACKAGE_PIN E3 IOSTANDARD LVCMOS33} [get_ports {o[6]}]
set_property -dict {PACKAGE_PIN E5 IOSTANDARD LVCMOS33} [get_ports {o[7]}]
set_property -dict {PACKAGE_PIN E6 IOSTANDARD LVCMOS33} [get_ports {o[8]}]
set_property -dict {PACKAGE_PIN C3 IOSTANDARD LVCMOS33} [get_ports {o[9]}]
set_property -dict {PACKAGE_PIN B2 IOSTANDARD LVCMOS33} [get_ports {o[10]}]
set_property -dict {PACKAGE_PIN A2 IOSTANDARD LVCMOS33} [get_ports {o[11]}]
set_property -dict {PACKAGE_PIN B3 IOSTANDARD LVCMOS33} [get_ports {o[12]}]
set_property -dict {PACKAGE_PIN A3 IOSTANDARD LVCMOS33} [get_ports {o[13]}]
set_property -dict {PACKAGE_PIN B4 IOSTANDARD LVCMOS33} [get_ports {o[14]}]
set_property -dict {PACKAGE_PIN A4 IOSTANDARD LVCMOS33} [get_ports {o[15]}]

# On-board Buttons
set_property -dict {PACKAGE_PIN J2 IOSTANDARD LVCMOS33} [get_ports {i[0]}]
set_property -dict {PACKAGE_PIN J5 IOSTANDARD LVCMOS33} [get_ports {i[1]}]
set_property -dict {PACKAGE_PIN H2 IOSTANDARD LVCMOS33} [get_ports {i[2]}]
set_property -dict {PACKAGE_PIN J1 IOSTANDARD LVCMOS33} [get_ports {i[3]}]

When we push on SW0, then LED0 will turn off and LED1 will turn on. When we release it, then LED0 will turn on again. The problem asks for the reaction time of LED0.

There are two ways to get the reaction time:

1. Generating the testcase and inspecting the waveform

If our testbench does not integrate this transition, then we should include both transitions.

For simulating the delays click on the left column Run Simulation ‣ Run Post-Implementation Timing Simulation.

If we peek into the simulation model (generated Verilog file) by double clicking into the design under test, we see that the design comprises many structural components like LUTs. We also notice that the structural description includes a SDF file that we discussed in exercise Exercise 110.

When we look into the waveforms, then we see that the output requires about 10 ns each time when we change the input.

The delays that the challenge asked for:

Push button assertion delay is shown as follows. Note that LED1 goes on before LED0 goes off, but we are interested in LED0 only.

Push button deassertion delay is the same:

Both reaction times are 8.747 ns.

2. Using timing report

An alternative approach is to use the timing report which is typically used to get the critical paths in a sequential design. We will use it to get the delay of all existing paths.

On the left column we click on Implementation ‣ Report Timing Summary. Synthesis section has the same option but we are interested in the post-implementation data which is the most realistic data. The tool outputs the ten worst paths as default, so we set limits in section Options ‣ Path Limits to 100 to get all the paths between inputs and outputs. We have a total of 16 times four paths. We activate Advanced ‣ Report unique pins to get rid of duplicate paths, otherwise some paths will be shown multiple times.

After generation we click on Timing Summary - timing_* ‣ Unconstrained Paths ‣ NONE to NONE ‣ Setup. Here we see that the delay between i[0] and o[0] is 8.748 ns.

Another interesting fact is that 5.297 ns is the actual logic delay and 3.451 is the interconnect delay for connecting the lego blocks in the FPGA. The interconnect makes up for more than one third of the delay. This delay can be responsible for up to the half of the whole delay path. This delay can be a bottleneck for a design.

Contents