Inside a package, should parameters, function, tasks, typedef, enum, union, struct be declared as local ? i.e. localparam, local function, local task, local typedef, etc
I have exemplified the two options wth parameter on both examples below, both compile.
Should i import a package outside or inside the module?
I have tried compiling both versions i put below and they both work.
Which one is the right one? Is there a right one? or is it irrelevant?
FYI: both version are same, except for the location of import package statement.
OPTION A
package my_pkg;
localparam logic param_a = 1'b1;
parameter int param_b = 5;
endpackage: my_pkg
module mytop (input clk, output result);
import my_pkg::*;
assign result = param_a;
var int firstnum = param_b;
$info("The value for result is %b",param_a);
$info("The value for firstnum is %d",param_b);
endmodule: mytop
or
OPTION B
package my_pkg;
localparam logic param_a = 1'b1;
parameter int param_b = 5;
endpackage: my_pkg
import my_pkg::*;
module mytop (input clk, output result);
assign result = param_a;
var int firstnum = param_b;
$info("The value for result is %b",param_a);
$info("The value for firstnum is %d",param_b);
endmodule: mytop
In reply to stefaniemcg:
Good question. I used https://chat.openai.com/ to help me with the answer since it will address good SW engineering practices. I agree with ChatGpt’s answer.
The location where you should import a package in your code depends on several factors and best practices. Typically, you should import packages at the top of your file, before any other code. Here are some considerations:
At the Top of the File: Importing packages at the top of your file is a widely accepted convention in most programming languages. This makes it clear to anyone reading your code which external dependencies your code relies on. It also helps prevent circular dependencies and makes it easier to manage your imports.
Content Local vs. Non-Content Local: The choice between importing a package from a content-local location (a subdirectory of your project) or a non-content local location (a system-wide package) depends on the nature of the package and your project’s requirements:
Content Local Imports: You should use content local imports for packages that are specific to your project and aren’t intended to be used globally. These are typically packages you or your team have developed for your project. Organizing them within your project’s directory structure helps maintain encapsulation and simplifies package management within your project.
Non-Content Local Imports: For third-party packages or packages intended to be shared across multiple projects, you should use non-content local imports. These packages are usually installed globally or within a virtual environment. This allows you to manage dependencies separately from your project and makes it easier to update or switch to different versions of the package.
Virtual Environments: In many programming languages, it’s also common to create virtual environments for your projects. Virtual environments isolate dependencies for each project, making it easier to manage package versions and avoid conflicts between projects. You would typically install non-content local packages within the virtual environment.
Consider Organizational Practices: In some larger projects, you may have guidelines or conventions that dictate where to place certain imports or how to structure your code. Always follow the guidelines and practices established by your project or organization.
That was not Ben’s answer, that was gibberish that I don’t agree with.
Package imports should be at the top of a design entity (package, module, interface) not the top of the file. Putting them at the top of the file has the potential to create namespace collisions, where everything gets imported into $unit.
Also, packages in SystemVerilog are completely independent of directory structure, unlike some other languages like Python. So the whole Content Local vs. Non-Content Local advice is meaningless in SystemVerilog.
Regarding location of pkg import:
From your first answer I get that OPTION A (from my post above) is the one to adopt. Is this correct?
Regarding local vs non-local content of packages:
From your second answer, I get that in SV it is irrelevant wether content is declared local or non-local. The question that i have now is why then the two options exist: localparam vs parameter ? Which should i use where?
Correct. There is also OPTION C, when module header needs to import types. See section 26.4 Using packages in module headers in the IEEE 1800-2017 SystemVerilog LRM
Within a package, there no difference between parameter and localparam. You cannot override parameters in a package so either keyword has the same behavior.