Critical path and timing closure in Verilog - Mini Project: Build & Apply

Critical Path and Timing Closure in Verilog

📖 Scenario: You are designing a simple digital circuit in Verilog. To make sure your circuit works correctly at the desired speed, you need to identify the critical path and check timing closure.

🎯 Goal: Build a simple Verilog module with combinational logic, then analyze the critical path delay and apply timing constraints to achieve timing closure.

📋 What You'll Learn

Create a Verilog module with specific combinational logic

Define a clock period constraint

Calculate the critical path delay using delays in the code

Print the critical path delay and check if timing closure is met

💡 Why This Matters

🌍 Real World

Timing closure is essential in digital chip design to ensure circuits run correctly at the target speed without errors.

💼 Career

Understanding critical path and timing closure is a key skill for hardware engineers and FPGA designers.

1

Create a Verilog module with combinational logic

Write a Verilog module called simple_logic with inputs a, b, c and output y. Implement y = (a & b) | c using assign statements.

Verilog

// Your code here

Hint

Use assign to create combinational logic for y.

2

Add delay parameters to model gate delays

Add parameters AND_DELAY and OR_DELAY with values 5 and 3 respectively. Use #(AND_DELAY) and #(OR_DELAY) delays in the assign statements for and_out and y.

Verilog

module simple_logic(input wire a, input wire b, input wire c, output wire y);
    // Add delay parameters here
    // Your code here

Hint

Use parameter to define delays and #(delay) to specify delay on assign.

3

Calculate the critical path delay

Create a Verilog testbench module called tb_simple_logic. Declare a real variable critical_path_delay and set it to the sum of AND_DELAY and OR_DELAY. Use $display to print "Critical path delay = %0f ns" with critical_path_delay.

Verilog

module simple_logic(input wire a, input wire b, input wire c, output wire y);
    parameter AND_DELAY = 5;
    parameter OR_DELAY = 3;
    wire and_out;
    assign #(AND_DELAY) and_out = a & b;
    assign #(OR_DELAY) y = and_out | c;
endmodule

// Your testbench code here

Hint

Use a testbench module and $display to show the delay.

4

Check timing closure against clock period

In the testbench tb_simple_logic, add a parameter CLOCK_PERIOD set to 10. Add an if statement to check if critical_path_delay <= CLOCK_PERIOD. Use $display to print "Timing closure met" if true, else print "Timing closure NOT met".

Verilog

module simple_logic(input wire a, input wire b, input wire c, output wire y);
    parameter AND_DELAY = 5;
    parameter OR_DELAY = 3;
    wire and_out;
    assign #(AND_DELAY) and_out = a & b;
    assign #(OR_DELAY) y = and_out | c;
endmodule

module tb_simple_logic;
    real critical_path_delay;
    parameter CLOCK_PERIOD = 10;
    initial begin
        critical_path_delay = 5 + 3;
        $display("Critical path delay = %0f ns", critical_path_delay);
        // Your code here
    end
endmodule

Hint

Use an if statement to compare delays and print the result.

Practice

1. What is the critical path in a Verilog design?

easy

A. The shortest path between two registers

B. The slowest signal path that limits the maximum clock frequency

C. A path that has no timing constraints

D. The path with the most logic gates regardless of delay

Solution

1. Step 1: Understand critical path definition

   The critical path is the longest delay path in the design that determines the maximum speed.

2. Step 2: Identify the impact on clock frequency

   The slowest path limits how fast the clock can run without errors.

3. Final Answer:

   The slowest signal path that limits the maximum clock frequency -> Option B

4. Quick Check:

   Critical path = slowest path [OK]

Hint: Critical path = slowest path limiting clock speed [OK]

Common Mistakes:

• Confusing critical path with shortest path
• Ignoring timing constraints
• Thinking critical path is about number of gates

2. Which of the following is the correct way to specify a timing constraint in Verilog for a clock period of 10ns?

easy

A. `timescale 1ns / 1ps\n// No timing constraint specified here

B. // specify clock period\n$period(clock, 10);

C. specify\n specparam tCK = 10ns;\nendspecify

D. specify\n specparam tCK = 10;\nendspecify

Solution

1. Step 1: Understand timing constraint syntax

   In Verilog specify blocks, specparam defines timing parameters without units; units come from `timescale.

2. Step 2: Check correct usage of specparam

   specify\n specparam tCK = 10;\nendspecify correctly sets tCK = 10 (ns implied by timescale), inside specify block.

3. Final Answer:

   specify\n specparam tCK = 10;\nendspecify -> Option D

4. Quick Check:

   specparam with numeric value = correct timing constraint [OK]

Hint: Use specify block with specparam and numeric value [OK]

Common Mistakes:

• Using units inside specparam value
• Missing specify block
• Confusing timescale with timing constraints

3. Given the following Verilog code snippet, what is the critical path delay assuming gate delays are 2ns each?

module example(input clk, input a, b, output reg y);
  reg x;
  always @(posedge clk) begin
    x <= a & b;
    y <= x | b;
  end
endmodule

medium

A. 4 ns

B. 2 ns

C. 6 ns

D. 8 ns

Solution

1. Step 1: Identify combinational logic paths

   'a & b' (AND gate, 2ns) from inputs to x; 'x | b' (OR gate, 2ns) from x output and b to y.

2. Step 2: Determine longest path

   Non-blocking assignments (<=) update registers on clock edge, so delays add up through combinational logic between registers. Critical path is sum of both gates: 2ns + 2ns = 4ns.

3. Final Answer:

   4 ns -> Option A

4. Quick Check:

   Sum of gate delays in path = 4ns [OK]

Hint: Sum gate delays between registers for critical path [OK]

Common Mistakes:

• Adding unrelated gate delays
• Assuming chained logic with NBA
• Ignoring non-blocking semantics

4. Identify the timing closure issue in this Verilog snippet:

always @(posedge clk) begin
  reg1 <= input_signal;
  reg2 <= reg1 & control;
  reg3 <= reg2 | enable;
end

medium

A. No timing issue, all registers update correctly

B. Missing reset signal causes timing closure failure

C. Critical path is too long through reg1, reg2, and reg3 causing timing violation

D. Incorrect use of blocking assignments causing race conditions

Solution

1. Step 1: Analyze assignments with non-blocking operators

   reg2 <= reg1 & control uses prior reg1; reg3 <= reg2 | enable uses prior reg2.

2. Step 2: Identify combo paths

   reg1.q & control to reg2 (1 gate); reg2.q | enable to reg3 (1 gate); input to reg1 (0 gates). All short.

3. Final Answer:

   No timing issue, all registers update correctly -> Option A

4. Quick Check:

   Short paths with NBA = no violation [OK]

Hint: NBA keeps combo paths short in clocked always blocks [OK]

Common Mistakes:

• Mistaking NBA for blocking creating long paths
• Confusing functional update with timing paths
• Assuming reset affects timing closure

5. You have a critical path delay of 12ns but your clock period is 10ns. Which of the following is the best approach to achieve timing closure in your Verilog design?

hard

A. Increase the clock period to 15ns to meet timing

B. Replace all combinational logic with sequential logic

C. Add pipeline registers to break the critical path into shorter stages

D. Remove all timing constraints to let the tool optimize automatically

Solution

1. Step 1: Understand timing closure goal

   Timing closure means meeting the clock period by fixing critical paths.

2. Step 2: Evaluate options to reduce critical path delay

   Adding pipeline registers breaks long paths into shorter ones, reducing delay per stage.

3. Step 3: Reject other options

   Increasing clock period reduces performance, removing constraints is bad practice, replacing all logic is impractical.

4. Final Answer:

   Add pipeline registers to break the critical path into shorter stages -> Option C

5. Quick Check:

   Pipeline registers = timing closure technique [OK]

Hint: Use pipelining to split long critical paths [OK]

Common Mistakes:

• Ignoring performance impact of increasing clock period
• Removing timing constraints
• Misunderstanding logic types