I want to include a verilog module into another file. How do I include it in the code and how do I compile the code to include the header file? Is it like in c?
A basic example can include them both in the same file as shown on page 4 of verilog in a day.
All files in the same folder should be automatically found.
Include them as shown in Hello_World_Program_Output or Example below.
Advanced workflows can have files.f listing the verilog or config files specifying include directories.
Include example for (3):
`include "folder/sub.sv"
module top;
sub sub_i(
.a(),
.b()
...
The file extension .v is used for verilog compilation, your compiler should use the latest standard up to Verilog 2005. The .sv extension is for SystemVerilog. Which replaced Verilog in 2009. The file extension causes the compiler to switch to SystemVerilog.
Related
I'm trying to build a Verilog file that imports global definitions from a defines file so I can keep track of all my FPGA endpoints in one place. In the my_defines file I have a list of variables like so:
`define PipeA 8'hA1
I import this file into the main file top_module using `include "my_defines.v"
When I instantiate the variable inside my top_module file, I noticed that you have to use `PipeA as the variable name instead of PipeA. If I've already imported this, why do I need the `?
`include is a verilog syntax which directs a compiler to include contents of other files in compilation. It is very similar to #include in C.
`define defines a named text replacement (macro), similar to the #define in C.
So, `define PipeA 8'hA1 defines the macro named PipeA with 8'h1 as a context. To use it in a program you need to follow verilog rules and to use the '`' syntax, as here: `PipeA.
An example
assign myVar[7:0] = `PipeA;
The pre-processor will replace `PipeA with the text form its definition:
assign myVar[7:0] = 8'h1;
The above result will be parsed by verilog.
Macro definitions are concidered global. The definition interpretation happens before any verilog analysis and is ortogonal to the scoping rules. So, no matter whre you define the macro, in a scope or outside a scope, it will still be defined everywhere within a compilation unit.
Also, standard Verilog does not have any concept of import. System verilog does, but it has nothing to do with the above.
There's a big difference between `include and import. import is something only SystemVerilog allows. The use of `define is text substitution in a pre-processing step without understanding any Verilog syntax. `PipeA invokes a text substitution macro, it is not a variable name. There is no global namespace as far as Verilog is concerned.
SystemVerilog has a package you can define which is a namespace that can be imported into a module (or another package).
I have two files, file a and file b. File a has compile directives based on whether or not 'b' is defined.
The code in a.sv is as follows:
module a_module()
initial begin
`ifdef b
$display("This is compiled in file b");
`else
$display("This is compiled in file a");
`endif
end
endmodule: a_module()
The code in b.sv is as follows:
`define b 1
`include a.sv
module b_module()
a_module a_module();
endmodule: b_module()
Despite defining 'b' before importing file a, running both files will output "This is compiled in file a".
Why is this? How do I structure my code so that a.sv will be independently compiled both times?
Verilog is different from 'c' in compilation processing. In 'c' every source file is a compilation unit and is self-contained. All macro definition are contained within it.
In verilog all declarations of macros (and all declarations in system verilog global scope) are sticky. This means that macro definitions in one source file are also seen in other source files which follow the one with declarations.
So, in verilog if you want to include the same file with different macro definitions, you would need to employ `define and `undef directives, for example,
`define b
`include "a.sv"
...
`undef b
`include "a.sv"
However, just a note of caution. In real projects this type of inclusions is a source of many errors, incorrect compilations and debugging problems. I suggest that you avoid using it.
irun does not determine define.h file. When I use irun like this
irun -f xxx.f
I've got a error message like this.
irun: E.FMUK the type of the file m_def.h could not be determined.
Above file is consist of all 'define xxxx. How can I solve this problem?
You can use irun commnad line option - vlog_ext to add new file extensions to irun.
Add extensions to the list of built-in, predefined extensions by using a plus sign ( + ) before the list of extensions to add. For example, the following option adds .rtl and .vh.
-vlog_ext +.rtl,.vh
Rename m_def.h to m_def.vh (or m_def.v).
The .h file extension is for C/C++ header files. Verilog header files more often use the .vh extension; if not then .v. SystemVerilog header files should use .svh extension.
Many Verilog/SystemVerilog simulators allow overriding/extending the accepted file extension type. Refer to the manual for the specific simulator. Note that some simulator except C/C++, Verilog, SystemVerilog, VHDL, and others. It is recommended not to add the file extension to one language that is already being used by another.
In this case .h is already used with C/C++, so don't add .h to the allowed Verilog/SystemVerilog file extension. If .vh is not supported by default, you may add it to the allowed Verilog file extension list.
Why are there Verilog verification files not in the form of a module?
The files I see start with just initial begin, and some file names use the .inc extension.
It is common to include files of arbitrary content into Verilog modules. This is done using the `include compiler directive, as described in IEEE Std 1800-2012, section "22.4 `include":
The file inclusion (include) compiler directive is used to insert the
entire contents of a source file in another file during compilation.
The result is as though the contents of the included source file
appear in place of the `include compiler directive.
It can be useful for sharing common code between different modules: parameters, define macros, tasks, functions, etc.
In general, the .inc file extension is not special. It may be a convention used by certain simulation tools.
Suppose I have a top level file that I pass to my compiler that has:
`include "my_defines.sv"
`include "my_component.sv"
Inside "my_component.sv" file, I am using some defines from "my_defines.sv", like this:
my_variable = `CONSTANT_FROM_MY_DEFINES;
The question is the following: do I need to have `include "my_defines.sv" inside "my_component.sv"? Perhaps this requirement is compiler-specific?
If your "my_defines.sv" has an "include" guard, then it is safe and better to include "my_defines.sv" in all your other files. The "include" guard at the top of "my_defines.sv" will look like this:
`ifndef MY_DEFINES_SV
`define MY_DEFINES_SV
// put your own defines here ...
`endif
include directives like that are like copying and pasting that file into the point where the include is. The compiler:
Reads the file you give it.
When it encounters an include, it reads that file.
When it's finished that file it continues the original file.
The result is that the compiler sees one big flat file.
In your example you can use stuff from my_defines in my_component because it appears earlier.
The problem with doing a lot of this is that eventually you'll end up with conflicts. Maybe two things reference each other (which include comes first), two things use the same name (clashing definitions), or multiple things have the same include statement (multiple definitions of the same thing).
Packages solve those problems. Once things start getting a little more complex, look into them.
It is dependent upon the order in which your source files are compiled. Because you are referring specifically todefine macros, which are global, it is required that the macro definitions are compiled before the macro is used. In your case, you do not need to include "my_defines.sv" inside "my_component.sv" since "my_defines.sv" was already compiled in your top file.
Macro definitions only persist across files but only to the end of the translation unit. Simulators must support two different methods of assigning source files to translation units and it's hard to get `include files full of `defines to compile correctly in both methods.
It is better use parameters or const variables for constants. Since parameters and constants follow normal scoping rules you can safely include them in every file/scope that needs them. Then it doesn't matter how the code is broken into translation units, it always compiles. I think it is easier to find the definitions when you're browsing the code because the `include is probably in the same file instead of off in some other unrelated file.
you have to include `include "my_defines.sv in my_component.sv...
best practice is add all include in one pkg and add that pkg to each of file.