When to use blocking (combinational) in Verilog - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of combinational logic with blocking assignments

What is the output of the following Verilog code snippet when inputs a=1 and b=0?

Verilog

module test(input a, input b, output reg y);
  always @(*) begin
    y = a & b;
    y = y | a;
  end
endmodule

A y = 1

B y = 0

C y = x (unknown)

D Compilation error

💡 Hint

Remember blocking assignments (=) execute statements in order inside always blocks.

The first assignment sets y = a & b = 1 & 0 = 0. The second assignment updates y = y | a = 0 | 1 = 1. So final y is 1.

❓ Predict Output

intermediate

Effect of blocking vs non-blocking in combinational logic

Given the following Verilog code, what is the value of y after execution if a=1 and b=0?

Verilog

module test(input a, input b, output reg y);
  always @(*) begin
    y <= a & b;
    y <= y | a;
  end
endmodule

A y = 0

B y = 1

C Simulation error

D y = x (unknown)

💡 Hint

Non-blocking assignments (<=) update variables at the end of the time step.

The first assignment schedules y to 0. The second assignment overrides the schedule with old y | a, where old y is the previous value (unknown), resulting in y = x (unknown).

🧠 Conceptual

advanced

Why use blocking assignments for combinational logic?

Which reason best explains why blocking assignments (=) are preferred for combinational logic in Verilog?

A Because blocking assignments automatically infer flip-flops.

B Because blocking assignments delay updates until the end of the time step.

C Because blocking assignments execute sequentially, reflecting combinational logic behavior accurately.

D Because blocking assignments prevent race conditions in sequential logic.

💡 Hint

Think about how combinational logic works in hardware and how blocking assignments execute.

Blocking assignments execute statements in order immediately, which matches how combinational logic computes outputs based on inputs without delay.

🔧 Debug

advanced

Identify the problem with using non-blocking assignments in combinational logic

What issue arises if non-blocking assignments (<=) are used inside a combinational always block?

A The output may hold old values causing incorrect combinational behavior.

B The code will not compile due to syntax errors.

C The synthesis tool will infer latches instead of combinational logic.

D The simulation will run faster but produce correct results.

💡 Hint

Consider when non-blocking assignments update variables during simulation.

Non-blocking assignments update variables at the end of the time step, so outputs may not reflect input changes immediately, causing incorrect combinational simulation.

🚀 Application

expert

Determine the number of items in the resulting dictionary after combinational blocking assignments

Consider the following Verilog-like pseudocode representing combinational logic with blocking assignments: always @(*) begin for (int i = 0; i < 3; i++) begin out[i] = in[i] & enable; end end If in = {1,0,1} and enable = 1, how many elements in out will be 1 after execution?

A 3

B 2

C 1

D 0

💡 Hint

Check each bit of in ANDed with enable=1.

out[0] = 1 & 1 = 1, out[1] = 0 & 1 = 0, out[2] = 1 & 1 = 1. So two elements are 1.

Practice

1. Which type of assignment should you use inside an always @(*) block to model combinational logic in Verilog?

easy

A. Continuous assignment (assign)

B. Non-blocking assignment (<=)

C. Blocking assignment (=)

D. Initial assignment

Solution

1. Step 1: Understand the purpose of always @(*) blocks

   These blocks are used to describe combinational logic where outputs depend immediately on inputs.

2. Step 2: Choose the correct assignment type for combinational logic

   Blocking assignments (=) execute statements sequentially and update values immediately, which is suitable for combinational logic.

3. Final Answer:

   Blocking assignment (=) -> Option C

4. Quick Check:

   Combinational logic uses blocking (=) [OK]

Hint: Use '=' in always @(*) for immediate updates [OK]

Common Mistakes:

• Using non-blocking (<=) in combinational blocks
• Confusing continuous assign with blocking inside always
• Using initial blocks for combinational logic

2. Which of the following is the correct syntax for a blocking assignment inside an always @(*) block?

easy

A. output <= input + 1;

B. output = input + 1;

C. assign output = input + 1;

D. initial output = input + 1;

Solution

1. Step 1: Identify the assignment type inside always @(*)

   Blocking assignments use the '=' operator inside procedural blocks.

2. Step 2: Match the syntax with blocking assignment

   The statement output = input + 1; uses '=' which is the blocking assignment syntax.

3. Final Answer:

   output = input + 1; -> Option B

4. Quick Check:

   Blocking assignment uses '=' inside always blocks [OK]

Hint: Inside always @(*), use '=' for blocking assignments [OK]

Common Mistakes:

• Using '<=' instead of '=' inside always @(*)
• Using 'assign' inside procedural blocks
• Using 'initial' for combinational logic

3. What is the output of the following Verilog code snippet?

reg a, b, c;
always @(*) begin
  a = 1'b0;
  b = a;
  c = b;
end

medium

A. a=0, b=0, c=0

B. a=0, b=1, c=1

C. a=1, b=0, c=0

D. a=1, b=1, c=1

Solution

1. Step 1: Trace the blocking assignments sequentially

   First, a = 0; sets a to 0 immediately. Then b = a; assigns b the current value of a, which is 0. Finally, c = b; assigns c the current value of b, which is 0.

2. Step 2: Confirm all variables have value 0

   All three variables a, b, and c are assigned 0 in order.

3. Final Answer:

   a=0, b=0, c=0 -> Option A

4. Quick Check:

   Blocking assignments update immediately, so all zero [OK]

Hint: Blocking updates happen immediately in order [OK]

Common Mistakes:

• Assuming b or c keep old values
• Confusing blocking with non-blocking timing
• Ignoring sequential order of assignments

4. Identify the error in this combinational logic block:

always @(*) begin
  out <= in1 & in2;
  out2 = out | in3;
end

medium

A. Using non-blocking (<=) and blocking (=) mixed in combinational block

B. Missing sensitivity list

C. Using continuous assignment inside always block

D. No error, code is correct

Solution

1. Step 1: Check assignment types inside always @(*)

   Combinational logic should use blocking assignments (=) consistently inside always @(*) blocks.

2. Step 2: Identify mixed assignment usage

   The code uses non-blocking (<=) for out and blocking (=) for out2, which is incorrect for combinational logic.

3. Final Answer:

   Using non-blocking (<=) and blocking (=) mixed in combinational block -> Option A

4. Quick Check:

   Combinational blocks use only blocking (=) [OK]

Hint: Use only '=' in combinational always blocks [OK]

Common Mistakes:

• Mixing <= and = inside combinational blocks
• Forgetting to use always @(*) for combinational logic
• Using continuous assign inside procedural blocks

5. You want to design a combinational logic block that calculates the maximum of two inputs a and b. Which of the following always @(*) blocks correctly uses blocking assignments to implement this?

hard

A. always @(*) begin
if (a > b)
max <= a;
else
max <= b;
end

B. always @(a or b) begin
if (a > b)
max = a;
else
max = b;
end

C. always @(a or b) begin
if (a > b)
max <= a;
else
max <= b;
end

D. always @(*) begin
if (a > b)
max = a;
else
max = b;
end

Solution

1. Step 1: Confirm the sensitivity list for combinational logic

   Using always @(*) is preferred for combinational logic to automatically include all inputs.

2. Step 2: Check assignment type for combinational logic

   Blocking assignments (=) must be used inside always @(*) blocks for combinational logic.

3. Step 3: Evaluate each option

   always @(*) begin if (a > b) max = a; else max = b; end uses always @(*) and blocking assignments (=), correctly modeling combinational max logic.

4. Final Answer:

   always @(*) begin if (a > b) max = a; else max = b; end -> Option D

5. Quick Check:

   Combinational max needs always @(*) and '=' [OK]

Hint: Use always @(*) with '=' for combinational max logic [OK]

Common Mistakes:

• Using non-blocking (<=) in combinational always blocks
• Using explicit sensitivity list instead of @(*)
• Mixing blocking and non-blocking assignments