I think there is an issue with how we are using VERILATOR_ROOT. According to the documentation:
http://www.veripool.org/projects/verilator/wiki/Manual-verilator
VERILATOR_ROOT: Specifies the directory containing the distribution kit. This is used to
find the executable, Perl library, and include files. If not specified, it will come from a default
optionally specified at configure time (before Verilator was compiled). It should not be specified
if using a pre-compiled Verilator RPM as the hardcoded value should be correct.
So the issue is that I have installed verilator using stow. But in this case you are not supposed to set VERILATOR_ROOT:
When you use configure --prefix when building verilator the path gets hard coded into the install. So things work fine without setting VERILATOR_ROOT, but our PyMTL code requires VERILATOR_ROOT to be set to get the path to the include files when we do our own compilation.
If I do not set VERILATOR_ROOT then PyMTL complains because it is not set. If I set it to be where the verilator source code (so it can find the include files) it still doesn't work. If instead I make sure that VERILATOR_ROOT is not set and change this line:
Given all of this, I propose we do not use VERILATOR_ROOT directly in PyMTL. Let verilator use or not use VERILATOR_ROOT as it wishes. Then the only thing we need is for PyMTL to be able to get the path to the include files -- it should really get them from the installed location (i.e., /Users/cbatten/install/stow-pkgs/x86_64-macosx10.7/share/verilator) not from where verilator was built from source since the source might be gone, the source might not have the right permissions, or verilator might have been installed via a package. I think verilator is setup so it is supposed to be in charge of creating the makefile -- so the easiest way is just to have our own environment variable (e.g., PYMTL_VERILATOR_INCLUDE_DIR) just for PyMTL to find the include files.
I think there is an issue with how we are using
VERILATOR_ROOT. According to the documentation:So the issue is that I have installed
verilatorusing stow. But in this case you are not supposed to set VERILATOR_ROOT:http://www.veripool.org/issues/193-Verilator-Support-install-to-non-standard-location
When you use
configure --prefixwhen buildingverilatorthe path gets hard coded into the install. So things work fine without settingVERILATOR_ROOT, but our PyMTL code requiresVERILATOR_ROOTto be set to get the path to the include files when we do our own compilation.https://github.com/cornell-brg/pymtl/blob/master/pymtl/tools/translation/verilator_cffi.py#L178
If I do not set
VERILATOR_ROOTthen PyMTL complains because it is not set. If I set it to be where theverilatorsource code (so it can find the include files) it still doesn't work. If instead I make sure thatVERILATOR_ROOTis not set and change this line:https://github.com/cornell-brg/pymtl/blob/master/pymtl/tools/translation/verilator_cffi.py#L178
To fix this, I defined a new environment variable named
PYMTL_VERILATOR_INCLUDE_DIRand set it to be either this:(i.e., where the source is when I built
verilator) or this:(i.e., where I installed
verilatorusing stow).Given all of this, I propose we do not use
VERILATOR_ROOTdirectly in PyMTL. Letverilatoruse or not useVERILATOR_ROOTas it wishes. Then the only thing we need is for PyMTL to be able to get the path to the include files -- it should really get them from the installed location (i.e.,/Users/cbatten/install/stow-pkgs/x86_64-macosx10.7/share/verilator) not from whereverilatorwas built from source since the source might be gone, the source might not have the right permissions, orverilatormight have been installed via a package. I thinkverilatoris setup so it is supposed to be in charge of creating the makefile -- so the easiest way is just to have our own environment variable (e.g.,PYMTL_VERILATOR_INCLUDE_DIR) just for PyMTL to find the include files.