module test_module();
`include "comparator.v"
endmodule // test_module
module comparator(stag,ptag,tag_equal);
parameter n=16;
input [n-1:0] stag,ptag;
output tag_equal;
reg tag_equal;
integer i;
// initial begin
// tag_equal<=1'b1;
// end
always @(stag or ptag)
tag_equal=!(stag^ptag);
endmodule
You seem to misunderstand the purpose of Verilog `include statement. It's just including code text, if the merged text doesn't comply with Verilog syntax rules, it causes an error. Multiple modules in a single file must be not nested, they can be placed one after the other.
Include is mainly used for common constant, variable and type definition. I guess your intention should be implemented by module instantiation.
module a (
input x,
output y
);
assign y = x;
endmodule
module b (
input m,
output n
);
a a_inst (
.x (m),
.y (n)
);
endmodule
module a (
input x,
output y
);
assign y = x;
endmodule
module b (
input m,
output n
);
a a_inst (
.x (m),
.y (n)
);
endmodule
What are the downsides to multiple modules in a file?
Convenient sharing of individual modules is one but when multiple modules are closely related and unlikely to be used stand-alone I don't see this causing an issue.
At this point I often allow myself multiple modules in a file and often include their testbench in that file as well.
Yes, and the question is why?
It relates to synthesis, you want the file name to match the module name. You can't get that with two modules on the same file.
It also relates to how companies divide the labor internally, ownership of code, coding styles. There is no technical reason, it's just good practice versus bad practice.
If you want to include a verilog code, then remove module and endmodule from comparator.v. That way your include will be plain Verilog code as part of test_module. It will work fine in synthesis and simulation. However, that being said, downside is when you go to any simulation tool like Verdi, there will be no scope definition or declaration of comparator.v. It becomes difficult to navigate. As already being pointed here instantiating is best solution.
Thanks.
besides this it also impacts reuse when you are adding some_module_xyz.v when you want a module_abc in your design, build scripts get ugly and no longer make sense, and you end up synthesizing more stuff than you need to as synthesis won't know you don't need a 200K gate module in your design because you didn't use it and only wanted to use the 5K gate module that was also in the same file.
It relates to synthesis, you want the file name to match the module name. You can't get that with two modules on the same file.
It also relates to how companies divide the labor internally, ownership of code, coding styles. There is no technical reason, it's just good practice versus bad practice.
A module you want to instantiate
Code:module a ( input x, output y ); assign y = x; endmodule
The module instantiation in another module e.g.
Code:module b ( input m, output n ); a a_inst ( .x (m), .y (n) ); endmodule
Like I said in your other thread, get and read a Verilog book. This is usually discussed in the first chapter.
- - - Updated - - -
If you want them in the same file:
but having multiple modules in one file is a bad practice. The general rule you should follow is one module per file.Code:module a ( input x, output y ); assign y = x; endmodule module b ( input m, output n ); a a_inst ( .x (m), .y (n) ); endmodule
Not at all. Each module is compiled independently, they can be related or not. Restart reading your Verilog text book.Thank you, just curious. If the two modules need to be in the same file, it seems that the two modules have to have the same input and output.
It does not really work. Thank you for your comments.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?