Using $display and $monitor in Verilog - Deep Dive

Overview - Using $display and $monitor

What is it?

$display and $monitor are Verilog system tasks used to show information during simulation. $display prints a message once when it is executed. $monitor prints a message automatically whenever any variable in its list changes. They help you see what your digital design is doing inside the simulator.

Why it matters

Without $display and $monitor, you cannot easily see how signals change over time in your design. This makes debugging very hard, like trying to fix a machine without seeing its parts move. These tools let you watch your design’s behavior step-by-step, saving time and preventing mistakes.

Where it fits

Before learning $display and $monitor, you should understand basic Verilog syntax and simulation concepts. After mastering them, you can learn advanced debugging techniques like waveform viewers and assertions to catch design errors more efficiently.

Mental Model

Core Idea

$display shows a snapshot once, while $monitor watches and reports changes continuously during simulation.

Think of it like...

Imagine $display as taking a photo at a moment in time, and $monitor as a security camera that records whenever something moves.

┌─────────────┐       ┌─────────────┐
│  $display   │──────▶│ Prints once │
└─────────────┘       └─────────────┘
       │
       ▼
┌─────────────┐       ┌─────────────┐
│  $monitor   │──────▶│ Watches and │
└─────────────┘       │ prints on   │
                      │ any change  │
                      └─────────────┘

Build-Up - 7 Steps

1

Foundation

Basics of $display usage

Concept: $display prints messages once when the simulator reaches that line.

In Verilog, you write $display("Hello, world!"); inside an initial block. When simulation runs, it prints the message once at that time. Example: initial begin $display("Simulation started"); end

Result

The simulator prints: Simulation started

Understanding that $display prints once helps you place messages exactly where you want to see specific events.

2

Foundation

Basics of $monitor usage

Concept: $monitor automatically prints a message whenever any listed variable changes.

You write $monitor("Time=%0t, a=%b", $time, a); inside an initial block. The simulator prints this line every time 'a' changes. Example: initial begin $monitor("Time=%0t, a=%b", $time, a); end

Result

Whenever 'a' changes, the simulator prints the current time and value of 'a'.

Knowing $monitor watches variables continuously helps you track signal changes without adding many $display lines.

3

Intermediate

Formatting output with $display

🤔Before reading on: do you think $display can print variable values in different formats like decimal or hex? Commit to your answer.

Concept: $display supports format specifiers to print variables in binary, decimal, hex, or string formats.

You can use %b for binary, %d for decimal, %h for hex, and %s for strings. Example: initial begin int x = 10; $display("x in decimal: %d", x); $display("x in binary: %b", x); $display("x in hex: %h", x); end

Result

The simulator prints: x in decimal: 10 x in binary: 1010 x in hex: a

Understanding format specifiers lets you read values in the most meaningful way for debugging.

4

Intermediate

Controlling $monitor behavior

🤔Before reading on: do you think $monitor can be turned off or changed during simulation? Commit to your answer.

Concept: $monitor can be disabled or changed by calling $monitoroff and $monitoron, or by calling $monitor again with new variables.

Example: initial begin $monitor("a=%b", a); #10 $monitoroff; #20 $monitor("b=%b", b); end This stops monitoring 'a' after 10 time units and starts monitoring 'b' after 20.

Result

The simulator stops printing changes to 'a' after 10 units and starts printing changes to 'b' after 20 units.

Knowing how to control $monitor lets you focus on signals of interest at different times.

5

Intermediate

Differences between $display and $monitor

🤔Before reading on: do you think $display and $monitor can be used interchangeably? Commit to your answer.

Concept: $display prints once when called; $monitor prints automatically on changes. They serve different debugging needs.

Use $display for one-time messages or checkpoints. Use $monitor to watch signals continuously without extra code. Example: initial begin $display("Start"); $monitor("a=%b", a); end

Result

$display prints 'Start' once; $monitor prints 'a' whenever it changes.

Understanding their difference prevents misuse and helps choose the right tool for debugging.

6

Advanced

Using $display and $monitor in complex testbenches

🤔Before reading on: do you think $monitor can slow down simulation if used carelessly? Commit to your answer.

Concept: In large testbenches, excessive $monitor calls can slow simulation; selective use and formatting improve efficiency.

Example: initial begin $monitor("Time=%0t, a=%b, b=%b", $time, a, b); end Use conditional statements to limit printing: always @(posedge clk) begin if (error) $display("Error at time %0t", $time); end

Result

Simulation runs efficiently while showing important changes and errors.

Knowing performance impact guides you to balance visibility and speed in real projects.

7

Expert

Internal behavior and limitations of $monitor

🤔Before reading on: do you think $monitor triggers on every variable change instantly, or is there a delay? Commit to your answer.

Concept: $monitor triggers at simulation time steps after all events settle, not instantly on every change, which can affect timing analysis.

$monitor watches variables and prints after all signal updates in a time step complete. It does not print multiple times within the same time unit even if variables change multiple times. This means $monitor output reflects stable values at each simulation time point.

Result

$monitor output shows consistent snapshots per time unit, avoiding clutter from rapid changes.

Understanding $monitor’s timing behavior helps interpret output correctly and avoid confusion about signal changes.

Under the Hood

$display is a system task that executes once when the simulator reaches its line, printing the formatted string immediately. $monitor registers a callback that triggers after every simulation time step if any watched variable changed, printing the formatted string once per time unit. Internally, $monitor tracks changes and schedules output after all events settle to avoid redundant prints.

Why designed this way?

This design balances performance and usability. Printing once per time step prevents flooding output with rapid changes. $display’s one-time print fits checkpoint needs. Alternatives like printing on every change would slow simulation and produce unreadable logs.

┌─────────────┐
│ Simulation  │
│ Time Step   │
└─────┬───────┘
      │
      ▼
┌─────────────┐       ┌─────────────┐
│ Signal      │──────▶│ Change      │
│ Updates     │       │ Detection   │
└─────────────┘       └─────┬───────┘
                               │
                               ▼
                      ┌─────────────┐
                      │ $monitor    │
                      │ Prints once │
                      │ per time    │
                      │ step        │
                      └─────────────┘

$display executes immediately when called.

Myth Busters - 4 Common Misconceptions

Quick: Does $monitor print immediately when a variable changes, or only after all changes in a time step? Commit to your answer.

Common Belief: $monitor prints instantly every time a variable changes, even multiple times in the same time unit.

Reality: $monitor prints only once per simulation time step after all changes settle, not instantly on every change.

Why it matters: Believing $monitor prints instantly can confuse you when rapid changes appear as single outputs, leading to wrong debugging conclusions.

Quick: Can $display be used to continuously watch variables like $monitor? Commit to your answer.

Common Belief: $display can replace $monitor by putting it inside always blocks to print on every change.

Reality: $display prints only when executed; it does not automatically track changes. Using it inside always blocks can cause redundant prints and clutter.

Why it matters: Misusing $display for continuous monitoring creates noisy logs and slows simulation, making debugging harder.

Quick: Does $monitor automatically stop printing after some time or must it be manually controlled? Commit to your answer.

Common Belief: $monitor stops printing automatically after a few changes or time units.

Reality: $monitor continues printing on every change until explicitly turned off with $monitoroff or simulation ends.

Why it matters: Assuming automatic stop can cause missed outputs or confusion about why monitoring stopped unexpectedly.

Quick: Is it safe to use $monitor in very large designs without performance concerns? Commit to your answer.

Common Belief: $monitor has no performance impact and can be used freely anywhere.

Reality: $monitor can slow simulation if monitoring many variables or printing complex messages frequently.

Why it matters: Ignoring performance impact can make simulations slow and inefficient, wasting time and resources.

Expert Zone

1

$monitor output is synchronized with simulation time steps, so it never shows intermediate unstable values within a time unit.

2

Using multiple $monitor calls overwrites previous ones; only the last $monitor is active unless you use $monitoron/$monitoroff carefully.

3

Format specifiers in $display and $monitor support advanced options like field width and padding, useful for aligned logs in complex simulations.

When NOT to use

$monitor is not suitable for real-time hardware debugging or when you need cycle-accurate tracing inside clock cycles. Use waveform viewers or assertions instead. $display is not good for continuous monitoring; use it for checkpoints or error messages only.

Production Patterns

In professional testbenches, $display is used for key event messages and error reporting. $monitor is used sparingly to watch critical signals. Most teams rely on waveform viewers for detailed signal tracing and use $display/$monitor for quick textual checks and debugging.

Connections

Event-driven simulation

$monitor relies on event-driven simulation to detect signal changes and schedule output.

Understanding event-driven simulation helps grasp why $monitor prints only after all changes settle in a time step.

Logging in software engineering

$display and $monitor are like logging functions that record program state for debugging.

Knowing software logging principles clarifies how to use $display/$monitor effectively to trace design behavior.

Real-time monitoring in industrial control

Both $monitor and industrial sensors watch for changes and report them, but $monitor batches reports per time unit.

This connection shows how digital simulation balances detail and performance like real-world monitoring systems.

Common Pitfalls

#1 Using $display inside an always block to watch signals continuously.

Wrong approach:

always @(a) begin
$display("a changed to %b", a);
end

Correct approach:

initial begin
$monitor("a changed to %b", a);
end

Root cause:

Misunderstanding that $display prints only when executed, causing many prints and clutter instead of efficient monitoring.

#2 Calling multiple $monitor statements without turning off previous ones.

Wrong approach:

initial begin
$monitor("a=%b", a);
#10 $monitor("b=%b", b);
end

Correct approach:

initial begin
$monitor("a=%b", a);
#10 $monitoroff;
#10 $monitor("b=%b", b);
end

Root cause:

Not knowing $monitor calls overwrite previous monitors, leading to unexpected missing outputs.

#3 Ignoring performance impact of $monitor on large designs.

Wrong approach:

initial begin
$monitor("a=%b, b=%b, c=%b, d=%b, e=%b", a, b, c, d, e);
end

Correct approach:

initial begin
$monitor("a=%b, b=%b", a, b);
// Monitor only critical signals
end

Root cause:

Assuming $monitor has no cost, causing slow simulations and wasted resources.

Key Takeaways

$display prints messages once when the simulator executes that line, useful for checkpoints and events.

$monitor automatically prints messages whenever any watched variable changes, helping track signal activity continuously.

$monitor prints once per simulation time step after all changes settle, not instantly on every change.

Use $display and $monitor thoughtfully to balance visibility and simulation performance in your testbenches.

Controlling $monitor with $monitoroff and $monitoron lets you focus on relevant signals during different simulation phases.

Practice

1. What is the main difference between $display and $monitor in Verilog?

easy

A. $display prints continuously; $monitor prints only once.

B. $display prints once when called; $monitor prints whenever a variable changes.

C. $display is used for debugging; $monitor is used for synthesis.

D. $display prints to a file; $monitor prints to the console.

Solution

1. Step 1: Understand $display behavior

   $display prints a message only once at the time it is called during simulation.

2. Step 2: Understand $monitor behavior

   $monitor automatically prints a message every time any of the monitored variables change value.

3. Final Answer:

   $display prints once when called; $monitor prints whenever a variable changes. -> Option B

4. Quick Check:

   $display = once, $monitor = on change [OK]

Hint: Remember: display = one-time print, monitor = auto on change [OK]

Common Mistakes:

• Thinking $display prints continuously
• Confusing $monitor with file output
• Assuming $monitor prints only once

2. Which of the following is the correct syntax to print the value of a 4-bit register reg [3:0] count; using $display?

easy

A. $display("Count value: %d", count);

B. $display("Count value: %h", count);

C. $display("Count value: %s", count);

D. $display("Count value: %b", count);

Solution

1. Step 1: Identify the data type and format specifier

   The register count is 4-bit binary, so binary format specifier %b is appropriate.

2. Step 2: Match format specifier with $display syntax

   $display("Count value: %b", count); correctly prints the binary value of count.

3. Final Answer:

   $display("Count value: %b", count); -> Option D

4. Quick Check:

   Binary format = %b [OK]

Hint: Use %b for binary, %d decimal, %h hex in $display [OK]

Common Mistakes:

• Using %s which is for strings, not numbers
• Using %d for binary values
• Forgetting to include variable after format string

3. Given the following Verilog code snippet, what will be the output during simulation?

reg [1:0] a;
initial begin
  a = 2'b00;
  $monitor("Time=%0t a=%b", $time, a);
  #5 a = 2'b01;
  #5 a = 2'b11;
  #5 a = 2'b10;
end

medium

A. Prints four lines showing time and value of 'a' at 0, 5, 10, and 15 time units.

B. Prints only one line at time 0 with initial value of 'a'.

C. Prints three lines at times 5, 10, and 15 but not at time 0.

D. No output because $monitor is not called correctly.

Solution

1. Step 1: Understand $monitor initial print

   $monitor prints immediately when called (time 0) and then whenever monitored variables change.

2. Step 2: Trace changes to 'a' and timing

   'a' changes at 5, 10, and 15 time units, so $monitor prints at these times plus initial time 0.

3. Final Answer:

   Prints four lines showing time and value of 'a' at 0, 5, 10, and 15 time units. -> Option A

4. Quick Check:

   $monitor prints on call + changes = 4 prints [OK]

Hint: $monitor prints immediately and on every change [OK]

Common Mistakes:

• Assuming $monitor prints only on changes, missing initial print
• Thinking $monitor prints only once
• Confusing $display behavior with $monitor

4. Identify the error in this Verilog code snippet:

reg clk;
initial begin
  $monitor("Clock = %b", clk);
  clk = 0;
  #10 clk = 1;
  #10 clk = 0;
end

medium

A. clk should be declared as wire, not reg, for $monitor to work.

B. Missing semicolon after $monitor statement causes syntax error.

C. $monitor is called before clk is initialized, so initial print shows unknown value.

D. No error; code runs and prints correctly.

Solution

1. Step 1: Check order of $monitor and variable initialization

   $monitor is called before clk is assigned a value, so initial print shows 'x' (unknown).

2. Step 2: Understand $monitor initial print behavior

   $monitor prints immediately on call, so it prints clk's value before initialization.

3. Final Answer:

   $monitor is called before clk is initialized, so initial print shows unknown value. -> Option C

4. Quick Check:

   Initialize variables before $monitor call [OK]

Hint: Initialize variables before $monitor to avoid unknown prints [OK]

Common Mistakes:

• Assuming $monitor waits for variable initialization
• Thinking missing semicolon causes error here
• Confusing reg and wire for $monitor usage

5. You want to monitor two signals reg [3:0] data; and reg valid; so that the simulation prints their values only when valid changes. Which is the best way to do this using $monitor?

hard

A. $monitor("Data=%b Valid=%b", data, valid);

B. Use an if statement inside $monitor to print only when valid changes.

C. Use $monitor with only valid variable: $monitor("Valid=%b", valid); and add $display for data.

D. Use $monitor with both variables but assign data only when valid changes.

Solution

1. Step 1: Understand $monitor behavior with multiple variables

   $monitor prints whenever any monitored variable changes. Monitoring both data and valid prints on either change.

2. Step 2: Restrict printing to valid changes only

   To print only when valid changes, monitor only valid. But then data won't print updated values automatically.

3. Step 3: Best practical approach

   Monitoring both variables prints all changes, but since data changes only when valid changes, this works well. $monitor("Data=%b Valid=%b", data, valid); is simplest and correct.

4. Final Answer:

   $monitor("Data=%b Valid=%b", data, valid); -> Option A

5. Quick Check:

   Monitor all needed vars; prints on any change [OK]

Hint: Monitor all variables to track changes together [OK]

Common Mistakes:

• Trying to put conditions inside $monitor (not allowed)
• Monitoring only one variable and missing others' changes
• Using $display inside $monitor incorrectly