Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 10 11:52
    Sturla22 commented #713
  • Apr 10 11:49
    LarsAsplund closed #713
  • Apr 10 11:49
    LarsAsplund commented #713
  • Apr 10 11:18

    LarsAsplund on master

    Revert Sphinx version to workar… (compare)

  • Apr 10 11:16
    LarsAsplund commented #713
  • Apr 10 11:11
    LarsAsplund commented #713
  • Apr 10 09:02
    Sturla22 opened #713
  • Mar 31 22:02

    eine on images

    (compare)

  • Mar 31 22:02

    eine on master

    ci: update container registry, … (compare)

  • Mar 31 21:01

    eine on images

    ci: update container registry, … (compare)

  • Mar 30 22:07

    eine on images

    ci: update container registry, … (compare)

  • Mar 23 09:18
    rafaelnp closed #711
  • Mar 23 09:18
    rafaelnp commented #711
  • Mar 23 07:42
    eschmidscs commented #703
  • Mar 19 23:37
    smenzel commented #703
  • Mar 19 21:19

    eine on fix-axi-stream-protocol-checker

    (compare)

  • Mar 19 21:16

    eine on bump-osvvm-to-latest

    (compare)

  • Mar 19 21:10
    eine labeled #712
  • Mar 19 21:10
    eine closed #712
  • Mar 19 21:10
    eine commented #712
Lars Asplund
@LarsAsplund
@eine @suzizecat You may want to read this: https://insights.sigasi.com/tech/work-not-vhdl-library/
eine
@eine
@LarsAsplund thanks, I remember having read it, but it thought it was some stackoverflow answer...
Lars Asplund
@LarsAsplund
Actually, it should be in VUnit's error message:
        if library_name == "work":
            LOGGER.error(
                "Cannot add library named work. work is a reference to the current library. "
                "http://www.sigasi.com/content/work-not-vhdl-library"
            )
            raise RuntimeError("Illegal library name 'work'")
Julien FAUCHER
@suzizecat
@LarsAsplund @eine Thanks for the infos, I indeed learned something today !
Lars Asplund
@LarsAsplund
You're welcome
eine
@eine
That's actually neat :D
Julien FAUCHER
@suzizecat
I actually saw this message :innocent:
On a side-side-note I was wondering, is sigasi (considered as) a reference for VHDL ?
eine
@eine
That depends on what you consider "a reference". Can you specify?
Julien FAUCHER
@suzizecat
A reliable source of info that is commonly used/referred to
eine
@eine
If you are asking about canonical support/usage of the language, I would say that GHDL and OSVVM are the absolute references. Then, immediately behind, there are tools such as VUnit and Sigasi. Some of the resources/structures used in VUnit do prioritise support accross multiple vendor tools, rather than using all language features. By the same token, I would expect Sigasi to support some code found in the wild, even if it's not the best. Nonetheless, I know that people from VUnit and Sigasi do have a deep understanding of the language and are interested in it being used "correctly".
Therefore, I'd say yes Sigasi is a reliable source of info and most (if not all) their blog post are correct. However, I don't see it referenced frequently for language issues. It's rather a reference because it's the main editor supporting most of the language (including VHDL 2019).
Lars Asplund
@LarsAsplund
@suzizecat Sigasi also maintains a browsable view of the VHDL grammar which is useful if you want to dig into the details of legal VHDL. The IEEE language reference manual is not freely available from IEEE. This is something being discussed but meanwhile Sigasi can be used as a reference when it comes to the syntax description.
NanooooK
@NanooooK

@LarsAsplund I've tried to remove the output_path(runnger_cfg) but I still have issues.
I have one tb that contains two test-cases (using run("test-caseX")):

tb.test-case1
tb.test-case2

Using the python script I add generic configurations, therefore all my tests are the following:

tb.cfg1.test-case1
tb.cfg2.test-case1
tb.cfg1.test-case2
tb.cfg2.test-case2

How should I configure the logging in the VHDL to retrieve 4 different .csv, one for each test?
Using variable file_handler_tc1 : log_handler_t := new_log_handler doesn't seem to work, all logs from test-case1 are overwritten. I don't know what I'm doing wrong.

Lars Asplund
@LarsAsplund
@NanooooK You should keep output_path(runner_cfg). If you name your file output_path(runner_cfg) & "log.csv" you will get four log files named log.csv located in four different directories named something like vunit_out/tb.cfg<x>.test-case<y><hash>
eine
@eine
@vblanco20-1 :point_up: March 16, 2021 11:40 AM try gtkwave-gtk2 instead of gtkwave. Both are installed together (same MSYS2 package).
Vitaly Konovalov
@arnfol

Hi everyone! I am looking for some help with running VUnit examples with GHDL in docker container. So I did just the following:

git clone --recurse-submodules https://github.com/VUnit/vunit.git
cd vunit/examples/vhdl/
bash docker_runall.sh

And I am getting a lot of compilation errors. What am I missing? Or do I need a stable version of VUnit to run examples?

Vitaly Konovalov
@arnfol
As far as I can see the problem arises in this part:
Compiling into vunit_lib:   ../../vunit/vhdl/path/src/path.vhd
            failed
=== Command used: ===
/usr/local/bin/ghdl -a --workdir=/work/examples/vhdl/vunit_out/ghdl/libraries/vunit_lib --work=vunit_lib --std=08 -P/work/examples/vhdl/vunit_out/ghdl/libraries/vunit_lib -P/work/examples/vhdl/vunit_out/ghdl/libraries/osvvm -P/work/examples/vhdl/vunit_out/ghdl/libraries/axi_dma_lib /work/vunit/vhdl/path/src/path.vhd

=== Command output: ===
/work/vunit/vhdl/path/src/path.vhd:9:10: package "string_ops" is obsoleted by package "std_logic_1164"
use work.string_ops.all;
         ^
/work/vunit/vhdl/path/src/path.vhd:27:14: package "path" was not analysed
package body path is
             ^
/usr/local/bin/ghdl: compilation error

Compile failed
umarcor
@umarcor
@arnfol I just tried running docker_runall.sh and I didn't find any issue. Can you please try removing vunit_out subdirs and executing again?
Which is your hos OS?
NanooooK
@NanooooK
@LarsAsplund @eine Thank you, I've solved my issue.
I now have one file_handler per testbench, all logs are stored in output_path and then with python and the content of test_name_to_path_mapping.txt I can rename the logs.csv for all tests.
Vitaly Konovalov
@arnfol
@umarcor my host system is Win10 and I use Docker with WSL. Due to docker_runall.sh is a bash script I launched it from Ubuntu 18.04 WSL.
Removing vunit_out didn't help :(
Vitaly Konovalov
@arnfol

To check if there is a problem with launching from Ubuntu WSL I tried to launch the content of docker_runall.sh in powershell from the same location:

docker run --rm -t -v /c/Users/arnfo/Work/Raitek/vunit://work -w //work/examples/vhdl -e PYTHONPATH=//work ghdl/vunit:llvm-master `
    sh -c ' \
    VUNIT_SIMULATOR=ghdl; \
    for f in `find ./ -name run.py`; do \
      if [ -d "vunit_out" ]; then rm -rf vunit_out; fi; \
      python3 $f; \
    done \
'

and got the same result with compilation errors.

umarcor
@umarcor
@arnfol I think the issue might be related to how you are defining the absolute path. Let's try something simpler:
  • docker run --rm -itv /$(pwd)://work -w //work ghdl/vunit:llvm-master bash
  • Inside the container, cd examples/vhdl/array_axis_vcs and python3 run.py -v
I use /$(pwd) and //work on MSYS2. However, on WSL or Powershell you might need to use a different syntax.
Vitaly Konovalov
@arnfol

@umarcor thank you a lot for babysitting me, I really appreciate ;)

I've tried to follow your instructions and docker run --rm -itv /$(pwd)://work -w //work ghdl/vunit:llvm-master bash worked perfectly in Ubuntu WSL, no problem here with $(pwd). However, I still got compilation error

root@87d44dc84daf:/work/examples/vhdl/array_axis_vcs# python3 run.py -v
Compiling into lib:       src/fifo.vhd
                                                     passed
Compiling into lib:       src/axis_buffer.vhd
                                                     failed
=== Command used: ===
/usr/local/bin/ghdl -a --workdir=/work/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/lib --work=lib --std=08 -P/work/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/vunit_lib -P/work/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/osvvm -P/work/examples/vhdl/array_axis_vcs/vunit_out/ghdl/libraries/lib /work/examples/vhdl/array_axis_vcs/src/axis_buffer.vhd

=== Command output: ===
/work/examples/vhdl/array_axis_vcs/src/axis_buffer.vhd:43:21: entity "fifo" is obsoleted by context "ieee_std_context"
  fifo: entity work.fifo
                    ^
/usr/local/bin/ghdl: compilation error

Compile failed
Vitaly Konovalov
@arnfol

Okey, here I did a sanity check:

docker run --rm -it ghdl/ext:latest bash
root@7c42868f5b3a:/# cd /tmp/files/
root@7c42868f5b3a:/tmp/files# ghdl -a hello.vhdl
root@7c42868f5b3a:/tmp/files# ghdl -e hello_world
*libraries*:1:1:error: entity "hello_world" is obsoleted by package "textio"

^
ghdl:error: compilation error

Tried to run hello_world example with GHDL in ghdl/ext:latest image (because ghdl/vunit:llvm-master does not hove these examples) and again the same compilation error :(

Vitaly Konovalov
@arnfol

On the other hand, the example adder_tb works fine:

root@eaa0057700b0:/tmp/files# ghdl -a adder.vhdl adder_tb.vhdl
root@eaa0057700b0:/tmp/files# ghdl -e adder_tb
root@eaa0057700b0:/tmp/files# ghdl -r adder_tb
adder_tb.vhdl:54:5:@8ns:(assertion note): end of test

The difference between adder_tb and hello_world is that the latest use standard textio package. So I assume I got some problems with standard libraries?

umarcor
@umarcor
I'm thinking this might be a problem with the filesystem in WSL. Did you checkout/clone VUnit through Windows? I.e., is it located in /mnt/c inside WSL? If so, try cloning VUnit in ~ inside WSL.
There is no reason for example Hello to work but Adder to fail. I mean from a code, GHDL or VUnit point of view.
Vitaly Konovalov
@arnfol

There is no reason for example Hello to work but Adder to fail. I mean from a code, GHDL or VUnit point of view.

Well, I agree with that, however as I mentioned the Hello example does use standard libraries and GHDL is complaining about them :(

Did you checkout/clone VUnit through Windows?

Yep, I checked out VUnit to /mnt/c/..., however doing the same operation to ~ in WSL does not change anything - Docker container is launched as a separate WSL, as far as I know. It looks like the problem is not located in VUnit at all, rather in GHDL or in Docker. Do you use WSL2 or WSL1?

Bradley Harden
@bradleyharden
I've recently started using the -m tag to compile the minimal subset needed for my tests. However, I ran into an issue with it just now. I have a vendor library that defines some components, with corresponding entities in separate files. When doing a full compile, the files containing the entities are included. But when doing a minimal compile, they are not. And as a result, my test bench no longer passes.
Is this a known limitation? Or is it a bug?
I would create a minimal example, but I don't want to bother if it's a known limitation of the dependency resolver
umarcor
@umarcor

Docker container is launched as a separate WSL, as far as I know. It looks like the problem is not located in VUnit at all, rather in GHDL or in Docker.

@arnfol, the point is that the error does not make sense because it implies that textio was analysed after hello_world and doing so obsoleted hello_world. If that was the case, analysing hello.vhdl would fix it, but you just did it!
Moreover, you are not mounting/binding any directory from the host. Therefore, something seems to be wrong with the filesystem Docker is running on... it is reporting the date of the prebuilt libraries incorrectly.

Do you use WSL2 or WSL1?

I'm not using any of those. I use Docker Desktop, from an MSYS2 terminal.
How did you install docker?

Vitaly Konovalov
@arnfol

How did you install docker?

I also use Docker Desktop, installed the common way, downloaded distro from the official website

I'm not using any of those. I use Docker Desktop, from an MSYS2 terminal.

I mean what is your Docker backend? As far as I know Docker could run with WSL2 or HyperV backend. Mine is using WSL2

Here are my docker configs:
image.png
image.png
As far as I remember I haven't changed any configs after installing Docker
Vitaly Konovalov
@arnfol
Well, I've reinstalled Docker and everything works fine! @umarcor thank you a lot for your help :)
It looks like I missed a step in Docker installation - Linux kernel update package has to be installed before installing Docker.
umarcor
@umarcor
@arnfol nice! That makes full sense. In fact, that's the reason I avoided using WSL2. I'm lazy for looking into tge kernel update XD
Santi Rodriguez-Parera
@rodriguezparera
Hi, @LarsAsplund, @cmarqu, I wonder how the support for Xcelium is going ? I noticed that EDAPlayground returns this message when trying to use VUnit with Xcelium 20.09: "Vunit support for Cadence Xcelium 20.09 is not yet available." We have 19.09 at the company and we have also a fail message when running the examples (after cloning the github repository), "Trying to check out license... Xcelium_Single_Core 19.00 - Failed". So, ...does VUnit supports only up to
v19.00 right now?
umarcor
@umarcor
@rodriguezparera have a look at:
Are you trying to use Xcelium for VHDL, SV or both?
Santi Rodriguez-Parera
@rodriguezparera
I was trying to use SV at first
Santi Rodriguez-Parera
@rodriguezparera
I've seen #325 already and try the test suite
The tests don't show the License error,
502 passed, 23 warnings in 40.26s
Let me take a better look at #504 and #677
Lars Asplund
@LarsAsplund
Hello! Relatively new to the VUnit world and starting to use it in Sigasi Studio. Does anyone who is using or used VUnit with Sigasi Studio know by any chance what may be the reason all my test results from test runs (in test_output folder that VUnit creates) are being dumped in my user \AppData\Local\Temp\ folder when running the VUnit tests from Sigasi IDE? When I run tests (via run.py file) in Windows command line, this does not happen, and I do see the test results in the folder where the VUnit project resides so I think it is something with Sigasi. I thought I followed all the necessary steps for integrating Sigasi with VUnit (via Sigasi's online instructions) and even tried setting the output path via --output-path VUnit option in Sigasi preferences but still keeps sending it to the Temp folder. Let me know if you'd like more info, and appreciate any input, thanks!
@vnoelifant Looks like Sigasi fixed your issue: https://insights.sigasi.com/tech/preview/#improvements