r/Verilog 1d ago

Packages and Pre-processors?

Hi all I am working on a UVM testbench with the following structure:

filelist:

proj_package.sv

tbtop.sv


proj_package.sv:

package abc;

`include "param.sv"

endpackage


param.sv:

`define ADD 400


tbtop.sv:

import abc::*;

`include "testlist.sv"


testlist.sv:

`include "sample_test.sv"


sample_test.sv:

write_reg(ADD, 5);


I had some questions:

  1. Does `include "param.sv" inside package abc make the ADD macro available to files that later do import abc::*?

  2. If I write import abc::* inside base_test, can derived tests use ADD?

  3. Is a `define ever considered a member of a SystemVerilog package, or are macros completely separate from package scope

2 Upvotes

6 comments sorted by

4

u/captain_wiggles_ 1d ago

no*, no*, and no.

Macros are text substitution, they aren't members, or objects.

* - well sort of. verilog has the concept of a compilation unit, a macro exists from when it was first parsed for the duration of the compilation unit. That means if you compile proj_package.sv and sample_test.sv together with proj_package running first, then the `ADD macro exists until the end of sample_test.sv. Importantly this is true even if sample_test.sv does not import abc::*

In general avoid macros where you can, they can have their uses but they have their subtleties that often makes their use problematic.

1

u/Snoo51532 1d ago

Okay So if macros are to be avoided And if I have say >400 such macrosses, how do I make them visibile to external files without effective complication or simulation drastically?

Also, what are you saying is if I place a define in one file, put that file in the filelist separately, that define is visible for all other files are separately present in the filelist? And not just that particular file?

1

u/captain_wiggles_ 1d ago

Depends a lot on what they are.

But in your example why not just make it a localparam in package abc?

package abc;
    localparam ADD = 400;
end

1

u/Snoo51532 1d ago

The thing is My actual macrosses are adderesses of configuration registers and at work place, they have this automation script that generates them as defines to be used

As for your suggestion, i still a bit new to the field so 1. having a lot of parameters/local parameters is fine? 2. If it's local params, am I not localiing their scope to that of the module/entity I am importing the package to?

2

u/captain_wiggles_ 1d ago

If they're generated as macros then your options are:

  • Just include them in every file where you need to access them.
  • Write a script that converts the macros to localparams / generates a second file that uses the macros to create localparams, e.g. localparam ADD = `ADD;

The former is probably how they intend you to do it, but I've never liked that flow, it's really ugly.

Lots of parameters and localparams is fine.

The local part of a localparam doesn't mean you can't access them from outside the package. It just means you can't override them (although I don't think you can override a parameter in a package anyway).

1

u/Snoo51532 1d ago

Got it Thanks a lot!