The Vivado simulator wrapper is unable to set top-level generics during simulation because the command line switch "-generic_top" does not work as documented in UG900 (p89)
According to the documentation, xelab accepts a command line argument of the form -generic_top "P1=10" in order to set a top level generic during elaboration, however doing so results in the following error:
xelab -generic_top "data_width=32" lib_tb_max_hold.tb_max_hold
ERROR: [XSIM 43-3225] Cannot find design unit work.'32' in library work located at xsim.dir/work.
If spaces are inserted between the '=' and the name+value the command is recognised correctly, but the spaces prevent the name+value from being correctly set:
xelab -generic_top "data_width =32" lib_tb_max_hold.tb_max_hold
ERROR: [XSIM 43-3281] Parameter/Generic data_width specified in commandline not found in design.
xelab -generic_top "data_width= 32" lib_tb_max_hold.tb_max_hold
ERROR: [VRFC 10-1509] unknown actual generic literal value 32 for generic data_width ignored
xelab -generic_top "data_width = 32" lib_tb_max_hold.tb_max_hold
ERROR: [XSIM 43-3281] Parameter/Generic data_width specified in commandline not found in design.
If the name+value and '=' are encapsulated in double quotes the command will work, e.g:
However, this may not work on all platforms (this was tested on Windows) and the underlying subprocess.Popen routine does not seem to be able to pass an argument using this unconventional form.
The Vivado simulator wrapper is unable to set top-level generics during simulation because the command line switch "-generic_top" does not work as documented in UG900 (p89)
According to the documentation, xelab accepts a command line argument of the form
-generic_top "P1=10"
in order to set a top level generic during elaboration, however doing so results in the following error:If spaces are inserted between the '=' and the name+value the command is recognised correctly, but the spaces prevent the name+value from being correctly set:
If the name+value and '=' are encapsulated in double quotes the command will work, e.g:
However, this may not work on all platforms (this was tested on Windows) and the underlying subprocess.Popen routine does not seem to be able to pass an argument using this unconventional form.