Include free verilog compiler

[leoheck]

Like icarus verilog

[LarsAsplund]

Some work has been done by @ehliar. Not sure about current status. Join https://gitter.im/VUnit/vunit to find out

[AlexDaniel]

Any news?

[LarsAsplund]

No, not really. This is an area where we would appreciate contributions. Have you been able to work on this @ehliar?

[feddischson]

Did someone get a response from @ehliar about his initial steps? (https://gitter.im/VUnit/vunit/archives/2016/04/27).

I am interested in having the icarus verilog support and I am willing to help.

[svenka3]

I made some attempt. I've a crude version running. However it is only skeleton as Icarus has issues around SV string methods, copy etc. I would like to support especially if there is some spec on what it takes to run a unit test under VUnit - like there is setup, loop etc. I believe it is obvious for SW folks, not so popular for HW engineers I guess. I've been hacking the unit_pkg files with those APIs - making them skeleton and uncommenting line-by-line. I feel that spoils the core functionality at some point as there are work-arounds for Icarus. Is there a doc for the VUNIT API from a developer perspective?

Thanks

[LarsAsplund]

@svenka3 Would it be possible to make your work public so that everyone interested can help out?

The starting point for our documentation is VUnit.github.io. There you'll find how to use VUnit but there is no documentation for the details needed to develop the tool. The only information we have is how to make sure that the things you've made doesn't break anything. http://vunit.github.io/contributing.html

[svenka3]

Sure, will upload. Please give me few days to do so.

[svenka3]

Quick update - I believe I now have the "loop" function ported to Icarus. Looks like Icarus support for string is minimal and hence the remaining 2 functions: setup() and search_replace() seem unlikely to run on it.

Can you please clarify what you would like to achieve via the setup()? I am sure we can find a pure Verilog way of doing it. Search-Replace - good for future maybe!

Thanks
Srini

[svenka3]

Please see: https://github.com/svenka3/vunit_icarus

Please do let me know if you see any issue in running it. As I cautioned earlier - this is heavily work in progress and not ready for release. Need some more work.

[feddischson]

@svenka3 Nice, this is a starting point.
I had a look at your example and there are probably some statements which need to be realized by Icarus to get everythink working. We could create a list of sv statements (or simple example) to get an overview of missing Icarus features.
I could also spend some time to add the icarus realization on the Python side (if you haven't done this).

@LarsAsplund What about creating a Icarus branch under https://github.com/VUnit/vunit/ where we can work on. If the branch is stable and all features are working, you can merge the changes back to your main branch. What do you think?

[LarsAsplund]

@feddischson What you should do is to follow the fork and pull request workflow explained here

[feddischson]

Ok, I've created the fork and branch, which can be found here:
https://github.com/feddischson/vunit/tree/icarus_support

I also added a folder docs/missing_icarus/missing_icarus_features.rst to track the missing icarus features.

@svenka3 I've added you as Collaborator to my fork. Would you like to integrate your extensions?

[svenka3]

Sounds good. Do you want me to copy the files to that fork? I will have limited bandwidth this week for this.

[svenka3]

@feddischson - on:

We could create a list of sv statements (or simple example) to get an overview of
missing Icarus features.

IMHO we should rather port this vunit to pure Verilog or Icarus friendly SV than look for extra features with Icarus. Maybe you are saying the same thing?

I was looking for what the setup/run() API inside VUNIT are supposed to do. Given that there is not much documentation on that (I didn't look deep enough maybe), it is a hit-and-try to port the code is what I am thinking.

[feddischson]

@svenka3 I added your files to the fork.

Regarding

 We could create a list of sv statements (or simple example) to get an overview of
   missing Icarus features.

IMHO we should rather port this vunit to pure Verilog or Icarus friendly SV than look for extra features > with Icarus. Maybe you are saying the same thing?

Both ways are possible with pros and cons.
From what I can see:
Pure Verilog solution:

• Pro: Easier to port on other simulators
• Con:
  • There will be two implementations for the same functionality.
  • If there is a new feature, it needs to be implemented in SV and V

Extension/Improvement of Icarus:

• Pro: Icarus would also benefit (because it supports more SV language features) from it
• Con:
  • It might take more time to realize the Icarus improvments

Any further pros/cons?

I think we should first try to analyze the gap and then fell a decision which way we will go.
As soon as we know how much features are missing, we can decide for the best solution.
Also a mixture between the both ways is possible.

[kraigher]

@feddischson
Regarding vunit_defines.svh everything in it except CHECK_EQUAL can be considered part of the core functionality. The CHECK_EQUAL should be moved to a separate check library which together with other convenient check-functions. The core functionality might be possible to implement in pure Verilog and but the check library might be SystemVerilog-only. That way Verilog-only simulators can still use the test-automation features of VUnit without benefiting from convenient check-functions.

Anyway why not ask icarus for improvements? It is open source after all. I made tons of bug/feature issues to GHDL before it finally could run VUnit.

@svenka3
Regarding the purpose of the core functionality setup and the pass/fail mechanism. Basically the Python part of VUnit sets a runner_cfg generic that is a string in a certain format that contains a number of fields such as the test case to run and the output path. This string needs to be parsed in setup for the HDL-part of VUnit to now which if run("test_name") if statement(s) it should go into. The pass/fail mechanism is through writing the $output_path/vunit_results file. A pass is when the simulation ends with the correct contents in vunit_results file and a fail is a (premature) simulation ending without the correct results written into vunit_results. Basically if the simulation ends before reaching cleanup it is considered a fail.

[feddischson]

@kraigher thanks

A first example is working now (with several workarounds).

I had to pass the runner_cfg via $value$plusargs because Icarus (vvp) has no option to override a verilog parameter during runtime.

A list of missing features can be found here.

[kraigher]

@feddischson How is it going?

[feddischson]

I used the branch mentioned above for a slightly larger design with around 140 test-cases.

I discovered one major thing which I need to re-write on the Python side: for each simulation, all Verilog files are compiled into one executable and then used for the simulation. This has a significant simulation speed drawback.

A better approach would be just to use the test-bench files and all dependencies of a specific test, compile that and use it for the simulation.

I will dig deeper into the VUnit structure in the next one or two weeks. I guess there is a solution via dependency_graph. The underlying structure must know which test-bench file belongs to a test-case (the file where TEST_CASE is used), and also which further files are required.

[kraigher]

Yes should be possible to compile only what is needed for each test since VUnit has the dependency graph. It has methods to get all dependencies of a node.

[kraigher]

When it is ready enough I want to set up Travis CI to run Verilog acceptance tests and examples using icarus.

[elms]

It may be worth adding a check for the version of iverilog, as I found out it doesn't work with versions before 10.2.

I checked out the branch and had a segfault (actually in ivlpp) during the compilation step of the example. When I tried with building iverilog master to debug, everything ran fine. I checked out steveicarus/iverilog tags v10_1_1 (segfaults) and v10_2 (no segfault). The packaged version that generated the segfault was 10.1 (stable), doesn't look many distros supply a newer version.

[eine]

Maybe we can create an iverilog branch with the most up to date fork, for better visibility and for multiple users to have a common place? I believe that iverilog was improved a lot in the last years, specially with regard to SV support.

[rodrigomelo9]

I am interested on that :-D any news? Or Verilator?

[umarcor]

FTR, steveicarus/iverilog#191 was implemented. According to steveicarus/iverilog#191 (comment), steveicarus/iverilog#192 is the remaining required feature for VUnit support.

[sschmitz86]

I am also interested in iverilog support. Is there a schedule for this feature ?

[LarsAsplund]

@sschmitz86 First iverilog has to do there part and I'm not sure if there is a schedule for that.

[umarcor]

@sschmitz86 see also #925.

[sschmitz86]

If is see it correct, steveicarus/iverilog#191 is already closed.
So only steveicarus/iverilog#192 is still open and the last remaining requirement, right ?

[sschmitz86]

@umarcor well , you did already answer my question above. I did not saw that ... sorry, i will ask if there is a schedule for steveicarus/iverilog#192