Description Update .editorconfig with settings for Ada files. Indent style and indent size values are the one that are currently used by the GHDL project.

(This PR aims to prevent editor with .editorconfig plugin to force the default tab indentation)

While trying to update the Verilator package in MSYS2 (which is ~8 months behind), I found that compilation would fail.

In order to keep better track of this type of regressions, this PR adds MSYS2 testing to CI: https://github.com/verilator/verilator/actions/runs/411990309. A PKGBUILD recipe is added, which is similar to the upstream but builds the sources surrounding it, instead of downloading a tarball. Then, in one CI job a package is built and uploaded as an artifact. In a second job, the artifact is installed and tested, similarly to how any user would do in a clean environment.

GitHub Action msys2/setup-msys2 is used for setting up MSYS2 and for caching installed packages.

Currently, Linux jobs are failing because I need to add myself to the contributors list properly. However, this PR does not modify those at all.

The current build error on MSYS2 is the following:

../V3Os.cpp:353:31: error: 'WEXITSTATUS' was not declared in this scope; did you mean 'PNTSTATUS'?
  353 |         const int exit_code = WEXITSTATUS(ret);
      |                               ^~~~~~~~~~~
      |                               PNTSTATUS
make[2]: *** [../Makefile_obj:293: V3Os.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/d/a/verilator/verilator/msys2/src/build-x86_64-w64-mingw32/src/obj_opt'
make[1]: *** [Makefile:60: ../bin/verilator_bin] Error 2
make[1]: Leaving directory '/d/a/verilator/verilator/msys2/src/build-x86_64-w64-mingw32/src'
make: *** [Makefile:222: verilator_exe] Error 2

This PR is just an "idea"... It enables the TRNG module for the UP5KDemo processor template.

For the records: The TRNG uses latches (!) and combinatorial loops (!). I know that both constructs are a bit "delicate" when it comes to FPGAs... So maybe it is a good idea to add the TRNG to check GHDL-yosys can handle such constructs.

@umarcor what do you think? Btw, do you know if there's an option to get a "hardware utilization by entity" report from yosys?

The idea comes from a thread in the German mikrocontroller.net forum where someone has problems with latches and GHDL/yosys. Here is the google translated thread: https://www-mikrocontroller-net.translate.goog/topic/528149?_x_tr_sl=de&_x_tr_tl=en&_x_tr_hl=de

edit I have tested the bitstream. The TRNG works! ✔️

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

This PR merges eine/tip into this repository.

By the way, tip/README.md is enhanced, to add info about the Context, the Composite Action version, and Advanced/complex use cases.

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

Add a new job template to publish unit test results in junit XML format via GH Action dorny/test-reporter to GitHubs API displaying an auto generated markdown file in list of jobs executed in a pipeline.

This PR fixes #8.
Depends on #11

This adds the Apache License, 2.0 headers and license texts.

Fixes #9.

This adds a simple pull request template.

We use everywhere explicit and full names, except for the job Params.

I suggest to rename it to Parameters.

I think a user can still call the job Params in his workflow, but the template would have a full name.

/cc @umarcor

This PR merges eine/tip into this repository.

By the way, tip/README.md is enhanced, to add info about the Context, the Composite Action version, and Advanced/complex use cases.

This PR merges eine/tip into this repository.

By the way, tip/README.md is enhanced, to add info about the Context, the Composite Action version, and Advanced/complex use cases.

The most popular open source VHDL verification projects are cocotb, OSVVM and UVVM, along with VUnit. As discussed in larsasplund.github.io/github-facts, there are some philosophical differences between them: OSVVM and UVVM are defined as "VHDL verification methodologies", cocotb is for (Python) co-routine co-simulation, and VUnit is a Python-aided framework of HDL utilities. Naturally, there are some overlapping capabilities because all of them provide basic features such as logging and building/simulation. Therefore, methodologies can be seen as bundles of utilities (frameworks), and some users might refer to using the VUnit runner as a methodology. Nonetheless, it is in the DNA of VUnit to be non-intrusive and allow users to pick features one by one, including reusing the methodologies they are used to.

Currently, it is possible to use OSVVM utilities/libraries in a VUnit environment. Although there are still some corner cases to fix (#754, #767, #768), it is usable already. In fact, some of VUnit's features do depend on OSVVM's core. However, it is currently not possible to use the OSVVM methodology as-is within VUnit. The OSVVM methodology uses top-level entities without generics or ports, and the entrypoints are VHDL configurations. Meanwhile, VUnit needs a top-level generic of type string in order to pass data from Python to VHDL.

Most simulators do support calling a configuration instead of an entity as the primary simulation unit. It should, therefore, be trivial to support OSVVM's configurations as entrypoints in VUnit. I am unsure about VUnit's parser supporting configurations in the parser and dependency scanning features; but that should not be the main challenge anyway.

The main challenge we need to address is that passing generics to VHDL Configurations is not supported in the language. If that was possible, the runner string might be forwarded to the entiy within the configuration. For the next revision, we might propose enhancements in this regard, since revisiting the limitations of configurations is one of the expected areas to work on. Nevertheless, that will/would take several months or years until made available in simulators.

Yesterday, I had a meeting with @JimLewis and he let me know that he's been thinking about implementing some mechanism for passing data between the TCL scripts (.pro files) and the VHDL testbenches. We talked about .ini, .yml and .json, and I suggested to use the latter because there is a JSON reader library available already: Paebbels/JSON-for-VHDL. In fact, JSON-for-VHDL is submoduled in VUnit, in order to pass very complex generics to the testbench.

I believe this is a good oportunity to document the syntax of VUnit's runner generic, make a public API from it, write a data model and provide multiple reader/writer implementations. @JimLewis said he did not put much thought into the data model yet, but he would be willing to include integration with VUnit into the scope when he works on it. Maybe there is no need for him to write a VHDL solution from scratch and it can be based on JSON-for-VHDL + VUnit's runner package.

Enhance VUnit's simulator interfaces to support writing runner (CLI) arguments to a file or to an envvar

Currently, VUnit's runner expects to receive an string, which Python passes as a top-level generic. Actually, there is no limitation in VHDL for using an alternative method. The generic might be a path, and users might read the file in the testbench before passing it to the functions from the runner package. By the same token, the generic might point to a JSON file, and users might convert that to the string syntax expected by the runner. Hence, the main challenge is that VUnit's Python simulator interfaces do not support writing runner parameters to a file.

Well, that is not 100% correct: when GHDL is used, option ghdl_e prevents running the simulation and instead writes all the CLI arguments in a JSON file (#606): https://github.com/VUnit/vunit/blob/7879504ba6a97be82137199e8819f770e4017681/vunit/sim_if/ghdl.py#L303-L322 That is used for building a design once (and generating an executable binary if the simulator is based on a compile & link model) and then executing it multiple times for co-simulation purposes: https://github.com/VUnit/cosim/tree/master/examples/buffer. Therefore, we might want to generalise this to all the simulator interfaces and make it optional to specify the name/location of the JSON file.

Similarly, we might want to support passing runner arguments through an environment variable. In the context of integrating VUnit and cocotb, one of the requirements is specifying environment variables per test/testbench. That's because cocotb bootstraps an independent Python instance, and the UUT is the design; so data needs to be passed through the filesystem or envvars. In fact, this is a requested feature: #708. If we used the same mechanism for the runner, cocotb might re-implement VUnit's runner package in Python (which is "just" 1K lines of VHDL code for 100% compatibility). I believe that would allow to plug cocotb's regression management. The remaining functionality would be for VUnit to "discover" the test cases before executing the simulations.

So, we might have an enumeration option to decide passing the runner string as a top-level generic, as an environment variable or as a file. Taking VHDL 2019 features into account, OSVVM and VUnit might end up using the envvar approach indeed.

Enhance JSON-for-VHDL

The current implementation of JSON-for-VHDL is functional and synthesisable, but not optimal for simulation. Some years ago, @Paebbels and @LarsAsplund discussed about writing an alternative implementation for simulation only, which would have less constraints and better performance. They also talked about using VHDL 2019 features. I don't remember if using those was a requirement for the optimised simulation-only implementation, or whether that could be done with VHDL 2008.

If we are to use JSON for sharing configuration parameters between VUnit's Python or OSVVM's TCL and VHDL, I guess we would make JSON-for-VHDL a prioritary dependency in the ecosystem.

Co-simulation

The run package might be enhanced for getting the data from a foreign environment. By encapsulating the interaction with the "runner configuration model" in a protected type, we might provide various implementations. For instance, the VHDL testbench might query a remote service which tests to run, and where to push the results.

Terminology: configurations

OSVVM uses VHDL configurations for composing the test harness and the test cases. At the same time, VUnit use the term "configuration" for referring to a set of values for top-level generics. So, in Python users can generate multiple sets of parameters for each testbench/testcase. That is not very conflictive yet because VHDL configurations are not used much in the VUnit ecosystem. However, if we are to improve the integration of OSVVM and VUnit, we might want to reconsider the naming.

/cc @Paebbels @JimLewis @ktbarrett @jwprice100

The most popular open source VHDL verification projects are cocotb, OSVVM and UVVM, along with VUnit. As discussed in larsasplund.github.io/github-facts, there are some philosophical differences between them: OSVVM and UVVM are defined as "VHDL verification methodologies", cocotb is for (Python) co-routine co-simulation, and VUnit is a Python-aided framework of HDL utilities. Naturally, there are some overlapping capabilities because all of them provide basic features such as logging and building/simulation. Therefore, methodologies can be seen as bundles of utilities (frameworks), and some users might refer to using the VUnit runner as a methodology. Nonetheless, it is in the DNA of VUnit to be non-intrusive and allow users to pick features one by one, including reusing the methodologies they are used to.

Currently, it is possible to use OSVVM utilities/libraries in a VUnit environment. Although there are still some corner cases to fix (#754, #767, #768), it is usable already. In fact, some of VUnit's features do depend on OSVVM's core. However, it is currently not possible to use the OSVVM methodology as-is within VUnit. The OSVVM methodology uses top-level entities without generics or ports, and the entrypoints are VHDL configurations. Meanwhile, VUnit needs a top-level generic of type string in order to pass data from Python to VHDL.

Most simulators do support calling a configuration instead of an entity as the primary simulation unit. It should, therefore, be trivial to support OSVVM's configurations as entrypoints in VUnit. I am unsure about VUnit's parser supporting configurations in the parser and dependency scanning features; but that should not be the main challenge anyway.

The main challenge we need to address is that passing generics to VHDL Configurations is not supported in the language. If that was possible, the runner string might be forwarded to the entiy within the configuration. For the next revision, we might propose enhancements in this regard, since revisiting the limitations of configurations is one of the expected areas to work on. Nevertheless, that will/would take several months or years until made available in simulators.

Yesterday, I had a meeting with @JimLewis and he let me know that he's been thinking about implementing some mechanism for passing data between the TCL scripts (.pro files) and the VHDL testbenches. We talked about .ini, .yml and .json, and I suggested to use the latter because there is a JSON reader library available already: Paebbels/JSON-for-VHDL. In fact, JSON-for-VHDL is submoduled in VUnit, in order to pass very complex generics to the testbench.

I believe this is a good oportunity to document the syntax of VUnit's runner generic, make a public API from it, write a data model and provide multiple reader/writer implementations. @JimLewis said he did not put much thought into the data model yet, but he would be willing to include integration with VUnit into the scope when he works on it. Maybe there is no need for him to write a VHDL solution from scratch and it can be based on JSON-for-VHDL + VUnit's runner package.

Enhance VUnit's simulator interfaces to support writing runner (CLI) arguments to a file or to an envvar

Currently, VUnit's runner expects to receive an string, which Python passes as a top-level generic. Actually, there is no limitation in VHDL for using an alternative method. The generic might be a path, and users might read the file in the testbench before passing it to the functions from the runner package. By the same token, the generic might point to a JSON file, and users might convert that to the string syntax expected by the runner. Hence, the main challenge is that VUnit's Python simulator interfaces do not support writing runner parameters to a file.

Well, that is not 100% correct: when GHDL is used, option ghdl_e prevents running the simulation and instead writes all the CLI arguments in a JSON file (#606): https://github.com/VUnit/vunit/blob/7879504ba6a97be82137199e8819f770e4017681/vunit/sim_if/ghdl.py#L303-L322 That is used for building a design once (and generating an executable binary if the simulator is based on a compile & link model) and then executing it multiple times for co-simulation purposes: https://github.com/VUnit/cosim/tree/master/examples/buffer. Therefore, we might want to generalise this to all the simulator interfaces and make it optional to specify the name/location of the JSON file.

Similarly, we might want to support passing runner arguments through an environment variable. In the context of integrating VUnit and cocotb, one of the requirements is specifying environment variables per test/testbench. That's because cocotb bootstraps an independent Python instance, and the UUT is the design; so data needs to be passed through the filesystem or envvars. In fact, this is a requested feature: #708. If we used the same mechanism for the runner, cocotb might re-implement VUnit's runner package in Python (which is "just" 1K lines of VHDL code for 100% compatibility). I believe that would allow to plug cocotb's regression management. The remaining functionality would be for VUnit to "discover" the test cases before executing the simulations.

So, we might have an enumeration option to decide passing the runner string as a top-level generic, as an environment variable or as a file. Taking VHDL 2019 features into account, OSVVM and VUnit might end up using the envvar approach indeed.

Enhance JSON-for-VHDL

The current implementation of JSON-for-VHDL is functional and synthesisable, but not optimal for simulation. Some years ago, @Paebbels and @LarsAsplund discussed about writing an alternative implementation for simulation only, which would have less constraints and better performance. They also talked about using VHDL 2019 features. I don't remember if using those was a requirement for the optimised simulation-only implementation, or whether that could be done with VHDL 2008.

If we are to use JSON for sharing configuration parameters between VUnit's Python or OSVVM's TCL and VHDL, I guess we would make JSON-for-VHDL a prioritary dependency in the ecosystem.

Co-simulation

The run package might be enhanced for getting the data from a foreign environment. By encapsulating the interaction with the "runner configuration model" in a protected type, we might provide various implementations. For instance, the VHDL testbench might query a remote service which tests to run, and where to push the results.

Terminology: configurations

OSVVM uses VHDL configurations for composing the test harness and the test cases. At the same time, VUnit use the term "configuration" for referring to a set of values for top-level generics. So, in Python users can generate multiple sets of parameters for each testbench/testcase. That is not very conflictive yet because VHDL configurations are not used much in the VUnit ecosystem. However, if we are to improve the integration of OSVVM and VUnit, we might want to reconsider the naming.

/cc @Paebbels @JimLewis @ktbarrett @jwprice100

The most popular open source VHDL verification projects are cocotb, OSVVM and UVVM, along with VUnit. As discussed in larsasplund.github.io/github-facts, there are some philosophical differences between them: OSVVM and UVVM are defined as "VHDL verification methodologies", cocotb is for (Python) co-routine co-simulation, and VUnit is a Python-aided framework of HDL utilities. Naturally, there are some overlapping capabilities because all of them provide basic features such as logging and building/simulation. Therefore, methodologies can be seen as bundles of utilities (frameworks), and some users might refer to using the VUnit runner as a methodology. Nonetheless, it is in the DNA of VUnit to be non-intrusive and allow users to pick features one by one, including reusing the methodologies they are used to.

Currently, it is possible to use OSVVM utilities/libraries in a VUnit environment. Although there are still some corner cases to fix (#754, #767, #768), it is usable already. In fact, some of VUnit's features do depend on OSVVM's core. However, it is currently not possible to use the OSVVM methodology as-is within VUnit. The OSVVM methodology uses top-level entities without generics or ports, and the entrypoints are VHDL configurations. Meanwhile, VUnit needs a top-level generic of type string in order to pass data from Python to VHDL.

Most simulators do support calling a configuration instead of an entity as the primary simulation unit. It should, therefore, be trivial to support OSVVM's configurations as entrypoints in VUnit. I am unsure about VUnit's parser supporting configurations in the parser and dependency scanning features; but that should not be the main challenge anyway.

The main challenge we need to address is that passing generics to VHDL Configurations is not supported in the language. If that was possible, the runner string might be forwarded to the entiy within the configuration. For the next revision, we might propose enhancements in this regard, since revisiting the limitations of configurations is one of the expected areas to work on. Nevertheless, that will/would take several months or years until made available in simulators.

Yesterday, I had a meeting with @JimLewis and he let me know that he's been thinking about implementing some mechanism for passing data between the TCL scripts (.pro files) and the VHDL testbenches. We talked about .ini, .yml and .json, and I suggested to use the latter because there is a JSON reader library available already: Paebbels/JSON-for-VHDL. In fact, JSON-for-VHDL is submoduled in VUnit, in order to pass very complex generics to the testbench.

I believe this is a good oportunity to document the syntax of VUnit's runner generic, make a public API from it, write a data model and provide multiple reader/writer implementations. @JimLewis said he did not put much thought into the data model yet, but he would be willing to include integration with VUnit into the scope when he works on it. Maybe there is no need for him to write a VHDL solution from scratch and it can be based on JSON-for-VHDL + VUnit's runner package.

Enhance VUnit's simulator interfaces to support writing runner (CLI) arguments to a file or to an envvar

Currently, VUnit's runner expects to receive an string, which Python passes as a top-level generic. Actually, there is no limitation in VHDL for using an alternative method. The generic might be a path, and users might read the file in the testbench before passing it to the functions from the runner package. By the same token, the generic might point to a JSON file, and users might convert that to the string syntax expected by the runner. Hence, the main challenge is that VUnit's Python simulator interfaces do not support writing runner parameters to a file.

Well, that is not 100% correct: when GHDL is used, option ghdl_e prevents running the simulation and instead writes all the CLI arguments in a JSON file (#606): https://github.com/VUnit/vunit/blob/7879504ba6a97be82137199e8819f770e4017681/vunit/sim_if/ghdl.py#L303-L322 That is used for building a design once (and generating an executable binary if the simulator is based on a compile & link model) and then executing it multiple times for co-simulation purposes: https://github.com/VUnit/cosim/tree/master/examples/buffer. Therefore, we might want to generalise this to all the simulator interfaces and make it optional to specify the name/location of the JSON file.

Similarly, we might want to support passing runner arguments through an environment variable. In the context of integrating VUnit and cocotb, one of the requirements is specifying environment variables per test/testbench. That's because cocotb bootstraps an independent Python instance, and the UUT is the design; so data needs to be passed through the filesystem or envvars. In fact, this is a requested feature: #708. If we used the same mechanism for the runner, cocotb might re-implement VUnit's runner package in Python (which is "just" 1K lines of VHDL code for 100% compatibility). I believe that would allow to plug cocotb's regression management. The remaining functionality would be for VUnit to "discover" the test cases before executing the simulations.

So, we might have an enumeration option to decide passing the runner string as a top-level generic, as an environment variable or as a file. Taking VHDL 2019 features into account, OSVVM and VUnit might end up using the envvar approach indeed.

Enhance JSON-for-VHDL

The current implementation of JSON-for-VHDL is functional and synthesisable, but not optimal for simulation. Some years ago, @Paebbels and @LarsAsplund discussed about writing an alternative implementation for simulation only, which would have less constraints and better performance. They also talked about using VHDL 2019 features. I don't remember if using those was a requirement for the optimised simulation-only implementation, or whether that could be done with VHDL 2008.

If we are to use JSON for sharing configuration parameters between VUnit's Python or OSVVM's TCL and VHDL, I guess we would make JSON-for-VHDL a prioritary dependency in the ecosystem.

Co-simulation

The run package might be enhanced for getting the data from a foreign environment. By encapsulating the interaction with the "runner configuration model" in a protected type, we might provide various implementations. For instance, the VHDL testbench might query a remote service which tests to run, and where to push the results.

Terminology: configurations

OSVVM uses VHDL configurations for composing the test harness and the test cases. At the same time, VUnit use the term "configuration" for referring to a set of values for top-level generics. So, in Python users can generate multiple sets of parameters for each testbench/testcase. That is not very conflictive yet because VHDL configurations are not used much in the VUnit ecosystem. However, if we are to improve the integration of OSVVM and VUnit, we might want to reconsider the naming.

/cc @Paebbels @JimLewis @ktbarrett @jwprice100