Simulation time control with #delay in Verilog - Deep Dive

Overview - Simulation time control with #delay

What is it?

In Verilog, simulation time control with #delay lets you pause or wait for a specific amount of simulation time before executing the next statement. It uses the # symbol followed by a number to represent how many time units to wait. This helps model real hardware timing and behavior in simulations. Without it, all actions would happen instantly, which is unrealistic.

Why it matters

Simulation time control is essential because real hardware does not operate instantly; signals take time to change and propagate. Without #delay, simulations would not reflect actual hardware timing, making designs unreliable and hard to test. It allows designers to see how circuits behave over time and catch timing-related bugs early.

Where it fits

Before learning #delay, you should understand basic Verilog syntax and how procedural blocks work. After mastering #delay, you can learn about more advanced timing controls like event control, non-blocking assignments, and clock-driven simulations.

Mental Model

Core Idea

The #delay command pauses simulation time for a set amount before moving on, mimicking real hardware timing.

Think of it like...

It's like setting a kitchen timer when baking cookies; you wait for the timer to finish before taking the cookies out, just like #delay waits before running the next instruction.

┌───────────────┐
│ Start command │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ #delay 10     │  <-- Wait 10 time units
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Next command  │
└───────────────┘

Build-Up - 6 Steps

1

Foundation

Basic #delay Syntax and Usage

Concept: Introduces the #delay syntax to pause simulation time.

In Verilog, you write # followed by a number to delay execution. For example: initial begin $display("Start"); #5; $display("After 5 time units"); end This waits 5 time units before printing the second message.

Result

Output: Start After 5 time units

Understanding that #delay literally pauses simulation time helps you model how hardware signals take time to change.

2

Foundation

Time Units and Precision Basics

Concept: Explains how time units and precision affect #delay duration.

Verilog simulations have a time unit and precision set by `timescale directive, e.g., `timescale 1ns / 1ps. The number after #delay counts in these units. So #10 means 10 nanoseconds if time unit is 1ns. Example: `timescale 1ns / 1ps initial begin #10; // waits 10 ns end

Result

The delay length depends on the timescale, so #10 means different real times if timescale changes.

Knowing timescale controls the real-world meaning of #delay prevents confusion about how long delays actually last.

3

Intermediate

Using #delay in Procedural Blocks

🤔Before reading on: Do you think #delay pauses the entire simulation or just the current process? Commit to your answer.

Concept: Shows how #delay affects only the current procedural block, not the whole simulation.

In Verilog, #delay pauses only the current procedural block (like initial or always). Other blocks keep running. Example: initial begin $display("Start A"); #5; $display("End A"); end initial begin $display("Start B"); #2; $display("End B"); end Output order shows overlapping delays.

Result

Output: Start A Start B End B End A

Understanding that delays are local to processes helps you write concurrent simulations that mimic parallel hardware.

4

Intermediate

Combining #delay with Signal Assignments

🤔Before reading on: Will a signal assigned after a #delay change immediately or after the delay? Commit to your answer.

Concept: Demonstrates how #delay controls when signal assignments happen in simulation time.

Example: reg a; initial begin a = 0; #10 a = 1; end The signal 'a' changes from 0 to 1 after 10 time units, not instantly.

Result

Signal 'a' is 0 initially, then becomes 1 after 10 time units.

Knowing #delay controls assignment timing is key to modeling hardware behavior accurately.

5

Advanced

Difference Between Blocking and Non-blocking with #delay

🤔Before reading on: Does #delay behave the same with blocking (=) and non-blocking (<=) assignments? Commit to your answer.

Concept: Explains how #delay interacts differently with blocking and non-blocking assignments in sequential logic.

Blocking assignments (=) execute in order and pause at #delay. Non-blocking (<=) schedule updates for later, allowing parallelism. Example: initial begin a = 0; #5 a = 1; // blocking end initial begin b <= 0; #5 b <= 1; // non-blocking end

Result

Blocking delays pause the process; non-blocking schedules updates without pausing the whole block.

Understanding this difference prevents timing bugs in sequential logic simulation.

6

Expert

Subtle Timing Effects and Zero-Delay #0

🤔Before reading on: Does #0 delay execution or run immediately? Commit to your answer.

Concept: Explores how #0 creates a zero-time delay that still schedules events for the next simulation cycle.

Using #0 does not pause time but defers execution to the next simulation step. Example: initial begin $display("Before #0"); #0 $display("After #0"); $display("End"); end Output order shows #0 schedules the middle display after the current statements.

Result

Output: Before #0 End After #0

Knowing #0 schedules events without advancing time helps manage race conditions and event ordering.

Under the Hood

The Verilog simulator maintains a simulation time counter and an event queue. When it encounters #delay, it schedules the next statement to run after the specified time units by placing it in the event queue at the future simulation time. The current process pauses, but other processes continue. The simulator advances time by processing events in time order.

Why designed this way?

This design mimics real hardware where signals change over time, not instantly. Scheduling events allows concurrent processes to run independently and models hardware concurrency. Alternatives like blocking the entire simulation would be unrealistic and inefficient.

┌───────────────┐
│ Current Time  │
│   (t)        │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Encounter #delay│
│  Schedule event│
│ at time t+delay│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Pause current  │
│ process       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Advance time  │
│ to next event │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Resume process│
│ at t+delay    │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does #delay pause the entire simulation or just one process? Commit to your answer.

Common Belief: Many think #delay stops the whole simulation for the delay time.

Reality: #delay only pauses the current procedural block; other blocks continue running concurrently.

Why it matters: Believing it pauses everything leads to wrong assumptions about signal timing and concurrency, causing design errors.

Quick: Does #0 mean no delay at all? Commit to your answer.

Common Belief: Some believe #0 means the statement runs immediately without any scheduling.

Reality: #0 schedules the statement to run in the next simulation cycle, not instantly, allowing other events to process first.

Why it matters: Misunderstanding #0 can cause subtle race conditions and unexpected simulation order.

Quick: Is the delay time always in nanoseconds? Commit to your answer.

Common Belief: People often assume #delay numbers are always in nanoseconds.

Reality: The delay units depend on the `timescale directive, which can be nanoseconds, microseconds, or other units.

Why it matters: Ignoring timescale leads to incorrect timing assumptions and simulation mismatches.

Quick: Does #delay affect signal assignments immediately? Commit to your answer.

Common Belief: Some think signal assignments happen instantly even if preceded by #delay.

Reality: Signal assignments after #delay happen only after the delay period ends.

Why it matters: This misconception causes confusion about when signals change, leading to incorrect testbench behavior.

Expert Zone

1

Using #0 delays is a common technique to break zero-time race conditions by deferring execution to the next simulation cycle.

2

The interaction of #delay with non-blocking assignments is subtle and critical for modeling synchronous logic correctly.

3

Different simulators may handle very small delays or zero delays slightly differently, so understanding the standard helps write portable code.

When NOT to use

Avoid using #delay for clock generation or precise timing control in complex designs; instead, use clock-driven always blocks or event controls. For cycle-accurate modeling, rely on non-blocking assignments and proper clock edges rather than arbitrary delays.

Production Patterns

In real-world testbenches, #delay is often used for stimulus timing and simple wait periods. Production RTL code avoids #delay for synthesis and uses clocked logic. Advanced verification uses #delay combined with event controls to model timing accurately.

Connections

Event-driven simulation

Builds-on

Understanding #delay is key to grasping how event-driven simulators schedule and execute events over simulation time.

Concurrency in Operating Systems

Similar pattern

Like #delay pauses one process but lets others run, OS concurrency manages multiple threads independently, helping understand parallelism.

Project Management Scheduling

Analogous concept

Just as #delay schedules tasks in simulation time, project managers schedule tasks with delays and dependencies, showing how timing controls flow.

Common Pitfalls

#1 Assuming #delay pauses the entire simulation.

Wrong approach:

initial begin
$display("Start");
#10;
$display("End");
end

initial begin
$display("Other process start");
end

Correct approach:

initial begin
$display("Start");
#10;
$display("End");
end

initial begin
#5 $display("Other process during delay");
end

Root cause:

Misunderstanding that #delay only affects the current process, not the whole simulation.

#2 Using #delay for clock generation in synthesizable code.

Wrong approach:

always begin
clk = 0;
#5 clk = 1;
#5 clk = 0;
end

Correct approach:

always @(posedge clk) begin
// synchronous logic here
end

Root cause:

Confusing simulation-only delays with hardware clocking, which must be edge-driven for synthesis.

#3 Ignoring timescale and assuming delay units are fixed.

Wrong approach:

`timescale 1ns / 1ps
initial begin
#10 $display("10 units");
end

`timescale 1us / 1ns
initial begin
#10 $display("10 units");
end

Correct approach:

Always check and set `timescale appropriately to match intended delay units.

Root cause:

Not understanding that #delay units depend on the `timescale directive.

Key Takeaways

#delay pauses only the current procedural block, allowing other processes to run concurrently.

The actual time a #delay represents depends on the simulation timescale setting.

Zero delay (#0) schedules events for the next simulation cycle, not instantly.

Using #delay correctly is essential for realistic hardware timing simulation but should be avoided in synthesizable RTL for clocking.

Understanding how #delay interacts with blocking and non-blocking assignments is key to accurate sequential logic modeling.

Practice

1. What does the #delay statement do in Verilog simulation?

easy

A. Pauses the simulation for a specified time before executing the next statement

B. Immediately ends the simulation

C. Skips the next statement without delay

D. Changes the clock frequency during simulation

Solution

1. Step 1: Understand the role of #delay

   The #delay statement in Verilog is used to pause the simulation for a certain amount of time before the next statement runs.

2. Step 2: Compare options with the definition

   Only Pauses the simulation for a specified time before executing the next statement correctly describes this behavior. Options A, B, and C describe unrelated or incorrect actions.

3. Final Answer:

   Pauses the simulation for a specified time before executing the next statement -> Option A

4. Quick Check:

   #delay pauses simulation = D [OK]

Hint: Remember: #delay waits before next action runs [OK]

Common Mistakes:

• Thinking #delay ends simulation
• Confusing #delay with clock control
• Assuming #delay skips statements

2. Which of the following is the correct syntax to delay 10 time units in Verilog?

easy

A. #10 delay;

B. #delay 10;

C. delay #10;

D. #10;

Solution

1. Step 1: Recall correct delay syntax

   In Verilog, the correct syntax to delay is #time; where time is a number representing delay units.

2. Step 2: Match options to syntax

   #10; matches the correct syntax: #10;. Options A, C, and D are incorrect because they misuse keywords or add extra words.

3. Final Answer:

   #10; -> Option D

4. Quick Check:

   Delay syntax = #time; = B [OK]

Hint: Delay uses # followed directly by number and semicolon [OK]

Common Mistakes:

• Adding extra words after #delay
• Using #delay keyword instead of #number
• Missing semicolon after delay

3. What will be the output time sequence of the following Verilog code snippet?

initial begin
  $display("Time: %0t", $time);
  #5;
  $display("Time after delay: %0t", $time);
end

medium

A. Time: 0
Time after delay: 0

B. Time: 5
Time after delay: 10

C. Time: 0
Time after delay: 5

D. Time: 5
Time after delay: 5

Solution

1. Step 1: Understand initial time and delay effect

   The simulation starts at time 0. The first $display prints time 0. Then #5; delays simulation by 5 time units.

2. Step 2: Determine time after delay

   After the delay, the second $display prints the current time, which is 5.

3. Final Answer:

   Time: 0 Time after delay: 5 -> Option C

4. Quick Check:

   Initial time 0 + #5 delay = 5 [OK]

Hint: First print at 0, second after #5 delay at time 5 [OK]

Common Mistakes:

• Assuming time does not advance after #delay
• Printing time before delay as non-zero
• Confusing delay units with clock cycles

4. Identify the error in this Verilog code snippet using #delay:

initial begin
  #10
  $display("Delayed output");
end

medium

A. Incorrect use of $display

B. Missing semicolon after #10

C. Delay value must be in parentheses

D. initial block cannot have delays

Solution

1. Step 1: Check syntax of delay statement

   The delay statement #10 must be followed by a semicolon to separate it from the next statement.

2. Step 2: Verify other statements

   The $display statement is correct, delay values do not require parentheses, and initial blocks can have delays.

3. Final Answer:

   Missing semicolon after #10 -> Option B

4. Quick Check:

   Delay statements need semicolon = A [OK]

Hint: Always put semicolon after #delay number [OK]

Common Mistakes:

• Omitting semicolon after delay
• Adding parentheses around delay number
• Thinking delays not allowed in initial blocks

5. Given the following code, what will be the output times printed?

initial begin
  $display("Start time: %0t", $time);
  #3;
  $display("After first delay: %0t", $time);
  #2;
  $display("After second delay: %0t", $time);
end

Assuming timescale is 1ns / 1ps.

hard

A. Start time: 0
After first delay: 3
After second delay: 5

B. Start time: 0
After first delay: 2
After second delay: 4

C. Start time: 1
After first delay: 4
After second delay: 6

D. Start time: 0
After first delay: 5
After second delay: 7

Solution

1. Step 1: Analyze initial time and first delay

   The simulation starts at time 0. The first $display prints 0. Then #3; delays simulation by 3 time units, so time becomes 3.

2. Step 2: Analyze second delay and final time

   After printing time 3, the next #2; adds 2 more units, making time 5. The last $display prints 5.

3. Final Answer:

   Start time: 0 After first delay: 3 After second delay: 5 -> Option A

4. Quick Check:

   0 + 3 + 2 = 5 time units [OK]

Hint: Add delays cumulatively to get output times [OK]

Common Mistakes:

• Adding delays incorrectly or skipping first time 0
• Confusing timescale units
• Assuming delays reset time