When I try to compile a testbench which includes a header file which contains a function declaration Icarus Verilog (v10.0 stable) aborts with the following error:
mpeg.vh:133: error: function declarations must be contained within a module.
This error is quite clear. However, the header file is in fact included inside of a module (the testbench). Since an include directive should just be replaced by the text inside the respective header file the function declaration is in fact contained within a module (contrary to what the error message claims).
I have used this header file before with Xilinx ISE (fuse/isim) which worked just as intended. There wasn't even a warning.
Is it allowed to declare a function inside a header file (for later inclusion inside of a module)?
I was unable to find the answer to this question in the Verilog LRM (IEEE 1364-2001, Chapter 10).
Example:
test.vh:
function integer foo;
input integer a;
begin
foo = a;
end
endfunction
test.v:
module bar;
`include "test.vh"
endmodule
Call iverilog: iverilog -o test.o -Wall test.v test.vh
In the old Verilog standard, nothing is allowed outside the scope of a module/endmodule pair. Compiler directives (things that start with `) are an exception because they are pre-processed before any other syntax.
SystemVerilog added the concept of a compilation unit, which allows code to exist outside the scope a module. But it also added packages that can be imported instead of `included to get rid of the problem of having a function multiply defined when you what one of them.
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.
I have a top level file where I have an instance of an interface. This is the code in my toplevel file
LC3_io top_io; // LC3_io is the interface which is defined seperately in my interfaces file.
LC3_test test(top_io); // Passing the interface to my testbench
test is the instance of my LC3_test(Testbench).
Now, after passing this interface to my Testbench . I have a separate testbench file where my first line of code is :
program automatic LC3_test(LC3_io.TB top_io);
I have written some other code in the testbench.
The problem when I am trying to simulate the testbench is :
**Fatal: (vsim-3695) DUT_Testing.sv(0) : The interface port 'top_io' must be passed an actual interface.
FATAL ERROR while loading design.
I do not understand where the problem could lie. I am compiling all the necessary files using vlog and trying to run/ simulate my testbench using vsim. I have tried removing program and using a module instead for the testbench but the problem persists. Is there anything I am missing here ? Thanks
It seems to me that the types don't match. You're expecting an argument of type LC3_io.TB for your program block, but you're passing in an interface of type LC3_io. Try changing your code to this:
// pass the TB modport from 'top_io'
LC3_test test(top_io.TB);
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.
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.