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
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
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.
../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
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
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.