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).
Related
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'm trying to make a counter on verilog using ise xilinx 14.7, webpack version.
Actually, I copied a counter from the book "Digital Design using digilent FPGA Boards" by R. Haskell and D. Hanna in order to understand it and make some modifications.
While syntaxis is all good, when I try to Synthetize the top module, it says unexpected token and illegal redeclaration about variables I'm calling from one of the modules, just like this picture shows. I'm new to verilog, please, if you could tell me what I'm doing wrong, I'd be very thankful.
picture
Your problem is the instantiation of the clockdiv module on line 16. The proper syntax for instantiating a module is like so:
module_name instance_name(port_connections);
Where module_name is the name of the module you want to instantiate, instance_name is the name given to this particular instance of the module, and port_connections are the connections of the input, output and inouts of the module, in either .name(connection), or ordered list style. So, I think you meant to say:
clockdiv U1( .mclk(mclk),
.clr(clr),
.clk190(clk190),
.clk48(clk48));
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.
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.