preface

File directory used for test (list key files):

/home/xiaotu/my_work/uvm_demo
-cfg/
-ctl/
-rtl/
-sim/
    -Makefile
-tc/
-th/
-ver/

-f/-F affects the parsing method in the followed filelist file, and does not affect the parsing method of the followed file

A typical scenario is that the suffix path in the makefile with - f or - F is the same (only for parsing the list)  ， The absolute path is parsed according to the absolute path, and the relative path is parsed relative to the directory where the makefile is located.

However, all paths in.. / cfg/tb.f are affected by the previous - f or - F. as shown in the above figure, the file path in.. / cfg/tb.f is resolved by - f regardless of the following writing method:

-F ../ctl/ctl.f
-f ../rtl/dut.f
../rtl/a.v

-f when parsing the path in the filelist, it has nothing to do with the path where the current filelist is located

-f ../cfg/tb.f，

When the path in tb.f is a relative path, it will be parsed relative to the path where the makefile is located;

When the path in tb.f is an absolute path, it is directly parsed according to the absolute path;

Further, the path in - f path/file.f will not affect the file path resolution in file.f in any way;

-F when parsing the path in the filelist, it is related to the path where the current filelist is located

-F ../cfg/tb.f

When the path in tb.f is a relative path, the path where the prefix filelist is located will be resolved;

../cfg/cfg.f How to write in:
../th/harness.sv

cmp.log Path resolved in:
Parsing design file '../cfg/../th/harness.sv'

When the path in tb.f is an absolute path, no path will be prefixed and the absolute path will be resolved directly;

../cfg/cfg.f How to write in:
/home/xiaotu/my_work/uvm_demo/ver/my_env.sv

cmp.log Path resolved in:
Parsing design file '/home/xiaotu/my_work/uvm_demo/ver/my_env.sv'

When the inner path of tb.f is the library file loaded by - y, it is directly regarded as a relative path, and the path where the prefix filelist is located is parsed;

../cfg/cfg.f How to write in:
-y /home/xiaotu/my_work/uvm_demo/rtl

cmp.log Path resolved in:
Warning-[LFCOR] Library file or dir cannot be opened
  Library directory '../cfg//home/xiaotu/my_work/uvm_demo/rtl' cannot be 
  opened for reading due to 'No such file or directory', will skip it.
  The library was specified from command line through -y or -v.

Nested scenes

../cfg/cfg.f Path within:
-f/-F ../cfg/dut.f(arrangement A)


../cfg/dut.f The path within is:
-f/-F ../ctl/ctl.f(arrangement B)

../ctl/ctl.f The internal documents are:
../ctl/my_interface.sv

-F (level A) nested - f (Level B). Both parsing are performed according to the absolute path or the relative path of the relative Makefile;

-F (level A) nested - f (Level B), level B parses in the form of - F, the absolute path of the file in level B parses normally, and the relative path parses relative to level B (i.e... / ctl /);

Parsing design file '../cfg/../ctl/my_interface.sv'

-F (level A) nested - f (Level B), and - f followed by the absolute path filelist will lead to compilation errors (this is caused by - F, which is reasonable and has nothing to do with - F)

Makefile Medium:
-F ../cfg/tb.f

../cfg/tb.f Medium:
-f /home/xiaotu/my_work/uvm_demo/cfg/dut.f

Compilation error:

Error-[P1ARGS-CANTOPN-F] Cannot open file
  Unable to open '../cfg//home/xiaotu/my_work/uvm_demo/cfg/dut.f' due to 'No 
  such file or directory'.
  Please fix the reason mentioned above and continue.

-F (level A) nested - f (Level B). The relative paths behind - F are relative to - f followed by the relative path of the directory where the file is located

It's too windy. Take a specific example:

Makefile Medium:
-F ../cfg/tb.f

../cfg/tb.f Medium:
-f ./dut.f

./dut.f Medium( dut.f stay cfg Table of contents:
../rtl/mul_trans.v
-f ../ctl/ctl.f

../ctl/ctl.f Medium:
../ctl/my_interface.sv

So mul_ The compilation path of trans. V is:

Parsing design file '../cfg/../rtl/mul_trans.v'

../cfg ——  - F.. / CFG / tb.f makes the relative path resolution in tb.f prefixed with.. / CFG;

../cfg/../rtl/mul_trans.v ——  - F. / dut.f therefore, when parsing the file with the relative path in dut.f, the relative path is the current.. / CFG path (the function of the previous layer - F);

And my_ Resolution path of interface.sv:

Parsing design file '../cfg/../ctl/my_interface.sv'

The form is - f nested - F and then - f nested. You can see that the latter two - FS are parsed relative to.. / cfg, and there is no path superposition between the two - fs (as mentioned above, the path in - f path/file.f will not affect the file path resolution in file.f in any way);

-F (level A) nested - f (Level B), - f followed by the absolute path in the filelist (if the filelist is found), it will be compiled as an absolute path

Makefile Medium:
-F ../cfg/tb.f

../cfg/tb.f Medium:
-f ../cfg/dut.f

../cfg/dut.f Medium:
/home/xiaotu/my_work/uvm_demo/rtl/mul_trans.v

Compilation results (this point deviates from my previous memory. I'll check it again. The measured results are indeed like this):

Parsing design file '/home/xiaotu/my_work/uvm_demo/rtl/mul_trans.v'

From a comprehensive point of view, - f nesting - F will affect - F's resolution of the relative path in the subsequent filelist, which should be used with extreme caution;

-F (level A) nesting - f (Level B)

Follow the law of - F layer by layer, omitted

summary

Because - f has a greater impact on the subsequent progressive disassembly of filelist, I think it is the most reasonable and safe to organize filelist in the way of - F + absolute path.