v1.3.0

[Paebbels]

New Features

• Support GHDL v5.1.1.
• Shop error message from inventory.json if a previously supported version was revoked.
• Added symbolic version latest, which gets the latest released version from latest nightly build via inventory.json.

Changes

• Setup a CODEOWNERS file.

Documentation

• Documented symbolic version latest.

Unit Tests

• Reactivated tests for latest and nightly.
• Added HelloWorld example.
  Closes Add tiny test example #16.

---

Related Issues and Pull-Requests

• Get latest version from nightly #19

[ktbarrett]

Hey @Paebbels any updates on this?

[Paebbels]

@ktbarrett ufff. Did I really forget to finish this branch and merge it?

f***

I'm sorry. I'll have a look at the weekend.

[Paebbels]

Versions v1.2.0 and v1.2.1 are already published. Looks like this branch should be for a v1.3.0.

What have I done (or not done ...?) How did I got distracted from this PR when GHDL v5.1.1 was released.

[ktbarrett]

No problem, I'll look again in a week after I return from the wilderness. I think v5.0.1 solves our (pyuvm's) problem, but the latest and greatest would be nice.

[Paebbels]

Selecting latest should install v6.0.0-dev (>v5.1.1). Only selecting a specific version is limited to v5.0.1. v5.1.1 isn't selectable.

[Paebbels]

@ktbarrett there is/was a chicken/egg problem which should be fixed.

pyTooling/Actions → ghdl/ghdl → ghdl/setup-ghdl → ghdl/ghdl

I updated pyTooling/Action to improve the generated inventory.json file, which is part of every GHDL release (incl. nightly). This file is needed by this action to install GHDL properly. As a new feature of pyTooling/Actions, the latest GHDL version won't be hard coded anymore, it's now updated with every nightly release, because inventory.json contains the version number of the latest release.

[Paebbels]

@tgingold I might have reported this before (by email?), but I can't find any matching issue here or at ghdl/ghdl.

All pipelines using Windows + MSYS2 + LLVM-JIT backend are failing to finish a simulation. It reports the expected simulations outputs (here an assert statement printing "hello world"), but then the surrounding shell reports a non-zero exit code.

Example job: https://github.com/ghdl/setup-ghdl/actions/runs/18147743237/job/51652701449

There is no scripting, just purely calling GHDL in Bash:

ghdl -a --std=08 example/HelloWorld.vhdl
ghdl -e --std=08 HelloWorld
ghdl -r --std=08 HelloWorld

Generated output:

example/HelloWorld.vhdl:9:9:@10ns:(report note): Hello World
simulation stopped @10ns
Error: Process completed with exit code 127.

Any ideas?
Can you have a look?

[ktbarrett]

🎉 Thanks for the effort!

[tgingold]

@Paebbels We don't have this issue on ghdl/ghdl runners. Why is setup-ghdl special ?

[Paebbels]

@tgingold I'm not sure what's the difference causing it. Let me try to gather a list of differences for you, maybe you spot a key difference that could cause it.

I'll keep the differences to the LLVM-JIT variant. When mentioning ghdl, I refer to builds of or packages containing LLVM-JIT variants.

1. In the ghdl pipeline, ghdl is build on one VM (job) and then copied to another job and installed, where it runs GHDL's testsuite. There are 2 variants:

   1. Installation from artifact containing build results. Here a mingw64.requirements shipped within the artifact is used in xargs --no-run-if-empty -a ./install/mingw64.requirements -- pacman -S --noconfirm to restore the MSYS/MinGW64 dependencies.
   2. Installation from *.pkg.tar.zst MSYS2 package shipped via artifact to the new job. Pacman is used for installation like so: pacman -U --noconfirm pacman/*.pkg.tar.zst.

   In setup-ghdl, it downloads ghdl from GHDL release page, where the previously mentioned MSYS2 package was uploaded (unmodified) and attached as an asset to the release page. Except for how it's transfered (curl, asset, ...) it should be identical to 1.ii

2. In ghdl, GitHub Reusable Workflows (job templates) are used to execute pipeline code (e.g. Bash),
   whereas setup-ghdl uses a GitHub Action.
   Both is YAML code with embedded Bash code.

3. In ghdl pipeline, the executed testsuites are delivered with GHDL (e.g. sanity),
   whereas setup-ghdl uses a very small hello world test.
   The test uses this code:

   entity HelloWorld is
   end entity;
   
   architecture test of HelloWorld is
   begin
     process
     begin
       wait for 10 ns;
       report "Hello World" severity note;
       std.env.stop;
     end process;
   end architecture;

   Can a difference be caused by std.env.stop;?

[Paebbels]

I noticed, that setup-ghdl is used in the ghdl pipeline, to test new releases (like nightly) after uploading them as an asset, but it only triggers a version check.

Let me add code to trigger a run of testsuite sanity in the main pipeline after installation using setup-ghdl.

[Paebbels]

I enhanced the ghdl pipeline, such as setup-ghdl is used to install GHDL and then I run the sanity testsuite. All runs are good.

---

If I remove std.env.stop and replace it with wait; the problem is gone.
Is there something going on with code generation in LLVM-JIT in case of std.env.stop and LLVM in MSYS2?

The current LLVM version in MSYS2 is 21.1.1.

[tgingold]

So it looks like this is indeed a problem with llvm-jit. I will investigate.

[Paebbels]

Thanks.

Meanwhile, setup-ghdl is out and released as v1.3.0 which is supporting actual version numbers like v5.0.1 or v5.1.1 as well as symbolic versions liked latest and nightly.

All new nightly releases contain the version of the latest release in the JSON structure, so this setup action doesn't need to be updated on every new GHDL release to know what the latest official release is.