Closed kraigher closed 8 years ago
Sounds good! Just adding dependency scanning would improve the situation for those doing mixed-language. add_external_library
helps a bit but for those actively developing their Verilog code the scanner would be an improvement
I have made an initial prototype on the systemverilog
branch. The verilog code is found in the verilog folder. An example of how a test bench would look can be found in tb_example.sv.
The runner concept is very similar to that of the VHDL runner and will support running test cases in the same simulation. The main difference is that SystemVerilog has macros which can be taken advantage of. I have taken it to the level where one can use run.py to run the test bench but there is no dependency scanning so --clean
has to be used when changing something.
With the last updates the SystemVerilog support is very usable. Package imports and module instances are handled by the dependency scanning as well as including files. Dependency scanning performs verilog pre-processing to find dependencies hidden behind macro expansions such as the import of vunit_pkg hidden behind our TEST_SUITE macro. I have added a verilog user_guide and uart_tx example. I will polish it a bit more and maybe add some check_equal equivalents before thinking about merging to master.
I have pushed hidden system verilog support to master now. It is almost ready and It was just to much code to have one a branch.
Is there a list of features that are supported in VHDL but not yet supported in Systemverilog? I would be interested in helping expand the functionality of vunit for SV.
@swattor Not really features missing I suppose except it does not have as rich libraries as we have for VHDL. Also the Verilog parsing and dependency scanning is just the bare minimum. There is no caching of parse results for Verilog yet like it is for VHDL. Without caching just running run.py --list
can take seconds when you have many files where they need to be re-parsed in Python. Also the behavior of running SystemVerilog is inconsistent between ModelSim and Aldec tools since Aldec have no option to break on a $error
or $warning
.
The reason that we declare the SystemVerilog as experimental is that we do not really know how it needs to change and do not want to promise that it will not change. Also it has not been proven in real use that we know of. The VHDL part of VUnit has been used by both of us authors and many other people in many companies to automate VHDL projects consisting of hundreds of test benches. What we are sure of though is that the things that make VUnit nice for VHDL would also be nice to have for a SystemVerilog user.
If you want to help us just use VUnit with SystemVerilog, let us know how it works, what problems you run into, what you think is missing etc.
Basic support has been added so I think this issue can be closed. New feature requests for SV should be handled in dedicated issues.
All off the benefits provided by VUnit for VHDL would apply equally well to SystemVerilog. I would surely miss the VUnit features when working in SystemVerilog project. There is actually not that much work that needs to be done to add basic SystemVerilog support. Here are some work items I have identifier:
I will start prototyping this on branch.