Add support for other simulators

[LarsAsplund]

The VUnit Python runner currently support Modelsim but it's designed to support multiple simulators. What other simulators would you like to see supported? Let's have some voting.

[kraigher]

Aldec

[tomasnilefrost]

Wouldn't it be wise to look into isim? This would lower the bar to using vunit for Xilinx users without a modelsim license. I mean, both Altera and Microsemi ships with a limited version of modelsim and are already covered.

[kraigher]

@tomasnilefrost I have looked into supporting xsim which is the new name for isim when shipped with Vivado. It might be reasonable to support it in some form but there are limitations that must be handled.

A few major problems with xsim:

• It does not support setting the break severity level to other than failure such as error or warning. In vunit we have chosen to have an error as the default break level and we also support warning using the 'fail_on_warning' pragma. Maybe the user could live with only having failure as break level, when using our check_xxx functions we could ensure that they trigger a failure. I have also made a post in the Xilinx forums about this and it feels like a trivial function for them to add so you could always hope they fix it some day.
• It does not support defining custom "resolved types" and only supports std_logic_vector. There are custom resolved types defined within vunit and they would need to be worked around. Maybe there is an isomorphic relation between a std_logic_vector and such a type so that std_logic_vector could be used instead.

A few minor problems which we can work around easily are:

• A file using a package will also depend on the package body and not just the package definition as in modelsim. This would be an easy new rule to add to the dependency scanner.
• The mocking substitutions that are made in the acceptance tests such as in lang_mock.vhd are not supported since a pure function cannot call a procedure with side-effects. It might be that the mocking used by us violates the standard but is somehow still supported by modelsim.

[tomasnilefrost]

Ah, I see! Personally I haven't used xsim/isim more than sporadic a few years ago. My main idea behind the suggestion was that it could lower the bar for new users.

Perhaps it's better to start by supporting a more "compliant" simulator and use the insights from that implementation work to better support a more limited simulator without impacting the current vunit implementation extensively.

[LarsAsplund]

Aldec expressed interest in having a VUnit webinar for their users. I wouldn't want to do that webinar unless I can show VUnit with one of their simulators. Let's see if we can get an evaluation license to make this happen.

[mschiller302]

Aldec support would be HUGE. I would suggest that you can get a "free" aldec license with Lattice tools, but since the free license doesn't support VSIMSA (their command-line tool) it might not allow full testing. You should be able to use the Lattice-edition for testing vhdl based stuff though... I think you can still run .do / .tcl scripts from the Aldec Active-HDL GUI, though I don't really do that since I have the commercial Aldec license available to me here at work and thus have vsimsa...

We use Aldec for all our simulations and I'm rather excited about the VUnit tool. I've been rolling my own for quite a while, but VUnit looks better than any of my hodge-podge collection of testbench tools.

[kraigher]

@mschiller302 We have immediate plans to add Aldec support.

One problem has been that unlike ModelSim there is no "free" license available that supports the command line and tcl-batch flow (vsimsa). Even though you could use just the VHDL-part of VUnit to much benefit there is much more value in also having the VUnit Python runner flow.

One idea we had was to take a 30-day evaluation license for the "full" simulator and use that to implement the Aldec driver. This is unsatisfactory since we need to support and maintain the implementation also after 30-days and being authors of a test-framework it would be ironical if we released parts of it untested.

We have had contact with Aldec representatives about being able to get access to a "full" Aldec license for free or at a very low cost as a "tool provider". Since you are interested I would consider taking the 30-day evaluation to get the support up and running for you right now and hope that the "tool provider license" materializes afterwards.

[LarsAsplund]

@mschiller302 There are licenses issues to be handled but we do not expect any major problems with the actual implementation. We did a quick prototype in October and it seems pretty straight-forward. Modelsim and Aldec interfaces are very similar. The VHDL code was also updated at that time to compile with Aldec as well.

[mschiller302]

I'm meeting with Aldec folks in 2 weeks I'll point them to this website to see if they can offer any support to your efforts [if they hear customers asking for it they may be more comfortable giving y'all a license]. Our software team already uses Jenkins, so I'm expecting to be able to convince the folks responsible for that serverfarm to install a free version of modelsim and Aldec active-hdl and then I can start trying the VUnit tool on some of my existing testbenches. I think I'm 1-2 months from giving it a shot. [Right this second I'm in the critical path, so I need to get some progress done on a HW/SW ICD and bringup a new FPGA board before trying anything speculative on the company dime.... and with two small children time outside of work is even more limited...] If things go well and I can show some progress, I might be able to justify some limited testing of any changes to the VUnit code using our commercial Active-HDL licenses. But it'll get dicey with management if I'm not showing progress on my actual project....

That being said I can probably also try the tool using Altera's Modelsim free license. Though that could dicey on some of my Xilinx designs and/or if I need dual language support (not offered in Altera's free license)... Speaking of which have you done any hacks to allow dual language designs? Some of Altera's IP only have Verilog models, I've seen that for Xilinx IP as well. Guess I could always pre-compile the Verilog library.....

Aldec tried to copy much of the .do/.tcl interface from Modelsim right down to the command name vsim being aliased to asim... Usually there is just a minor issue with running modelsim scripts.

-- Matthew Schiller -- Senior Design Engineer @ Garmin

[PerePala]

I haven't tried yet, but being able to work with GHDL would definitely be a plus! GHDL is a nice, free simulator...

[LarsAsplund]

@PerePala That would be the second vote. VUnit and GHDL was also discussed in this thread

[LarsAsplund]

@mschiller302 Very good, we have good connections with the European side of Aldec so I'm not worried that this will be any problem in the long run. However, I'd appreciate if you would share your interest in VUnit with them and that we can use you as a backup for testing of new releases.

We currently have some Verilog support, see issue #8.

[kraigher]

@mschiller302 In my project we pre-compile FPGA vendor IP:s into a separate library and add them to vunit with 'add_external_library'. Typically the FPGA vendor IP:s are recompiled much more seldom and outside of the modify-compile-test loop. We also have limited support for compiling Verilog files (only without dependency scanning).

In the long term we have the ambition to add full Verilog / SystemVerilog support since VUnit concepts and Python-automation would lend itself to those languages as well. Currently we have focused on VHDL only since that is what we use at work.

I will download an Aldec evaluation license and add support for it as soon I find the time so that you can try it out.

[kraigher]

@PerePala One problem with GHDL is that it does not allow setting top level generics from the command line. We rely on this feature quite a lot to pass information from the Python-runner to the test bench. We could try to contact the author of GHDL and see if this feature could be implemented. We would need to pass top level generic values to the elaboration stage from command line.

Update: Just being able to set 'string' generics would cover our basic needs. Having support for integer, boolean and real would be nice though since it is used by some of our examples.

[LarsAsplund]

@kraigher I had a discussion with one of the GHDL maintainers here. I'll point him to this thread.

[PerePala]

On 02/19/2015 04:59 PM, kraigher wrote:

@PerePala https://github.com/PerePala One problem with GHDL is that it does not allow setting top level generics from the command line. We rely on this feature quite a lot to pass information from the Python-runner to the test bench. We could try to contact the author of GHDL and see if this feature could be implemented.

— Reply to this email directly or view it on GitHub https://github.com/LarsAsplund/vunit/issues/10#issuecomment-75077320.

Ok, let's see if it is possible to implement this feature! It would be nice to have a full free testing chain.

[kraigher]

@PerePala @LarsAsplund I have made a separate issue for GHDL (Add GHDL simulator support #24) listing the limitations that are currently blocking us. I suggest GHDL specific discussions continue there.

[kraigher]

@PerePala We have successfully added support for GHDL on the ghdl branch. It can run all our acceptance tests now. It only works with GHDL built from source from today basically. In the future the changes and bugfixes we needed will have gone into an official binary release of GHDL. Anyway if you have the ability to build GHDL from source you can use VUnit with it from the ghdl branch. I have ran it on Ubuntu Linux 14.04 LTS using the LLVM backend.

[LarsAsplund]

I will close this since we have separate issues for Aldec and nvc

[kraigher]

@mschiller302 We now have support for both Active-HDL and Riviera-PRO.