Shall we support implicit include dependency in verilog importing?

[jsn1993]

For example, in some verilog file A.v, it instantiates some module B that is not defined in the same file but in the file B.v located in the same folder. Also, the author doesn't explicitly include B.v in A.v. Then pymtl cannot do py.test in build folder and will throw some verilator error: "Cannot find file containing module / This may be because there's no search path specified with -I/path/to/B".

The reason why currently pymtl cannot handle it, is because of the following. We usually do py.test in pymtl/build/ and then by py.test ../A/A_test.py. The first step of what pymtl does is to copy the target design from pymtl/A/A.v to build/A_0x12345.v. It doesn't copy B.v to build folder. I've verified that pymtl calls verilator to verilate the model without letting verilator know the including path, so verilator is only able to search within build folder. This is verified by copying B.v to build folder and then it works.

As verilator is able to detect the file by specifying including directories, which shouldn't require much effort to modify pymtl, I'm wondering if we should support implicit include, since I've seen some HLS tool, by default, generates SRAM module in a separate file.

[cbatten]

I do not want us to do implicit dependency. Explicit is better than implicit -- it is too easy to pick up the wrong version, and the explicit `include is also an import way to document how the Verilog files depend on each other. I feel pretty strongly about this ... we might need to figure out some special way to handle the automatically generated files by an HLS tool, but I definitely would like to avoid implict dependency includes

[rzhao01]

The way I've been handling this is just to write a small piece of code at the end of the HLS tcl script which grabs all the .v files in the synthesized design directory and concatenate them into one file. That way all the modules are in a single file. Check the PolyHS tcl scripts if you want to see how that's done.

[jsn1993]

Thanks Ritchie, I wasn't aware of the tcl scripts and their functionality. I'm going to take a look at it and hopefully replicate it in stratus hls environment.

[jsn1993]

Ok it seems like the way stratus only uses tcl file as input to generate the makefile, which is different from vivado hls who actually executes the commands in tcl.

[hawajkm]

Maybe we can try something similar to gcc -E to expand all include and in-line everything in one line? This expanded version will be the input to the pymtl rather than the normal .v file?

EDIT: We can run the following command:

iverilog -E $verilog_file > $new_verilog_file

This should preprocess the file and include everything.