Always block sensitivity list in Verilog - Deep Dive

Overview - Always block sensitivity list

What is it?

In Verilog, an always block runs code repeatedly based on changes in signals listed in its sensitivity list. The sensitivity list tells the simulator which signals to watch for changes to trigger the block. This helps model hardware behavior that reacts to inputs or clocks. Without it, the always block wouldn't know when to update its outputs.

Why it matters

The sensitivity list ensures that hardware simulation matches real circuits, which only react when inputs change. Without it, simulations could miss changes or run unnecessarily, causing incorrect behavior or slow simulation. This is crucial for designing reliable digital circuits that behave as expected in the real world.

Where it fits

Before learning always block sensitivity lists, you should understand basic Verilog syntax and signals (wires and regs). After this, you can learn about different types of always blocks (combinational vs sequential) and how to write correct hardware descriptions.

Mental Model

Core Idea

An always block runs only when signals in its sensitivity list change, mimicking hardware reacting to input changes.

Think of it like...

It's like a motion sensor light that turns on only when it detects movement in certain areas; the sensitivity list is the set of areas it watches.

┌───────────────────────────────┐
│          always block          │
│ ┌───────────────────────────┐ │
│ │ Sensitivity List: signals │ │
│ │  (e.g., a, b, clk)        │ │
│ └─────────────┬─────────────┘ │
│               │               │
│      Signal changes trigger   │
│      execution of the block   │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is an always block

Concept: Introduce the always block as a fundamental Verilog construct for describing behavior.

An always block is a piece of code that runs repeatedly during simulation. It models hardware that reacts to changes. For example: always @(a or b) begin y = a & b; end This block runs whenever 'a' or 'b' changes, updating 'y'.

Result

The output 'y' updates whenever inputs 'a' or 'b' change.

Understanding that always blocks describe hardware reactions is key to writing correct Verilog.

2

Foundation

What is a sensitivity list

Concept: Explain the sensitivity list as the signals that trigger the always block to run.

The sensitivity list is the list of signals inside parentheses after '@' in an always block. It tells the simulator which signals to watch. For example: always @(clk or reset) begin // code end This block runs only when 'clk' or 'reset' changes.

Result

The always block triggers only on changes to signals in the sensitivity list.

Knowing the sensitivity list controls when code runs helps avoid unnecessary or missed updates.

3

Intermediate

Difference between combinational and sequential sensitivity lists

🤔Before reading on: do you think sensitivity lists for combinational and sequential logic are the same or different? Commit to your answer.

Concept: Show how combinational always blocks list all inputs, while sequential blocks usually list only clock and reset.

Combinational logic depends on all inputs, so sensitivity lists include all signals read inside the block: always @(a or b or c) begin y = a & b | c; end Sequential logic runs on clock edges: always @(posedge clk or posedge reset) begin if (reset) y <= 0; else y <= d; end Here, only 'clk' and 'reset' are in the list.

Result

Combinational blocks react to any input change; sequential blocks react only to clock or reset edges.

Recognizing sensitivity list differences prevents simulation mismatches and hardware bugs.

4

Intermediate

Using wildcard '*' in sensitivity lists

🤔Before reading on: does using '*' in sensitivity lists always produce correct simulation results? Commit to your answer.

Concept: Introduce the '*' wildcard to automatically include all signals read in the block, simplifying combinational logic sensitivity lists.

Instead of listing every input, you can write: always @(*) begin y = a & b | c; end The '*' means 'all signals read inside this block'. This reduces errors from missing signals.

Result

The always block triggers on any input change used inside it, ensuring correct combinational behavior.

Using '*' helps avoid bugs from incomplete sensitivity lists and makes code easier to maintain.

5

Advanced

Consequences of incomplete sensitivity lists

🤔Before reading on: what happens if a signal used inside an always block is missing from its sensitivity list? Commit to your answer.

Concept: Explain how missing signals cause simulation mismatches and incorrect hardware behavior.

If a signal used inside the always block is not in the sensitivity list, the block won't run when that signal changes. For example: always @(a or b) begin y = a & b | c; // 'c' missing from list end Changes to 'c' won't trigger the block, so 'y' won't update correctly in simulation.

Result

Simulation results differ from real hardware, causing bugs that are hard to find.

Understanding this prevents subtle bugs that only appear during simulation, saving debugging time.

6

Advanced

Sensitivity lists in SystemVerilog and modern tools

Concept: Discuss how SystemVerilog and modern simulators handle sensitivity lists, including automatic sensitivity and best practices.

SystemVerilog allows always_comb blocks that automatically infer sensitivity lists: always_comb begin y = a & b | c; end This avoids manual sensitivity lists and reduces errors. Modern tools support this and recommend it for combinational logic.

Result

More reliable simulation and cleaner code without manual sensitivity list errors.

Knowing modern features helps write safer, more maintainable hardware descriptions.

7

Expert

Why sensitivity lists matter for synthesis and timing

🤔Before reading on: do sensitivity lists affect only simulation or also hardware synthesis? Commit to your answer.

Concept: Explain how sensitivity lists influence synthesis tools and timing analysis, not just simulation.

Sensitivity lists guide simulation triggers but synthesis tools infer hardware from code structure. However, incorrect sensitivity lists can hide bugs that cause synthesis mismatches. Also, sensitivity lists affect how simulators model timing and glitches, impacting verification accuracy.

Result

Correct sensitivity lists ensure simulation matches synthesized hardware behavior and timing.

Understanding this connection helps avoid costly hardware bugs and verification failures.

Under the Hood

The simulator monitors signals in the sensitivity list. When any listed signal changes value, the simulator schedules the always block to run. This mimics hardware where combinational logic reacts instantly to input changes, and sequential logic reacts on clock edges. Internally, the simulator uses event-driven simulation to efficiently update only affected blocks.

Why designed this way?

Sensitivity lists were designed to model real hardware behavior where circuits react only to input changes, not continuously. Early Verilog required manual lists to give designers control and efficiency. Later, automatic sensitivity was added to reduce human error. This design balances simulation speed and accuracy.

┌───────────────┐
│ Signal Change │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Sensitivity   │
│ List Check    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Run always    │
│ block code   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does an always block run continuously regardless of sensitivity list? Commit yes or no.

Common Belief: An always block runs all the time, ignoring the sensitivity list.

Reality: An always block runs only when signals in its sensitivity list change.

Why it matters: Believing this causes confusion about simulation behavior and leads to incorrect code assumptions.

Quick: Does using '*' in sensitivity lists guarantee correct simulation for all logic? Commit yes or no.

Common Belief: Using '*' always produces correct sensitivity lists and simulation results.

Reality: '*' works well for combinational logic but can cause issues if the block contains non-combinational constructs or delays.

Why it matters: Misusing '*' can hide bugs or cause simulation mismatches, especially in complex designs.

Quick: Do sensitivity lists affect hardware synthesis? Commit yes or no.

Common Belief: Sensitivity lists only affect simulation, not synthesis.

Reality: Sensitivity lists do not directly affect synthesis, but incorrect lists can hide bugs that cause synthesis mismatches.

Why it matters: Ignoring this can lead to hardware that behaves differently than simulation predicts.

Quick: Can you omit signals from sensitivity lists without any problem? Commit yes or no.

Common Belief: It's okay to omit some signals from sensitivity lists if you think they won't change often.

Reality: Omitting signals causes the always block not to run when those signals change, leading to incorrect simulation results.

Why it matters: This leads to subtle bugs that are hard to detect and fix.

Expert Zone

1

Sensitivity lists must include all signals read in combinational always blocks to avoid simulation mismatches, but synthesis tools infer hardware from code structure, not sensitivity lists.

2

Using always_comb in SystemVerilog automatically manages sensitivity lists, but legacy Verilog requires manual lists, so understanding both is important for mixed codebases.

3

Sensitivity lists influence simulation event scheduling and timing accuracy, affecting glitch modeling and verification of race conditions.

When NOT to use

Manual sensitivity lists are error-prone for complex combinational logic; use SystemVerilog's always_comb instead. For sequential logic, always use clock and reset edges explicitly. Avoid '*' in blocks with delays or non-blocking assignments to prevent simulation mismatches.

Production Patterns

In real projects, always_comb is preferred for combinational logic to avoid missing signals. Sequential always blocks list only clock and reset edges. Code reviews check sensitivity lists to prevent bugs. Simulation warnings help detect incomplete lists.

Connections

Event-driven simulation

Sensitivity lists are the triggers for event-driven simulation to run code blocks.

Understanding sensitivity lists clarifies how simulators efficiently update only affected parts of a design.

Reactive programming

Both sensitivity lists and reactive programming respond to changes in data or signals to trigger actions.

Knowing sensitivity lists helps grasp reactive programming concepts where code reacts automatically to data changes.

Human sensory perception

Sensitivity lists are like sensory receptors that detect changes and trigger responses.

This cross-domain link shows how systems, biological or digital, rely on detecting changes to act efficiently.

Common Pitfalls

#1 Omitting signals from the sensitivity list in combinational always blocks.

Wrong approach:

always @(a or b) begin
y = a & b | c; // 'c' missing
end

Correct approach:

always @(a or b or c) begin
y = a & b | c;
end

Root cause:

Not realizing that all signals read inside the block must be in the sensitivity list to trigger updates.

#2 Using '*' in sensitivity list with non-combinational constructs causing simulation mismatches.

Wrong approach:

always @(*) begin
y <= a + b; // non-blocking assignment inside combinational block
end

Correct approach:

always @(a or b) begin
y = a + b; // blocking assignment for combinational logic
end

Root cause:

Confusing blocking and non-blocking assignments and their impact on sensitivity and simulation.

#3 Leaving sensitivity list empty or missing entirely in older Verilog code.

Wrong approach:

always @() begin
y = a & b;
end

Correct approach:

always @(a or b) begin
y = a & b;
end

Root cause:

Misunderstanding that sensitivity lists cannot be empty and must include all relevant signals.

Key Takeaways

Always blocks run only when signals in their sensitivity list change, modeling hardware reactions.

Sensitivity lists must include all signals read inside combinational always blocks to ensure correct simulation.

Using '*' in sensitivity lists simplifies code but must be used carefully to avoid simulation errors.

Sequential always blocks typically list only clock and reset signals to trigger on edges.

Modern SystemVerilog features like always_comb automate sensitivity lists, reducing human error and improving reliability.

Practice

1. What does the sensitivity list in a Verilog always block control?

easy

A. The data type of variables inside the block

B. The clock frequency of the design

C. When the always block executes based on signal changes

D. The synthesis tool optimization level

Solution

1. Step 1: Understand the role of sensitivity list

   The sensitivity list specifies which signals trigger the always block to run when they change.

2. Step 2: Differentiate from unrelated concepts

   Data types, clock frequency, and synthesis optimization are unrelated to sensitivity lists.

3. Final Answer:

   When the always block executes based on signal changes -> Option C

4. Quick Check:

   Sensitivity list controls execution timing [OK]

Hint: Sensitivity list triggers block on signal changes [OK]

Common Mistakes:

• Confusing sensitivity list with clock frequency
• Thinking it controls variable types
• Assuming it affects synthesis optimization

2. Which of the following is the correct syntax for an always block sensitivity list that triggers on the positive edge of clock clk and any change in reset rst?

easy

A. always @(posedge clk and rst)

B. always @(posedge clk or rst)

C. always @(clk posedge or rst)

D. always @(posedge clk, rst)

Solution

1. Step 1: Recall correct sensitivity list syntax

   The correct syntax uses posedge clk and or to separate signals: always @(posedge clk or rst).

2. Step 2: Identify incorrect syntax in other options

   A uses and instead of or, B uses wrong order clk posedge, D uses comma which is invalid.

3. Final Answer:

   always @(posedge clk or rst) -> Option B

4. Quick Check:

   Use 'or' to separate signals in sensitivity list [OK]

Hint: Use 'or' between signals, 'posedge' before clock [OK]

Common Mistakes:

• Using 'and' instead of 'or' in sensitivity list
• Placing 'posedge' after signal name
• Separating signals with commas

3. Consider the following Verilog code snippet:

reg q;
always @(posedge clk or posedge rst) begin
  if (rst)
    q <= 0;
  else
    q <= d;
end

What happens to q when rst goes high?

medium

A. q is set to 0 immediately

B. q holds its previous value

C. q is set to d

D. Synthesis error occurs

Solution

1. Step 1: Analyze sensitivity list triggers

   The block triggers on positive edge of clk or rst. When rst goes high, the block runs immediately.

2. Step 2: Check the if condition inside the block

   If rst is high, q is assigned 0, resetting it.

3. Final Answer:

   q is set to 0 immediately -> Option A

4. Quick Check:

   Reset high sets q to 0 [OK]

Hint: Reset in sensitivity list triggers immediate reset [OK]

Common Mistakes:

• Assuming q holds value on reset
• Thinking q updates only on clock edge
• Confusing reset with data input

4. Identify the error in this Verilog code:

always @(clk or rst) begin
  if (rst)
    q <= 0;
  else if (posedge clk)
    q <= d;
end

medium

A. No error, code is correct

B. Missing negedge rst in sensitivity list

C. Incorrect use of nonblocking assignment <=

D. Using posedge clk inside the block instead of sensitivity list

Solution

1. Step 1: Check sensitivity list correctness

   The sensitivity list uses clk and rst without edges, so it triggers on any change.

2. Step 2: Identify improper use of posedge clk inside block

   You cannot use posedge clk as a condition inside the block; it must be in sensitivity list.

3. Final Answer:

   Using posedge clk inside the block instead of sensitivity list -> Option D

4. Quick Check:

   Edge triggers belong in sensitivity list [OK]

Hint: Put edge triggers only in sensitivity list [OK]

Common Mistakes:

• Placing edge conditions inside always block
• Ignoring sensitivity list edges
• Confusing blocking and nonblocking assignments

5. You want to write a combinational logic block that updates output y whenever any input signal a, b, or c changes. Which sensitivity list is best practice to ensure correct behavior?

hard

A. always @(*)

B. always @(negedge a and negedge b and negedge c)

C. always @(posedge a or posedge b or posedge c)

D. always @(a or b or c)

Solution

1. Step 1: Understand combinational logic sensitivity

   For combinational logic, sensitivity list should include all inputs to avoid simulation mismatches.

2. Step 2: Use @(*) for automatic sensitivity

   @(*) automatically includes all signals read inside the block, ensuring correctness and easier maintenance.

3. Final Answer:

   always @(*) -> Option A

4. Quick Check:

   Use @(*) for combinational logic sensitivity [OK]

Hint: Use @(*) to cover all inputs automatically [OK]

Common Mistakes:

• Listing signals manually and missing some
• Using edge triggers for combinational logic
• Using 'and' instead of 'or' in sensitivity list