Why always blocks are needed in Verilog - Why It Works This Way

Overview - Why always blocks are needed

What is it?

In Verilog, always blocks are special code sections that run repeatedly to model hardware behavior. They describe how signals change over time based on events like clock edges or input changes. This lets us simulate and design circuits that react dynamically, like flip-flops or combinational logic. Without always blocks, we couldn't express how hardware updates continuously.

Why it matters

Hardware circuits are always working and reacting to signals, not just running once like a normal program. Always blocks let us capture this ongoing behavior in code. Without them, we couldn't model real hardware timing or state changes, making it impossible to design or test digital circuits accurately. This would slow down hardware development and cause errors in chips.

Where it fits

Before learning always blocks, you should understand basic Verilog syntax and how signals represent wires and registers. After mastering always blocks, you can learn about finite state machines, timing control, and synthesizable design patterns that build real hardware systems.

Mental Model

Core Idea

Always blocks are like a loop that watches for signal changes and updates hardware behavior continuously.

Think of it like...

Imagine a security guard who never sleeps and always watches the doors. Whenever someone opens a door (signal changes), the guard reacts immediately. The always block is like that guard, always ready to respond to events in the circuit.

┌───────────────┐
│   always @    │
│ (event list)  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│  Execute code │
│  to update    │
│  signals      │
└───────────────┘
       │
       └─> Wait for next event
       (repeat forever)

Build-Up - 7 Steps

1

Foundation

Signals and Continuous Assignment

Concept: Understanding how signals represent wires and how continuous assignments model simple hardware connections.

In Verilog, signals like wires carry values. You can assign values continuously using the 'assign' keyword, which models simple connections like wires or gates. For example, 'assign out = a & b;' means out always reflects the AND of a and b.

Result

The output signal updates immediately when inputs change, modeling combinational logic.

Knowing continuous assignment shows how simple hardware connections work, but it can't model memory or sequential behavior.

2

Foundation

Limitations of Continuous Assignments

Concept: Recognizing that continuous assignments cannot model storage or timing-dependent behavior.

Continuous assignments update outputs instantly with input changes. But real hardware often needs to remember past values or change only on clock edges, like flip-flops. Continuous assignments can't do this because they lack timing control and state.

Result

You cannot model circuits that need memory or react only at specific times.

Understanding this gap motivates the need for a construct that can handle timing and state changes.

3

Intermediate

Introducing always Blocks for Behavior

Concept: Learning that always blocks let you describe how hardware reacts to events and stores state.

An always block runs whenever specified signals change, letting you write code that updates registers or models sequential logic. For example, 'always @(posedge clk) q <= d;' models a flip-flop that updates q on the clock's rising edge.

Result

You can now describe circuits that remember values and change at specific times.

This step shows how always blocks bridge the gap between simple wires and real hardware behavior.

4

Intermediate

Event Control and Sensitivity Lists

🤔Before reading on: Do you think always blocks run continuously or only when certain signals change? Commit to your answer.

Concept: Understanding how always blocks use sensitivity lists to trigger execution only on specific events.

The sensitivity list after '@' tells the always block when to run. For example, '@(posedge clk)' means run only on the clock's rising edge. '@(a or b)' means run when a or b changes. This controls when hardware updates happen.

Result

Always blocks run efficiently and model hardware timing precisely.

Knowing event control prevents unnecessary code execution and models real hardware triggers.

5

Intermediate

Modeling Combinational vs Sequential Logic

🤔Before reading on: Can always blocks model both combinational and sequential logic? Commit to yes or no.

Concept: Learning how always blocks can describe both types of hardware depending on sensitivity lists and coding style.

If the always block triggers on all input changes (e.g., '@(*)'), it models combinational logic. If it triggers on clock edges (e.g., '@(posedge clk)'), it models sequential logic like flip-flops. The coding style inside the block also matters.

Result

You can flexibly describe different hardware behaviors with always blocks.

Understanding this dual use makes always blocks a powerful and versatile tool.

6

Advanced

Avoiding Latches with Proper Coding

🤔Before reading on: Do you think missing an else branch in an always block causes a latch or a flip-flop? Commit to your answer.

Concept: Recognizing that incomplete assignments in always blocks can unintentionally create latches, which are often undesired.

If you don't assign a value to a signal in every possible path inside an always block, Verilog infers a latch to hold the previous value. For example, missing an else branch means the signal keeps its old value, creating a latch. This can cause timing issues.

Result

You learn to write complete assignments to avoid unintended hardware.

Knowing this prevents subtle bugs and ensures predictable hardware synthesis.

7

Expert

Synthesis and Simulation Differences

🤔Before reading on: Do you think all always block code simulates exactly as it synthesizes into hardware? Commit to yes or no.

Concept: Understanding that some always block constructs simulate correctly but may not synthesize as intended, causing mismatches.

Certain coding styles in always blocks, like using delays or non-blocking assignments incorrectly, can simulate fine but produce different hardware after synthesis. Also, some constructs are ignored by synthesis tools. Experts carefully write always blocks to match simulation and real hardware.

Result

You gain awareness of the gap between simulation and real hardware behavior.

This knowledge helps avoid costly hardware bugs and ensures reliable designs.

Under the Hood

Always blocks are event-driven processes in the Verilog simulator. When a signal in the sensitivity list changes, the simulator schedules the always block to run. Inside, the code executes sequentially, updating registers or wires as specified. This models hardware that reacts to signal changes or clock edges. The simulator maintains a delta cycle queue to handle zero-delay updates, ensuring correct ordering of events.

Why designed this way?

Verilog was designed to model hardware behavior closely, which is inherently event-driven and parallel. Always blocks provide a way to describe this reactive behavior in a sequential programming style, making it easier for designers to write and understand hardware logic. Alternatives like purely continuous assignments were too limited, and procedural blocks with event control offered the needed flexibility.

┌───────────────┐
│ Signal change │
└──────┬────────┘
       │ triggers
       ▼
┌───────────────┐
│  always block │
│   executes    │
└──────┬────────┘
       │ updates
       ▼
┌───────────────┐
│ Registers or  │
│ wires updated │
└───────────────┘
       │
       └─> Wait for next event

Myth Busters - 4 Common Misconceptions

Quick: Do always blocks run continuously like a loop or only on events? Commit to one.

Common Belief: Always blocks run continuously like a while loop, executing code nonstop.

Reality: Always blocks run only when signals in their sensitivity list change, not continuously.

Why it matters: Thinking they run nonstop leads to confusion about simulation performance and hardware behavior.

Quick: Does missing an else branch in an always block create a flip-flop or a latch? Commit to your answer.

Common Belief: If you miss an else branch, the always block still models a flip-flop.

Reality: Missing an else branch causes Verilog to infer a latch, which holds the previous value until updated.

Why it matters: Unintended latches cause timing problems and unpredictable hardware.

Quick: Can always blocks only model sequential logic? Commit yes or no.

Common Belief: Always blocks are only for sequential logic like flip-flops and registers.

Reality: Always blocks can model both combinational and sequential logic depending on sensitivity lists and coding style.

Why it matters: Limiting always blocks to sequential logic reduces design flexibility and understanding.

Quick: Does simulation always match synthesis for always blocks? Commit yes or no.

Common Belief: Code in always blocks simulates exactly as it synthesizes into hardware.

Reality: Some always block code simulates correctly but synthesizes differently or not at all.

Why it matters: Ignoring this causes hardware bugs that are hard to debug and fix.

Expert Zone

1

Non-blocking assignments inside always blocks are crucial for modeling real hardware timing and avoiding race conditions.

2

The choice of sensitivity list (@(*) vs explicit signals) affects simulation accuracy and synthesis results.

3

Using always_comb, always_ff, and always_latch in SystemVerilog clarifies intent and improves tool support, but classic Verilog uses generic always blocks.

When NOT to use

Always blocks are not suitable for purely combinational logic that can be described with continuous assignments for simplicity and clarity. For complex state machines, using SystemVerilog constructs like always_ff is preferred. Also, for purely structural descriptions, module instantiations without always blocks are better.

Production Patterns

In real hardware design, always blocks are used to model clocked registers, reset logic, and combinational logic with careful coding to avoid latches. Designers use coding guidelines to ensure synthesis matches simulation and use tools to check for inferred latches or mismatches.

Connections

Event-driven programming

Always blocks implement event-driven behavior in hardware description languages.

Understanding event-driven programming concepts helps grasp how always blocks react only to signal changes, similar to event handlers in software.

Finite State Machines (FSM)

Always blocks are used to implement FSMs by updating state on clock edges.

Knowing how always blocks work is essential to design reliable FSMs that control hardware behavior over time.

Reactive systems in biology

Both hardware always blocks and biological reactive systems respond to stimuli or signals continuously.

Seeing hardware as a reactive system like biological feedback loops deepens understanding of continuous monitoring and response.

Common Pitfalls

#1 Unintentionally creating latches by missing else branches.

Wrong approach:

always @(posedge clk) begin
if (enable) q <= d;
end

Correct approach:

always @(posedge clk) begin
if (enable) q <= d;
else q <= q;
end

Root cause:

Not assigning a value in all paths causes Verilog to infer a latch to hold the previous value.

#2 Using blocking assignments for sequential logic causing race conditions.

Wrong approach:

always @(posedge clk) begin
q = d;
end

Correct approach:

always @(posedge clk) begin
q <= d;
end

Root cause:

Blocking assignments execute immediately, which can cause incorrect ordering in sequential logic.

#3 Incorrect sensitivity list causing simulation mismatches.

Wrong approach:

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

Correct approach:

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

Root cause:

Not including all inputs in sensitivity list causes simulation to miss updates.

Key Takeaways

Always blocks let you describe hardware that reacts to signal changes and stores state over time.

They run only when signals in their sensitivity list change, modeling real hardware events efficiently.

Proper coding inside always blocks is essential to avoid unintended hardware like latches or race conditions.

Always blocks can model both combinational and sequential logic depending on how you write them.

Understanding the difference between simulation and synthesis behavior in always blocks prevents costly hardware bugs.