Ifdef Vs plusargs:

Both let you control a testbench without editing source each time, so they are easy to confuse. The key question is whether you want to change what code exists (compile time) or change how the existing code behaves (run time). That single choice decides which tool fits.

A simple way to picture it

Think of building a house. An ifdef is a decision made during construction, such as whether to build a basement. Once the house is built, you cannot change that without rebuilding. A plusarg is like a light switch inside the finished house: the wiring is already there, and you flip switches any time you use the house. One changes what gets built, the other changes how you use what is built.

Side by side comparison

Example: the same idea done both ways

Here is a debug print controlled first by a compile macro, then by a run time plusarg. The macro version removes the code entirely when the macro is not defined. The plusarg version always compiles the code and decides at run time.

// Compile time: ifdef macro
module with_ifdef;
  initial begin
`ifdef DEBUG
    $display("DEBUG build: extra logging");   // only exists if +define+DEBUG
`endif
    $display("running");
  end
endmodule

// Run time: plusarg
module with_plusarg;
  initial begin
    if ($test$plusargs("DEBUG"))              // code always compiled
      $display("DEBUG run: extra logging");
    $display("running");
  end
endmodule

To change the macro version you recompile with or without +define+DEBUG. To change the plusarg version you keep the same build and just add or drop +DEBUG on the run command.

When to use ifdef

• You need to include or exclude whole blocks of code, such as an assertion set or a debug module.
• You want the excluded code to be truly absent from the image, for speed or for a clean release build.
• You are switching between mutually exclusive builds, such as gate level versus RTL wrappers.
• You are guarding tool specific or library specific code that should not compile everywhere.

When to use plusargs

• You want to pick a test, seed, config, or debug level at run time from one build.
• You run a regression where each run uses the same image with different switches.
• You want quick manual control while bringing up a block, without waiting for a rebuild.
• You want to change values, such as a transaction count, without touching source.

Using both together

In practice a real environment uses both. You might guard a heavy debug library with an ifdef so release builds stay small, and inside that library read a plusarg to set the verbosity at run time. The macro decides whether the feature is built at all; the plusarg tunes it when it is present.

module combined;
  initial begin
`ifdef DEBUG_LIB
    int level = 0;
    void'($value$plusargs("DBG_LEVEL=%d", level));   // tune at run time
    $display("debug library present, level=%0d", level);
`endif
    $display("main test running");
  end
endmodule

Common mistakes to avoid

• Expecting a plusarg to remove code: it cannot. Excluded code needs an ifdef.
• Forgetting to recompile after changing a macro: the old image still has the old choice baked in.
• Overusing ifdef for values: a value that changes often, such as a seed, belongs in a plusarg, not a macro.
• No default for a plusarg value: set a default before reading, since a missing switch leaves the variable unchanged.

For the full syntax of run time switches, see our guide on plusargs in SystemVerilog. More build and run control patterns are in our SystemVerilog tutorials and interview questions.

Frequently asked questions

Share this post: on Twitter on Facebook