I want to be able to run a simulation with a test vector located in a repository. The repository will be determined by users credentials. The repository will not necessarily be a relative path to where the script is executed from.
`ifdef FILENAME_PATH
`define FILENAME1 ``FILENAME_PATH/test1.txt // fail - what does double `` even do?`define FILENAME2 {`FILENAME_PATH,/test2.txt}// fail`define FILENAME3 {"`FILENAME_PATH`","/test3.txt"}// compiles but gives vsim-pli-3084 ($feof, fscanf etc argument 1 not valid file descriptor)
`else`define FILENAME1 /home/hard/coded/path/test1.txt //works, but not flexible for different users.
Questasim bombs out with
# ** Error (suppressible): (vopt-7063) ../../../../../../../../source/PCIe_blk/bench/tb_PCIe_lib/read_file_tasks.vh(4): Failed to find 'FILENAME_PATH' in hierarchical name '/FILENAME_PATH'
Basically the end goal is to make the stimulus script path agnostic. Relative path could be one solution, however I prefer a solution that is loaded/set during compile based on user credentials.
#2 As per the `else example, it works, however it's not flexible for other users.
Situation is : User checkout repo from git. Within their workspace is a test_vectors directory. They develop tests there. They checkin complete test vectors
-------Edit.
It would be preferred if the a script wasn't required to overwrite the text in the rtl itself. I could do a sed command, but would prefer not to, because people have a habit of checking in their butchered versions.
will override the parameter with a new value, you can also define the parameter with no value and have it set with -g instead. Using a parameter also has a benefit of not requiring that you recompile the source file to change where the directory is pointing to. You just rerun vsim with a new directory location.
This is the method I've used for this type of string/directory manipulation in the past.
From what I could glean from some experiments was that the +define+ is treating the value after the = as an integer (e.g. =45 is a '-') and won't accept a string.
apparently you can use #sformat. I've never done this, so no idea if it actually works. either way, you can probably provide this to $display or such in order to see what prints out.
The `` and `" are SystemVerilog token pasting operator. Normally, the macro pre-processor only works with inseparable tokens like identifiers, numbers and strings. If you want a macro argument substituted in the middle of one of the tokens, you need these pasting operators. What you want is
You didn't have to use systemverilog it was just cleaner...
Using only Verilog 2001 compatibility...
Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
module dir_path_verilog;// parameter [64*8-1:0] MY_PATH; // this results in a string with lots of leading spacesparameter MY_PATH;wire[64*8-1:0] my_str;assign my_str ={MY_PATH,"/test.txt"};// adds leading spaces due to my_str definitioninitialbegin$display("start test");#10;$display("%s",{MY_PATH,"/test.txt"});// no leading spaces$display("%s", my_str);// leading spaces#10;$display("end test");endendmodule
Results in the following output results:
Code:
# start test
# /this/is/a/new/path/test.txt
# /this/is/a/new/path/test.txt
# end test
and this result if the commented width defined parameter is used:
Code:
# start test
# /my_new_home/path/is/this/test.txt
# /my_new_home/path/is/this/test.txt
# end test
As I already mentioned, I've used this method previously to generate directory strings, and this was prior to SystemVerilog even existing.
It's been a while since I've used the non-string version but you may need to use a function to left justify the string if it ends up with leading spaces. I recall using such a function.
It's been a while since I've used the non-string version but you may need to use a function to left justify the string if it ends up with leading spaces. I recall using such a function.
Did you try the example in #8 it isn't the same as the first SV version as it uses a verilog wire vector instead of a string type. I compiled it with -vlog01compat in Modelsim to force it to use Std 1364-2001 and you shouldn't even have to do that if you compile it with a .v file extension.
Like I've already stated...This IS how I've done this in the past before I switched to the SV as the majority of simulators started to support SV features.
I also don't get the issue with using SV vs Verilog. SV IS Verilog you can write purely 2001 Verilog complaint code and compile it with your compilers SV switch turned on and nothing should change (as I recall only if you write problematic code would you have a chance for running across anything they actual changed i.e. improved/fixed)
- - - Updated - - -
Wait....maybe you are using Icarus Verilog. Last time I checked, that simulator isn't even fully 2001 compliant, which would explain why you are having problems.