Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add NVC support #904

Merged
merged 3 commits into from
Feb 27, 2023
Merged

Add NVC support #904

merged 3 commits into from
Feb 27, 2023

Conversation

nickg
Copy link
Contributor

@nickg nickg commented Feb 26, 2023

This adds support for NVC, a VHDL simulator I have been developing, based on some initial work from @kraigher a few years ago. It can pass all the acceptance tests but needs the very latest master branch.

@LarsAsplund
Copy link
Collaborator

@nickg I tried to run all acceptance tests locally and ran into a few failing tests. I built nvc from a Github clone and is running under Windows:

$ nvc --version
nvc 1.9-devel (1.8.0.r116.g75c503da) (Using LLVM 15.0.7)
Copyright (C) 2011-2023 Nick Gasson
This program comes with ABSOLUTELY NO WARRANTY. This is free software, and
you are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

I looks like the problem is related to file accesses. For example,

larsa@LAPTOP-B6KUINVE MINGW64 /c/github/vunit/vunit/vhdl/check (nickg-pr-nvc)
$ python run.py "lib.tb_deprecated.Test changing checker name"

results in

** Fatal: 0ms+1: Assertion Failure: Failed to open file error.csv - name_error
Procedure ASSERT_STATUS [FILE_OPEN_STATUS, STRING]
C:\github\vunit\vunit\vhdl\logging\src\file_pkg.vhd:84
Procedure FILE_OPEN_FOR_WRITE [FILE_ID_T, STRING]
C:\github\vunit\vunit\vhdl\logging\src\file_pkg.vhd:210
Procedure INIT_LOG_FILE [LOG_HANDLER_T, STRING]
C:\github\vunit\vunit\vhdl\logging\src\log_handler_pkg-body.vhd:43
Function NEW_LOG_HANDLER [NATURAL, STRING, LOG_FORMAT_T, BOOLEAN return LOG_HANDLER_T]
C:\github\vunit\vunit\vhdl\logging\src\log_handler_pkg-body.vhd:57
Function NEW_LOG_HANDLER [STRING, LOG_FORMAT_T, BOOLEAN return LOG_HANDLER_T]
C:\github\vunit\vunit\vhdl\logging\src\log_handler_pkg-body.vhd:69
Procedure CONFIGURE_HANDLERS [LOG_HANDLER_T, LOG_HANDLER_T]
C:\github\vunit\vunit\vhdl\logging\src\log_deprecated_pkg.vhd:135
Procedure LOGGER_INIT [LOGGER_T, STRING, STRING, DEPRECATED_LOG_FORMAT_T, DEPRECATED_LOG_FORMAT_T, LOG_LEVEL_T, CHARACTER, BOOLEAN]
C:\github\vunit\vunit\vhdl\logging\src\log_deprecated_pkg.vhd:163
Procedure CHECKER_INIT [CHECKER_T, LOG_LEVEL_T, STRING, STRING, DEPRECATED_LOG_FORMAT_T, DEPRECATED_LOG_FORMAT_T, LOG_LEVEL_T, CHARACTER, BOOLEAN]
C:\github\vunit\vunit\vhdl\check\src\check_deprecated_pkg.vhd:115
Procedure CHECKER_INIT [LOG_LEVEL_T, STRING, STRING, DEPRECATED_LOG_FORMAT_T, DEPRECATED_LOG_FORMAT_T, LOG_LEVEL_T, CHARACTER, BOOLEAN]
C:\github\vunit\vunit\vhdl\check\src\check_deprecated_pkg.vhd:131
Process :tb_deprecated:test_runner
C:\github\vunit\vunit\vhdl\check\test\tb_deprecated.vhd:105
fail (P=0 S=0 F=1 T=1) lib.tb_deprecated.Test changing checker name (0.5 seconds)

The error status is name_error but the file is there.

Any idea?

@nickg
Copy link
Contributor Author

nickg commented Feb 26, 2023

I haven't tested VUnit on Windows before, I'll have a look.

@umarcor
Copy link
Member

umarcor commented Feb 26, 2023

Shall I add nvc tests to CI in a feature-branch so that @nickg can cherry-pick it?

@nickg
Copy link
Contributor Author

nickg commented Feb 26, 2023

The problem seems to be that error.csv is opened twice simultaneously which Windows doesn't allow by default. I switched to using _fsopen with shared mode in nickg/nvc@ec2d6d5322 and the test passes now. Could you try again? The status should really be MODE_ERROR not NAME_ERROR, I fixed that in the same commit.

@LarsAsplund
Copy link
Collaborator

@nickg Thanks, I will get back and give it a try this evening.

@LarsAsplund
Copy link
Collaborator

@nickg I tested your updates and now all tests are green!

I noticed one thing when testing with VHDL/Compliance-Tests though. When I enable VHDL-2019, VUnit will compile a logging package making use of call paths. That didn't seem to work so I changed master to check for simulator support with a new simulator interface method: supports_vhdl_call_paths. The base class implementation returns false and after that the call paths are excluded from nvc simulations and everything is fine. Could you rebase?

That being said, after I made the change I observed some commit messages in nvc suggesting that call paths are supported. Is that so? Something that works in Linux but not on Windows? If it is a simple fix we can take care of it now but otherwise I'm okey with merging this PR as it stands. Call path support can be added later if that is more convenient.

@nickg
Copy link
Contributor Author

nickg commented Feb 27, 2023

@LarsAsplund it should work, including on Windows, but it was only added recently so it's not been thoroughly tested. Here's the simple regression test I'm using: https://github.com/nickg/nvc/blob/master/test/regress/stdenv3.vhd

What do I need to change in order test in VHDL-2019 mode?

@nickg
Copy link
Contributor Author

nickg commented Feb 27, 2023

Do you mean this?

** Error: type of string literal cannot be determined from the surrounding context             
    > /home/nick/src/vunit/vunit/vhdl/logging/src/location_pkg-body-2019p.vhd:29               
    |                                                                                          
 29 |     write(result.file_name, "");                                                         
    |                             ^^ could be BIT_VECTOR or STRING                             
    |                                                                                          
    = Note: context contains overload WRITE [LINE, BIT_VECTOR, SIDE, WIDTH]                    
         ../lib/std.19/textio.vhdl:125                                                         
    = Note: context contains overload WRITE [LINE, STRING, SIDE, WIDTH]                        
         ../lib/std.19/textio.vhdl:131                                                         

I believe this error is correct: there is an ambiguity between those two overloads (at least GHDL also errors on the same thing). Do other simulators accept it? I think it can be fixed easily by using a qualified expression like:

diff --git a/vunit/vhdl/logging/src/location_pkg-body-2019p.vhd b/vunit/vhdl/logging/src/location_pkg-body-2019p.vhd
index 0202ce5ba333..381e9c033893 100644
--- a/vunit/vhdl/logging/src/location_pkg-body-2019p.vhd
+++ b/vunit/vhdl/logging/src/location_pkg-body-2019p.vhd
@@ -26,7 +26,7 @@ package body location_pkg is
       end if;
     end if;
 
-    write(result.file_name, "");
+    write(result.file_name, string'(""));
     return result;
   end;
 end package body;

@LarsAsplund
Copy link
Collaborator

@nickg I didn't check any deeper but you're right, that's on me. I will fix it. It works with Aldec's simulators which are the only ones we have supporting VHDL-2019. GHDL would probably fail on it as well but without 2019 support it is never exposed. I will make an update in an hour or so. I think the new supports_vhdl_call_paths method should remain though. When the standard is new we can't expect every simulator to have that feature in their first 2019 release. Can you add that method to your PR?

@nickg
Copy link
Contributor Author

nickg commented Feb 27, 2023

Sure, I just added it in 611661c

@umarcor
Copy link
Member

umarcor commented Feb 27, 2023

@LarsAsplund
Copy link
Collaborator

@nickg Good, works as expected. I've pushed the ambiguity fix to master so I need yet another rebase. After that I think we're ready to merge this PR.

@LarsAsplund LarsAsplund merged commit 3599646 into VUnit:master Feb 27, 2023
@LarsAsplund
Copy link
Collaborator

Well, no point in you making the rebase... Done. Thanks for your contribution.

@umarcor
Copy link
Member

umarcor commented Feb 27, 2023

I rebased the CI branch after the merge of this PR. Acceptance tests are all passing, but vcomponents are failing on tb_wishbone_slave.vhd. See:

=== Command used: ===

/usr/local/bin/nvc --work=vunit_lib:/src/vunit_out/nvc/libraries/vunit_lib --std=2008 --map=vunit_lib:/src/vunit_out/nvc/libraries/vunit_lib --map=osvvm:/src/vunit_out/nvc/libraries/osvvm -a /src/vunit/vhdl/verification_components/test/tb_wishbone_slave.vhd



=== Command output: ===

** Error: no matching subprogram VERBOSE [return LOG_LEVEL_T]

    > /src/vunit/vhdl/verification_components/test/tb_wishbone_slave.vhd:77

    |

 77 |     show(tb_logger, display_handler, verbose);

    |                                      ^^^^^^^

** Error: no matching subprogram VERBOSE [return LOG_LEVEL_T]

    > /src/vunit/vhdl/verification_components/test/tb_wishbone_slave.vhd:78

    |

 78 |     show(default_logger, display_handler, verbose);

    |                                           ^^^^^^^

** Error: no matching subprogram VERBOSE [return LOG_LEVEL_T]

    > /src/vunit/vhdl/verification_components/test/tb_wishbone_slave.vhd:79

    |

 79 |     show(com_logger, display_handler, verbose);

    |                                       ^^^^^^^



Compile failed

@nickg
Copy link
Contributor Author

nickg commented Feb 27, 2023

@umarcor I can reproduce it locally, I'll have a look...

@eine eine added the Tool: NVC label Feb 27, 2023
@LarsAsplund
Copy link
Collaborator

verbose is a deprecated log level that was replaced with trace. To keep backward compatibility we made verbose an alias of trace. This will be removed in v5.0.0. Meanwhile we can just replace verbose with trace. I will do that.

@LarsAsplund
Copy link
Collaborator

Updated now. Hopefully that removes the problem.

@umarcor
Copy link
Member

umarcor commented Feb 27, 2023

Rebased CI branch. Running: https://github.com/VUnit/vunit/actions/runs/4287438129

@nickg
Copy link
Contributor Author

nickg commented Feb 27, 2023

OK, I actually fixed the bug just now anyway in nickg/nvc@1c81bcc but I ran into a second error:

** Error: generate expression is not static                                                                                                                                                    
     > /home/nick/src/vunit/vunit/vhdl/verification_components/src/axi_stream_master.vhd:181                                                                                                   
     |                                                                                                                                                                                         
 181 |   axi_stream_protocol_checker_generate : if master.p_protocol_checker /= null_axi_stream_protocol_checker generate                                                                      
     |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                                                               
               0 fs - vunit_lib:com            - FAILURE - DUPLICATE ACTOR NAME ERROR.          
               0 fs - vunit_lib:com            - FAILURE - DUPLICATE ACTOR NAME ERROR.          
fail (P=21 S=0 F=62 T=513) vunit_lib.tb_axi_stream.stall_slave.test random check stall on slave (0.4 seconds)

I think I know what the problem is but it will take a while longer to fix. Perhaps you could mark that test as expected fail with NVC temporarily?

@nickg nickg deleted the pr-nvc branch February 27, 2023 22:31
@LarsAsplund
Copy link
Collaborator

Yeah, I see the same thing. Let's see what you can find.

@umarcor
Copy link
Member

umarcor commented Feb 27, 2023

All tests other than the AXI Stream VC's are green. So, that's good news! This might be last feature/bug to catch.

@nickg
Copy link
Contributor Author

nickg commented Mar 5, 2023

This is fixed on the latest master branch and all the verification_components tests pass for me now. Could you test again?

@umarcor umarcor mentioned this pull request Mar 5, 2023
@umarcor
Copy link
Member

umarcor commented Mar 5, 2023

@nickg all green! https://github.com/VUnit/vunit/actions/runs/4337431930

Please, let us know which is the first tag including these enhancements, so that we can use it as the min version to recommend to users.

@nickg
Copy link
Contributor Author

nickg commented Mar 5, 2023

I'll make a 1.9 release in a month or so but there's a few other things I want to get in first. Thanks for testing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants