Hi, I'm very interested in this. I'm not sure I fully understand the goal here though. UVM is all non-synthesizable code, and I thought verilator only handled synthesizable code. Is there really a goal to be able to compile and run UVM testenches with verilator?

The Verilator roadmap is towards eventual complete SystemVerilog support. It's a long road.

Complete support? So arbitrary "#" delays, X and Z, everything?

In several years, yes. Only those features needed to get to UVM are in the first major round.

Any update on the UVM support?
I am trying to run System Verilog TB with UVM and I get many parsing errors:
Error: /tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/base/uvm_version.svh:31:31: syntax error, unexpected $end, expecting TYPE-IDENTIFIER
31 | parameter string uvm_revision =
| ^
/tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/base/uvm_coreservice.svh:221:1: ... note: In file included from uvm_coreservice.svh
/tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/base/uvm_base.svh:28:37: ... note: In file included from uvm_base.svh
/tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/dpi/uvm_regex.svh:25:67: ... note: In file included from uvm_regex.svh
/tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/dpi/uvm_svcmd_dpi.svh:45:59: ... note: In file included from uvm_svcmd_dpi.svh
/tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/dpi/uvm_hdl.svh:130:159: ... note: In file included from uvm_hdl.svh
/tools/snps/vcs/Q-2020.03-SP2/etc/uvm-1.2/uvm_pkg.sv:28:17: ... note: In file included from uvm_pkg.sv

UVM support is still in progress and a lot left to do, let us know if you'd like to help.

UVM support is still in progress and a lot left to do, let us know if you'd like to help.

Hi, I am interested in helping. Where can I start learning about the things needed. I've tried running with --language 1800-2017 but am getting

%Error: ../src/my_design_0.1.0/testbench/tb_top.sv:11: Unsupported: SystemVerilog 2005 reserved word not implemented: new

Hi, @saw235 would love to have additional help on this. Given the error message I suspect you are using a very old version. Presently the parser can read in UVM code, but cannot elaborate it, so that would be the next phase requiring some work. If you run the verilator_ext_tests repository t/t_uvm_parse.pl test, and comment out the --debug-exit-uvm you can see the errors that next need to be made supported.

What is current status here?

Fundamentally the message above still applies, it can read but not elaborate, and we would welcome assistance.

There has been progress on recursive functions, and static members, so at least some of the items needed are making progress.

Hello, is it possible to have an update about Verilator/UVM integration? It is told that it should be parse-compatible but I have too much parsing errors of UVM SystemVerilog sources (on master branch). Maybe I should use an alternative development branch to get as much UVM functionalities as possible? When a complete Verilator/UVM integration is planned? Thank you in advance for your answer.

Version 5 which is in development for release later this year will do correct scheduling and fork/join. Past that, UVM can get parsed, but not evaluated, so a lot left to do, let us know if you'd like to help.

@wsnyder

I'm very interested in understanding what still needs to be accomplished here. I'm currently running the Git master HEAD:

Verilator 4.227 devel rev v4.226-17-g45d622e4

I have cloned the Verilator-patched downstream version of UVM, and have reproduced EDAPlayground's UVM 1.2 Hello World source base for testing. Issuing the following command:

verilator --cc uvm/src/uvm.sv design.sv testbench.sv -Iuvm/src --exe

currently gives:

%Error-PKGNODECL: uvm/src/base/uvm_text_tr_database.svh:135:57: Package/class 'type_id' not found, and needs to be predeclared (IEEE 1800-2017 26.3)
  135 |       uvm_text_tr_stream m_stream = uvm_text_tr_stream::type_id::create(name);
      |                                                         ^~~~~~~
                  uvm/src/base/uvm_tr_database.svh:228:10: ... note: In file included from uvm_tr_database.svh
                  uvm/src/base/uvm_links.svh:322:10: ... note: In file included from uvm_links.svh
                  uvm/src/base/uvm_packer.svh:1191:1: ... note: In file included from uvm_packer.svh
                  uvm/src/base/uvm_comparer.svh:691:1: ... note: In file included from uvm_comparer.svh
                  uvm/src/base/uvm_printer.svh:1901:1: ... note: In file included from uvm_printer.svh
                  uvm/src/base/uvm_copier.svh:208:1: ... note: In file included from uvm_copier.svh
                  uvm/src/base/uvm_field_op.svh:176:1: ... note: In file included from uvm_field_op.svh
                  uvm/src/base/uvm_policy.svh:186:1: ... note: In file included from uvm_policy.svh
                  uvm/src/base/uvm_config_db.svh:406:1: ... note: In file included from uvm_config_db.svh
                  uvm/src/base/uvm_resource_db_options.svh:108:1: ... note: In file included from uvm_resource_db_options.svh
                  uvm/src/base/uvm_resource_db.svh:380:1: ... note: In file included from uvm_resource_db.svh
                  uvm/src/base/uvm_resource_specializations.svh:197:1: ... note: In file included from uvm_resource_specializations.svh
                  uvm/src/base/uvm_resource.svh:1423:1: ... note: In file included from uvm_resource.svh
                  uvm/src/base/uvm_resource_base.svh:547:1: ... note: In file included from uvm_resource_base.svh
                  uvm/src/base/uvm_spell_chkr.svh:204:1: ... note: In file included from uvm_spell_chkr.svh
                  uvm/src/base/uvm_queue.svh:211:1: ... note: In file included from uvm_queue.svh
                  uvm/src/base/uvm_pool.svh:338:77: ... note: In file included from uvm_pool.svh
                  uvm/src/base/uvm_registry.svh:676:1: ... note: In file included from uvm_registry.svh
                  uvm/src/base/uvm_factory.svh:2107:1: ... note: In file included from uvm_factory.svh
                  uvm/src/base/uvm_object.svh:1375:1: ... note: In file included from uvm_object.svh
                  uvm/src/base/uvm_globals.svh:508:10: ... note: In file included from uvm_globals.svh
                  uvm/src/base/uvm_coreservice.svh:443:1: ... note: In file included from uvm_coreservice.svh
                  uvm/src/base/uvm_misc.svh:509:1: ... note: In file included from uvm_misc.svh
                  uvm/src/base/uvm_object_globals.svh:717:40: ... note: In file included from uvm_object_globals.svh
                  uvm/src/base/uvm_version.svh:38:1: ... note: In file included from uvm_version.svh
                  uvm/src/base/uvm_base.svh:30:38: ... note: In file included from uvm_base.svh
                  uvm/src/dpi/uvm_regex.svh:25:67: ... note: In file included from uvm_regex.svh
                  uvm/src/dpi/uvm_svcmd_dpi.svh:45:59: ... note: In file included from uvm_svcmd_dpi.svh
                  uvm/src/dpi/uvm_hdl.svh:128:93: ... note: In file included from uvm_hdl.svh
                  uvm/src/uvm_pkg.sv:28:16: ... note: In file included from uvm_pkg.sv
                  uvm/src/uvm.sv:26:1: ... note: In file included from uvm.sv
                  ... For error description see https://verilator.org/warn/PKGNODECL?v=4.227

I first want to make sure this is an expected error and I'm not just running this incorrectly.
Then, would you mind giving a brief A-to-Z of work that still needs to be done here? Thanks! :)

If you look at the verilator_ext_tests repository the https://github.com/verilator/verilator_ext_tests/blob/master/t/t_uvm_parse.pl test shows that the first parsing is working. The v3Global.opt.debugExitUvm() check in Verilator.cpp is currently exiting after that, the next step would be to move that after V3LinkDot, if you do this there's roughly 8 errors (so far). To get past those and see what's next we require at least:

• Support process class #3612
• Standalone reference to 'this' is marked as a symbol-resolution error #3248 (if you'd like to help likely the easiest)
• Class parameters support #3541

Hi! @wsnyder
Is there any update on this support of UVM? Still only can be read and can't be elaborated? Thanks!

Closer every month, but still a ways to go. As above we would like help on this effort.

Hi @wsnyder,

as many companies in the industry, we're much interested as well.
We could possibly help on this effort if that made a difference.
Many of us are of course fluent in UVM, C++ etc. but not familiar with Verilator internal code and structure.
How difficult of a ramping curve would it be?
How much time/effort is it necessary to invest, in the above conditions, to bring any real value to this great project?

The hard part is being familiar with C++ so your skills would be a great help.

@RRozak and Antmicro have been contributing greatly towards UVM, perhaps they have comments on what is in flight with them, so you don't conflict.

If you download the verilator/verilator_ext_tests repo, and run t/t_uvm_parse.pl --no-debug-exit-uvm

this will try to elaborate UVM and this gives errors, which is where we are now. I see one internal error needing debug/fixing (perhaps debug and file a bug, then try to fix?), and the big one to work on is getting process support #3612.

In addition many of the "Support..." or otherwise bugs reported here, generally, would appreciate debug and fixing

To elaborate a little bit:
We (Antmicro) are currently working on the process class support (currently figuring out the best way to distinguish which coroutine belongs to which process to be able to get correct process handles for the objects, the code is highly WIP so there is no pull request yet).

In addition we are incrementally trying to verilate UVM, we tackle the issues one by one so far so we don't have a full roadmap etc, but we do have a list of patches that remove things that verilator still does not support here (expect this branch to change with push forces, posting it here only for reference, also note that UVM in this branch is not functional, it's just a way to roughly track how far off we are - we might change this approach so also don't judge the progress by looking at that in the future :) ).

Currently, the majority (but not all) of the things we find are related to class parameters usage, the fixes we do are usually fairly self contained and regularly submitted here with PRs.

One of the other long term goals that we think is needed for UVM testbenches is constrained randomization, we have some rudimentary support for that here - it uses CRAVE and its solvers. This is also a WIP and has not been contributed here yet.

@tgorochowik thanks for commenting, and of course much appreciate your past and future efforts here. Can you comment more on where you think others might best pick up some tasks to help accelerate/off load you all?

Thanks @wsnyder, @tgorochowik, @RRozak and Antmicro,
I'll have a look at the various proposed tracks, see if I can get support from my management, and get back to you...

Progress - we're now through the first V3LinkDot link stage, and breaking later in V3Param. Anyone that wants to look at V3Param fixes to move more forward (e.g. @RRozak - since you improved that last) it would be appreciated!

Is there a page with up-to-date summary of features that are supported?

There's no summary page, individual features are bugs here. There has been a lot of progress on process classes and other enhancements, but still not ready for users.

There's only a couple of issues blocking full elaboration (yea!). I'm extending the scope of this issue to get through Verilator and into GCC.

All known blocking issues to getting UVM through to GCC have been filed, and the t_uvm_todo test passes with those issues commented out. The list of issues is:

• Support short-circuiting #487
• Support recursive functions #3267
• Task ref variables incorrectly passed #3385
• Support disable fork #4125
• Fix false INFINITELOOP on forever..mailbox.get() #4323
• Support randc #4349
• Support wait fork #4465
• Fix UVM function output width reassignment #4467
• Fix UVM assignment of event data types #4468
• Fix UVM function non-constant default arguments #4470
• Fix UVM fork..join_none local variable can't locate varref scope #4493
• Support UVM #0 ZERODLY #4494
• Support UVM waiting on local event variables #4495
• Support UVM delayed assignment inside public function/task #4496
• Fix uvm_sequencer wrong reference type #4497

@tgorochowik I'm trying to write a very simple testbench where I want to generate randomized data for a multi-input adder. Is there any progress on CR support since your March posting? Is there anything I can cherry-pick into the latest main branch to try it?
Thanks

@muzafferkal unfortunately no changes when it comes to constrained randomization since my last post. Feel free to experiment with the branch linked in my previous comment.
UVM is getting close though!

@wsnyder

I'm very interested in understanding what still needs to be accomplished here. I'm currently running the Git master HEAD:

Verilator 4.227 devel rev v4.226-17-g45d622e4

I have cloned the Verilator-patched downstream version of UVM, and have reproduced EDAPlayground's UVM 1.2 Hello World source base for testing. Issuing the following command:

verilator --cc uvm/src/uvm.sv design.sv testbench.sv -Iuvm/src --exe

currently gives:

%Error-PKGNODECL: uvm/src/base/uvm_text_tr_database.svh:135:57: Package/class 'type_id' not found, and needs to be predeclared (IEEE 1800-2017 26.3)
  135 |       uvm_text_tr_stream m_stream = uvm_text_tr_stream::type_id::create(name);
      |                                                         ^~~~~~~
                  uvm/src/base/uvm_tr_database.svh:228:10: ... note: In file included from uvm_tr_database.svh
                  ...

I first want to make sure this is an expected error and I'm not just running this incorrectly. Then, would you mind giving a brief A-to-Z of work that still needs to be done here? Thanks! :)

@benjaminmordaunt were you able to fix this? I am facing this error too, your kind help will be appreciated. Thanks!
p.s. I am working on v5.016

All the bugs listed above this that are not closed need to be closed before this will work. If you want to help, which is appreciated, please pick one of those sub issues and ask how to help.

Note you must use the verilator version of UVM under chipsalliance. Instructions will be posted when it is ready for people to use (i.e. near when above issues are resolved, and whatever other debugging finishes).

I will be updating the first comment in this issue to give current status. Here's the original first comment;

Author Name: Wilson Snyder (@wsnyder)
Original Redmine Issue: 1538 from https://www.veripool.org

Feature tracking bug.

Currently Verilator parses a subset of SystemVerilog and reports many unsupported errors at parse time.

Towards getting full language support, it is desirable that the parser handle all of UVM and support dumping this to XML. This allows downstream tools to use the full language. Any unsupported Verilation language constructs would then be reported at an error at that point.

Verilog-Perl's parser is a nearly complete starting point, with some fixes needed to handle "foo = new foo".

[This captures update to first comment here]

This issue tracks the remaining subissues that must be fixed before UVM can be converted to C++.

Note UVM is not yet supported, We request you do not file "UVM doesn't work" issues, or "How soon will UVM work" issues. Please try UVM only if you are willing to help develop the subissues mentioned.

For developers, to run UVM, see:

• t_uvm_all test, which exits early so it passes. The early exit in Verilator.cpp needs to be removed.
• t_uvm_todo test, which has commented out code in t_uvm_pkg_todo.vh so it passes. Tthe commented-out code need to be reinserted as issues are resolved,

The list of subissues remaining to be resolved:

• Support short-circuiting #487
• Task ref variables incorrectly passed #3385
• Support disable fork #4125
• Support wait fork #4465
• Fix UVM assignment of event data types #4468
• Support UVM #0 ZERODLY #4494
• Support UVM waiting on local event variables #4495
• Support UVM delayed assignment inside public function/task #4496
• Fix uvm_sequencer wrong reference type #4497
• Support library (e.g. UVM) includes #4562

Summary - copy put into updated first message in this thread.

This issue tracks the remaining subissues that must be fixed before UVM can be converted to C++. This first comment is updated periodically to summarize the most recent state.

Note UVM is not yet supported, We request you do not file "UVM doesn't work" issues, or "How soon will UVM work" issues. Please try UVM only if you are willing to help develop the subissues mentioned.

For developers, to run UVM, see:

• t_uvm_all test, which exits early so it passes. The early exit in Verilator.cpp needs to be removed.
• t_uvm_todo test, which has commented out code in t_uvm_pkg_todo.vh so it passes. Tthe commented-out code need to be reinserted as issues are resolved,

The list of subissues remaining to be resolved through compilation phase:

• Task ref variables incorrectly passed #3385
• Fix UVM assignment of event data types #4468
• Support UVM #0 ZERODLY #4494
• Support UVM waiting on local event variables #4495
• Fix uvm_sequencer wrong reference type #4497
• Fix VlProcess argument inconsistent across virtual member functions #4565
• Fix VlProcess argument breaks DPI export #4566

The list of subissues affecting usability:

• Support library (e.g. UVM) includes #4562

Completed issues (over last few months only):

• Support short-circuiting #487
• Support recursive functions #3267
• Support disable fork #4125
• Fix false INFINITELOOP on forever..mailbox.get() #4323
• Support randc #4349
• Support wait fork #4465
• Fix UVM elaboration of package dotted reference #4466
• Fix UVM function output width reassignment #4467
• Fix UVM static cast from a stream type #4469
• Fix UVM function non-constant default arguments #4470
• Fix UVM fork..join_none local variable can't locate varref scope #4493
• Support UVM delayed assignment inside public function/task #4496
• Fix compile warning on unused member function variable #4567
• Fix method narrowing conversion compiler error #4568

We have hello world! Adding run_test() hangs, but there's still code commented out due to the other issues.

----------------------------------------------------------------
Accellera:1800.2-2017:UVM:1.0

All copyright owners for this kit are listed in NOTICE.txt
All Rights Reserved Worldwide
----------------------------------------------------------------

UVM_INFO t/t_uvm_hello.v(40) @ 0: reporter [HELLO_UVM] Hello world!
*-* All Finished *-*

`define UVM_NO_DPI
`include "t_uvm_pkg_todo.vh"
// FIXME, needed because t_uvm_pkg_todo deleted macros, for this to work
// need to have a +incdir+ pointing at verilator_ext_test's submodules/uvm/src
`include "uvm_macros.svh"
import uvm_pkg::*;

class env extends uvm_env;
   function new(string name, uvm_component parent = null);
      super.new(name, parent);
   endfunction
endclass

module t;
   env environment;
   initial begin
      environment = new("env");
      `uvm_info("HELLO_UVM", "Hello world!", UVM_LOW);
      // TODO Never get a finish if add this: run_test();
      $write("*-* All Finished *-*\n");
      $finish;
   end
endmodule

Excellent Wilson, congrats to all who contributed! :-)

Hi all, a quick update about current state from us. Even though some required features are still unsupported, we managed to run a UVM testbench of a VeeR module in Verilator: chipsalliance/Cores-VeeR-EL2#131. We're now running Verilator UVM testbenches in CI in VeeR as a part of our test suite. Please note that a dedicated UVM branch is being used for now and that we run a custom Verilator build that includes the code from: #4673. More examples and information about the work towards adding UVM support can be found on our blog: https://antmicro.com/blog/2023/10/running-simple-uvm-testbenches-in-verilator/.

Very good stuff @tgorochowik, keep it up! :-)

Hi all, a quick update about current state from us. Even though some required features are still unsupported, we managed to run a UVM testbench of a VeeR module in Verilator: chipsalliance/Cores-VeeR-EL2#131. We're now running Verilator UVM testbenches in CI in VeeR as a part of our test suite. Please note that a dedicated UVM branch is being used for now and that we run a custom Verilator build that includes the code from: #4673. More examples and information about the work towards adding UVM support can be found on our blog: https://antmicro.com/blog/2023/10/running-simple-uvm-testbenches-in-verilator/.

Hi @tgorochowik,

As discussed in antmicro/verilator-verification-features-tests#493, can you please consider updating the comments on the blog (https://antmicro.com/blog/2023/10/running-simple-uvm-testbenches-in-verilator/) and the above comment to specify the specific commit from Verilator that works for UVM?

We are unable to use the latest Verilator version (which has many fixes, support, and enhancements done in the last 6 months) for SV/UVM with the patch for UVM that you mentioned with that branch. This is to avoid confusion for all.

I understand that paid support is needed for you (Antmicro) to incorporating the latest Verilator version to use with the UVM branch on repo (https://github.com/antmicro/verilator-verification-features-tests).

The current status is that both the UVM testbench and the uvm-mem testbench are failing:

• https://antmicro.github.io/verilator-verification-features-tests/log.html#s1-s15
• https://antmicro.github.io/verilator-verification-features-tests/log.html#s1-s15-t1

We are grateful for all the contributors who are supporting Verilator development, with the recent development for constraint randomization support coming in thanks to Antmicro and EU funding.

We believe that once full UVM support is up, more of the community will start using Verilator as a mainstream tool in commercial, academic, and personal projects. This will lead to more developer participation for future bug fixes and enhancements in Verilator.

I understand that full UVM support related issue/activity has been paused for the past 6 months, and we only have 6 pending issues that are not moving forward. I assume that @wsnyder and other developers contributing to UVM support are busy with bug fixes and feature enhancements for full UVM support. We are not pressuring @wsnyder to work on this immediately.

Thanks

Hi, the comment above is up to date, nothing important changed since then (in terms of running the UVM testbench).

As you can probably see the PR linked in the comment above has been merged and Veer is tested with UVM in Verilator in each commit since then. Here is the latest run as of Today: https://github.com/chipsalliance/Cores-VeeR-EL2/actions/runs/7475942249/job/20345229476

Please refer to the PR linked above for all the details on how it's run, the yml files there define the whole run (including building Verilator from sources, getting UVM and running the testbench).

To make it easier, you can try using something like act (https://github.com/nektos/act) to run the yml files locally, without the need to extract all the commands manually.

Thanks @tgorochowik for your reply,

We have reviewed the provided information and noticed a few discrepancies.

As you can probably see the PR linked in the comment above has been merged and Veer is tested with UVM in Verilator in each commit since then. Here is the latest run as of Today: https://github.com/chipsalliance/Cores-VeeR-EL2/actions/runs/7475942249/job/20345229476

Firstly, the referenced GitHub action run (https://github.com/chipsalliance/Cores-VeeR-EL2/actions/runs/7475942249/job/20345229476) was indeed executed on January 10, 2024, and not today.

Secondly, We have also checked the GitHub workflow (https://github.com/chipsalliance/Cores-VeeR-EL2/blob/main/.github/workflows/build-verilator.yml#L15) and confirmed that the Verilator version used is v5.010, which is an a year older version. The current stable release of Verilator is v5.022.

We found better way to look for Verilator and UVM working testbench example at https://antmicro.github.io/verilator-verification-features-tests/log.html#s1-s15-t1 which is failing with Verilator latest version/commit today.

We have figured out the Verilator commit feae9ca (a 6-month-old commit), which is known to work with the current-patches branch of the uvm-verilator repository.

If you have any information regarding a newer Verilator version or commit that is compatible with the current-patches branch of https://github.com/antmicro/uvm-verilator, please let us know. It will help the community to use the latest version of Verilator with more bug fixes, new feature support, and enhancements.

Thank you for your attention to this matter.

Veer is not very actively developed the last commit is from January so the last run is from January. The run I linked is the last run as of Today, what I wrote is factually correct.

My original comment above does say that we're using a custom Verilator build. It does not work with mainline Verilator at this point. I am not sure why you're inferring otherwise. If you want to use mainline and make the tests you mention work, please cherry pick this commit: antmicro@4b00952 but expect other things to break.
Mainline Verilator does not fully support UVM at this point, it's still in progress.

We're doing everything in our power to get UVM to mainline and we are continuously contributing to Verilator, both as paid support and as our internal R&D. If our priorities do not align with yours you are free to contribute to Verilator yourself.
Please kindly stop pinging me about this issue in random places. There is nothing I can do to speed this up.

@opensource-elearning FYI: with the latest fix from Krzystof, the uvm mem testbench in our verification suite (the one you asked about) is green when using current mainline Verilator

That's great, thanks for the update @tgorochowik