ghdl/ghdl

VHDL 2008/93/87 simulator

This directory contains the sources of GHDL, the open-source analyzer, compiler, simulator and (experimental) synthesizer for VHDL, a Hardware Description Language (HDL). GHDL is not an interpreter: it allows you to analyse and elaborate sources for generating machine code from your design. Native program execution is the only way for high speed simulation.

Main features

Full support for the 1987, 1993, 2002 versions of the IEEE 1076 VHDL standard, and partial for the 2008 and 2019 revisions.

Partial support of PSL.

By using a code generator (LLVM, GCC or, x86_64/i386 only, a built-in one), it is much faster than any interpreted simulator. It can handle very large designs, such as leon3/grlib.

GHDL runs on GNU/Linux, Windows and macOS; on x86, x86_64, armv6/armv7/aarch32, aarch64 and ppc64. You can freely download nightly assets, use OCI images (aka Docker/Podman containers), or try building it on your own machine (see 'Getting GHDL' below).

Can write waveforms to GHW, VCD or FST files. Combined with a GUI-based waveform viewer and a good text editor, GHDL is a very powerful tool for writing, testing and simulating your code.

Co-simulation with foreign applications is supported through Verilog Procedural Interface (VPI) and/or VHPIDIRECT. See ghdl.github.io/ghdl-cosim.

Can synthesize arbitrarily complex VHDL designs into a VHDL 1993 netlist, which can be implicitly or explicitly used in open source or vendor synthesis frameworks.

Supported third party projects: Yosys (through ghdl-yosys-plugin), cocotb (through the VPI interface), OSVVM, UVVM, VUnit, ... (see ghdl/extended-tests).

GHDL is free software:

• 
• available at ghdl.github.io/ghdl.
• Some of the runtime libraries, are under different terms; see the individual source files for details.

Getting GHDL

• Pre-built packages:
  • GHDL is available through the default package manager on most distributions: Debian/Ubuntu, Fedora, Arch Linux, MSYS2, etc.
  • After each succesful CI run, nightly tarballs/zipfiles for Ubuntu and Windows (MSYS2) are updated.
  • For using GHDL in CI, setup-ghdl-ci is provided. It is a GitHub Action (see github.com/features/actions) to setup GHDL in just 3 lines.
• You may use containers from ghdl/docker or hdl/containers, in case your didn't find a suitable release.
• Build GHDL yourself! See ghdl.github.io/ghdl: Building GHDL.

Project structure

Regular users

• The CLI tool allows analysis, compilation, simulation and (experimental) synthesis for generating VHDL 1993 netlists. It is written in Ada and C, and three different backends are supported, which are sometimes named ghdl_mcode, ghdl_gcc and ghdl_llvm. This is the entrypoint for most users.

• [experimental] ghdl-yosys-plugin is the integration of GHDL as a frontend plugin module for Yosys Open SYnthesis Suite, which uses the libghdl library (built with --enable-synth).

• ghdl-ls (part of pyGHDL, see below) implements Language Server Protocol (LSP) in Python. VHDL analysis features provided by GHDL are accessed through libghdl. This can be integrated in text editors or IDES, such as, Vim, Emacs, Atom or Visual Studio Code. See ghdl/ghdl-language-server.

  • vscode-client is an extension for Visual Studio Code (VSC) to provide language support for VHDL by interfacing ghdl-ls.

Advanced users

• libghdl is a shared library that includes a subset of the regular features plus some features to be used by extension tools (i.e. pyGHDL). This is built along with the regular GHDL and it supports both non-synthesisable and synthesisable code. Nonetheless, this is not for users, but for tools built on top of the core. When configured along with --enable-synth, this shared library includes synthesis features too.

• pyGHDL is a Python interface to libghdl. Currently, it is only used by ghdl-ls; however, it can be useful for advanced users which are willing to build Python utilities based on GHDL. There is work in progress for binding libghdl to pyVHDLModel (see pyGHDL.dom).

• [deprecated] ghdl_simul, which supports interpreted simulation, is available for historical reasons and for development/debugging only. It is very slow compared to the 'regular' compiled simulation and not all the features are supported.

ghdl's Issues

GHDL makes me swap

Hi !
After the previous bug here, I tried to recreate the issue. Unfortunately, something worst happened ! My system swaps whenever I start a simulation now.
I am on commit 19793a9 with mcode backend.

As I am unable to join some code archive to this issue, I'll send them to you by email ... There are 2: idct and vector, both output of AUGH.

The ghdl command I tried is:

$ /home/path/to/ghdl/ghdl-mcode/bin/ghdl -c -v *.vhd -r tb

And this leads to a huge system swap. Next, I tried it with gdb. idct stopped immediately with this :

$ gdb --args /home/path/to/ghdl/... and all my vhds etc.
Linking in memory

Program received signal SIGSEGV, Segmentation fault.
0x000000000053bc93 in binary_file.gen_8 (b=0) at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/binary_file.adb:368
368       Cur_Sect.Data (Cur_Sect.Pc) := B;
(gdb) bt
#0  0x000000000053bc93 in binary_file.gen_8 (b=0) at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/binary_file.adb:368
#1  0x0000000000559f8f in ortho_code.dwarf.finish () at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/ortho_code-dwarf.adb:409
#2  0x000000000056315c in ortho_code.x86.emits.finish () at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/ortho_code-x86-emits.adb:3253
#3  0x0000000000565db7 in ortho_code.x86.abi.finish () at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/ortho_code-x86-abi.adb:682
#4  0x00000000004bb043 in ortho_mcode.finish () at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/ortho_mcode.adb:719
#5  0x000000000055beed in ortho_jit.link (status=false) at /home/bourgeal/local/opt/ghdl-build/src/ortho/mcode/ortho_jit.adb:62
#6  0x00000000005f8be1 in ghdlrun.run () at /home/bourgeal/local/opt/ghdl-build/src/ghdldrv/ghdlrun.adb:575
#7  0x00000000005fd708 in ghdlcomp.perform_action (cmd=..., args=...) at /home/bourgeal/local/opt/ghdl-build/src/ghdldrv/ghdlcomp.adb:246
#8  0x00000000005fbe83 in ghdlmain.main () at /home/bourgeal/local/opt/ghdl-build/src/ghdldrv/ghdlmain.adb:342
#9  0x00000000004bb38b in ghdl_jit () at /home/bourgeal/local/opt/ghdl-build/src/ghdldrv/ghdl_jit.adb:34

The second (vector) swapped and was killed by my kernel without gdb complaining.

$ /home/path/to/ghdl/ghdl-mcode/bin/ghdl --version
GHDL 0.34dev (20151126) [Dunoon edition]
 Compiled with GNAT Version: 4.6
 mcode code generator
Written by Tristan Gingold.

Copyright (C) 2003 - 2015 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux sequoia 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u3 x86_64 GNU/Linux

Exeeeding 2**31

ISSUE

What should a simulator do if we add 230 + 230?

Particularly since the language specifies the range of integer to be the minimum supported

GHDL crashes with the following:

c:\tools\ghdl-0.33\bin\ghdl.exe:error: overflow detected
c:\tools\ghdl-0.33\bin\ghdl.exe:error: simulation failed

Other potential behavior

I have seen other behavior that allows the integer to quietly roll over. The nice side to this is that it returns control to the user program for handling the numbers

Test case

integer_max_val.txt

Impact

In weighted distributions (DistInt), I check to see that the sum is non-decreasing. This makes it easy to check for either a negative number or roll-over, and hence, do some sensible error reporting. OTOH, having the tool crash will communicate that the user did something wrong.

Oh how I wish we had conditional compilation for the testbenches that allowed me to test for simulator name.

Stack overflow (or erroneous memory access)

Hi !

I got some issue when simulating VHDL produced by an HLS tool (AUGH). I can repeat the error from where I simulates but I was unable to make it happen again when concatenating files in one directory to create a tar archive. However, here is what ghdl tells me:

/home/bourgeal/local/opt/ghdl-mcode/bin/ghdl -c --workdir=work -v ../vhd/idct.d/vhdl/*.vhd ./src/*.vhd -r tb
Linking in memory

******************** GHDL Bug occured ****************************
Please report this bug on https://github.com/tgingold/ghdl/issues
GHDL release: GHDL 0.34dev (20151126) [Dunoon edition]
Compiled with GNAT Version: 4.6
In directory: /home/bourgeal/repo/augh_testfiles/dft/
Command line:
/home/bourgeal/local/opt/ghdl-mcode/bin/ghdl -c --workdir=work -v ../vhd/idct.d/vhdl/add_163.vhd ../vhd/idct.d/vhdl/add_165.vhd ../vhd/idct.d/vhdl/add_166.vhd ../vhd/idct.d/vhdl/add_167.vhd ../vhd/idct.d/vhdl/add_168.vhd ../vhd/idct.d/vhdl/add_169.vhd ../vhd/idct.d/vhdl/add_170.vhd ../vhd/idct.d/vhdl/add_171.vhd ../vhd/idct.d/vhdl/add_172.vhd ../vhd/idct.d/vhdl/add_173.vhd ../vhd/idct.d/vhdl/add_174.vhd ../vhd/idct.d/vhdl/add_175.vhd ../vhd/idct.d/vhdl/add_176.vhd ../vhd/idct.d/vhdl/add_177.vhd ../vhd/idct.d/vhdl/add_178.vhd ../vhd/idct.d/vhdl/add_179.vhd ../vhd/idct.d/vhdl/add_180.vhd ../vhd/idct.d/vhdl/add_181.vhd ../vhd/idct.d/vhdl/add_182.vhd ../vhd/idct.d/vhdl/add_183.vhd ../vhd/idct.d/vhdl/add_184.vhd ../vhd/idct.d/vhdl/add_191.vhd ../vhd/idct.d/vhdl/add_194.vhd ../vhd/idct.d/vhdl/add_205.vhd ../vhd/idct.d/vhdl/add_206.vhd ../vhd/idct.d/vhdl/add_210.vhd ../vhd/idct.d/vhdl/add_211.vhd ../vhd/idct.d/vhdl/add_212.vhd ../vhd/idct.d/vhdl/add_226.vhd ../vhd/idct.d/vhdl/add_235.vhd ../vhd/idct.d/vhdl/add_236.vhd ../vhd/idct.d/vhdl/add_254.vhd ../vhd/idct.d/vhdl/add_255.vhd ../vhd/idct.d/vhdl/add_276.vhd ../vhd/idct.d/vhdl/add_277.vhd ../vhd/idct.d/vhdl/add_295.vhd ../vhd/idct.d/vhdl/add_296.vhd ../vhd/idct.d/vhdl/add_314.vhd ../vhd/idct.d/vhdl/add_315.vhd ../vhd/idct.d/vhdl/add_323.vhd ../vhd/idct.d/vhdl/add_338.vhd ../vhd/idct.d/vhdl/add_350.vhd ../vhd/idct.d/vhdl/add_382.vhd ../vhd/idct.d/vhdl/add_390.vhd ../vhd/idct.d/vhdl/add_393.vhd ../vhd/idct.d/vhdl/add_419.vhd ../vhd/idct.d/vhdl/add_420.vhd ../vhd/idct.d/vhdl/add_430.vhd ../vhd/idct.d/vhdl/add_466.vhd ../vhd/idct.d/vhdl/add_474.vhd ../vhd/idct.d/vhdl/add_483.vhd ../vhd/idct.d/vhdl/add_487.vhd ../vhd/idct.d/vhdl/add_508.vhd ../vhd/idct.d/vhdl/add_516.vhd ../vhd/idct.d/vhdl/add_537.vhd ../vhd/idct.d/vhdl/add_552.vhd ../vhd/idct.d/vhdl/add_564.vhd ../vhd/idct.d/vhdl/add_570.vhd ../vhd/idct.d/vhdl/add_600.vhd ../vhd/idct.d/vhdl/add_601.vhd ../vhd/idct.d/vhdl/add_602.vhd ../vhd/idct.d/vhdl/cmp_164.vhd ../vhd/idct.d/vhdl/cmp_202.vhd ../vhd/idct.d/vhdl/cmp_203.vhd ../vhd/idct.d/vhdl/cmp_204.vhd ../vhd/idct.d/vhdl/cmp_324.vhd ../vhd/idct.d/vhdl/cmp_325.vhd ../vhd/idct.d/vhdl/cmp_392.vhd ../vhd/idct.d/vhdl/cmp_396.vhd ../vhd/idct.d/vhdl/cmp_398.vhd ../vhd/idct.d/vhdl/cmp_400.vhd ../vhd/idct.d/vhdl/cmp_402.vhd ../vhd/idct.d/vhdl/cmp_404.vhd ../vhd/idct.d/vhdl/cmp_406.vhd ../vhd/idct.d/vhdl/cmp_408.vhd ../vhd/idct.d/vhdl/cmp_410.vhd ../vhd/idct.d/vhdl/cmp_411.vhd ../vhd/idct.d/vhdl/cmp_412.vhd ../vhd/idct.d/vhdl/cmp_413.vhd ../vhd/idct.d/vhdl/fsm_23.vhd ../vhd/idct.d/vhdl/input_split0.vhd ../vhd/idct.d/vhdl/input_split1.vhd ../vhd/idct.d/vhdl/mul_189.vhd ../vhd/idct.d/vhdl/mul_190.vhd ../vhd/idct.d/vhdl/mul_192.vhd ../vhd/idct.d/vhdl/mul_193.vhd ../vhd/idct.d/vhdl/mul_195.vhd ../vhd/idct.d/vhdl/mul_196.vhd ../vhd/idct.d/vhdl/mul_198.vhd ../vhd/idct.d/vhdl/mul_199.vhd ../vhd/idct.d/vhdl/mul_215.vhd ../vhd/idct.d/vhdl/mul_216.vhd ../vhd/idct.d/vhdl/mul_218.vhd ../vhd/idct.d/vhdl/mul_219.vhd ../vhd/idct.d/vhdl/mul_223.vhd ../vhd/idct.d/vhdl/mul_230.vhd ../vhd/idct.d/vhdl/mul_328.vhd ../vhd/idct.d/vhdl/mul_331.vhd ../vhd/idct.d/vhdl/mul_341.vhd ../vhd/idct.d/vhdl/mul_344.vhd ../vhd/idct.d/vhdl/mul_353.vhd ../vhd/idct.d/vhdl/mul_357.vhd ../vhd/idct.d/vhdl/mul_365.vhd ../vhd/idct.d/vhdl/mul_368.vhd ../vhd/idct.d/vhdl/mul_373.vhd ../vhd/idct.d/vhdl/mul_376.vhd ../vhd/idct.d/vhdl/mul_383.vhd ../vhd/idct.d/vhdl/mul_416.vhd ../vhd/idct.d/vhdl/mul_442.vhd ../vhd/idct.d/vhdl/mul_445.vhd ../vhd/idct.d/vhdl/mul_447.vhd ../vhd/idct.d/vhdl/mul_448.vhd ../vhd/idct.d/vhdl/mul_456.vhd ../vhd/idct.d/vhdl/mul_457.vhd ../vhd/idct.d/vhdl/mul_460.vhd ../vhd/idct.d/vhdl/mul_469.vhd ../vhd/idct.d/vhdl/mul_477.vhd ../vhd/idct.d/vhdl/mul_492.vhd ../vhd/idct.d/vhdl/mul_495.vhd ../vhd/idct.d/vhdl/mul_499.vhd ../vhd/idct.d/vhdl/mul_502.vhd ../vhd/idct.d/vhdl/mul_511.vhd ../vhd/idct.d/vhdl/mul_520.vhd ../vhd/idct.d/vhdl/mul_524.vhd ../vhd/idct.d/vhdl/mul_527.vhd ../vhd/idct.d/vhdl/mul_531.vhd ../vhd/idct.d/vhdl/mul_534.vhd ../vhd/idct.d/vhdl/mul_540.vhd ../vhd/idct.d/vhdl/mul_543.vhd ../vhd/idct.d/vhdl/mul_547.vhd ../vhd/idct.d/vhdl/mul_556.vhd ../vhd/idct.d/vhdl/mul_559.vhd ../vhd/idct.d/vhdl/mul_560.vhd ../vhd/idct.d/vhdl/mul_561.vhd ../vhd/idct.d/vhdl/mul_565.vhd ../vhd/idct.d/vhdl/mul_566.vhd ../vhd/idct.d/vhdl/mul_573.vhd ../vhd/idct.d/vhdl/mul_577.vhd ../vhd/idct.d/vhdl/mul_578.vhd ../vhd/idct.d/vhdl/mul_579.vhd ../vhd/idct.d/vhdl/mul_589.vhd ../vhd/idct.d/vhdl/mul_592.vhd ../vhd/idct.d/vhdl/mul_594.vhd ../vhd/idct.d/vhdl/mul_595.vhd ../vhd/idct.d/vhdl/mul_605.vhd ../vhd/idct.d/vhdl/muxb_162.vhd ../vhd/idct.d/vhdl/muxb_201.vhd ../vhd/idct.d/vhdl/muxb_263.vhd ../vhd/idct.d/vhdl/muxb_265.vhd ../vhd/idct.d/vhdl/muxb_322.vhd ../vhd/idct.d/vhdl/output_split0.vhd ../vhd/idct.d/vhdl/output_split1.vhd ../vhd/idct.d/vhdl/output_split2.vhd ../vhd/idct.d/vhdl/output_split3.vhd ../vhd/idct.d/vhdl/output_split4.vhd ../vhd/idct.d/vhdl/output_split5.vhd ../vhd/idct.d/vhdl/output_split6.vhd ../vhd/idct.d/vhdl/output_split7.vhd ../vhd/idct.d/vhdl/sub_157.vhd ../vhd/idct.d/vhdl/sub_159.vhd ../vhd/idct.d/vhdl/sub_160.vhd ../vhd/idct.d/vhdl/sub_185.vhd ../vhd/idct.d/vhdl/sub_186.vhd ../vhd/idct.d/vhdl/sub_187.vhd ../vhd/idct.d/vhdl/sub_188.vhd ../vhd/idct.d/vhdl/sub_197.vhd ../vhd/idct.d/vhdl/sub_200.vhd ../vhd/idct.d/vhdl/sub_207.vhd ../vhd/idct.d/vhdl/sub_208.vhd ../vhd/idct.d/vhdl/sub_209.vhd ../vhd/idct.d/vhdl/sub_213.vhd ../vhd/idct.d/vhdl/sub_214.vhd ../vhd/idct.d/vhdl/sub_217.vhd ../vhd/idct.d/vhdl/sub_220.vhd ../vhd/idct.d/vhdl/sub_227.vhd ../vhd/idct.d/vhdl/sub_243.vhd ../vhd/idct.d/vhdl/sub_262.vhd ../vhd/idct.d/vhdl/sub_284.vhd ../vhd/idct.d/vhdl/sub_303.vhd ../vhd/idct.d/vhdl/sub_332.vhd ../vhd/idct.d/vhdl/sub_337.vhd ../vhd/idct.d/vhdl/sub_345.vhd ../vhd/idct.d/vhdl/sub_354.vhd ../vhd/idct.d/vhdl/sub_362.vhd ../vhd/idct.d/vhdl/sub_369.vhd ../vhd/idct.d/vhdl/sub_370.vhd ../vhd/idct.d/vhdl/sub_377.vhd ../vhd/idct.d/vhdl/sub_391.vhd ../vhd/idct.d/vhdl/sub_429.vhd ../vhd/idct.d/vhdl/sub_437.vhd ../vhd/idct.d/vhdl/sub_446.vhd ../vhd/idct.d/vhdl/sub_449.vhd ../vhd/idct.d/vhdl/sub_461.vhd ../vhd/idct.d/vhdl/sub_478.vhd ../vhd/idct.d/vhdl/sub_484.vhd ../vhd/idct.d/vhdl/sub_488.vhd ../vhd/idct.d/vhdl/sub_489.vhd ../vhd/idct.d/vhdl/sub_496.vhd ../vhd/idct.d/vhdl/sub_503.vhd ../vhd/idct.d/vhdl/sub_517.vhd ../vhd/idct.d/vhdl/sub_521.vhd ../vhd/idct.d/vhdl/sub_528.vhd ../vhd/idct.d/vhdl/sub_544.vhd ../vhd/idct.d/vhdl/sub_553.vhd ../vhd/idct.d/vhdl/sub_562.vhd ../vhd/idct.d/vhdl/sub_563.vhd ../vhd/idct.d/vhdl/sub_567.vhd ../vhd/idct.d/vhdl/sub_574.vhd ../vhd/idct.d/vhdl/sub_580.vhd ../vhd/idct.d/vhdl/sub_585.vhd ../vhd/idct.d/vhdl/sub_586.vhd ../vhd/idct.d/vhdl/sub_593.vhd ../vhd/idct.d/vhdl/sub_596.vhd ../vhd/idct.d/vhdl/sub_599.vhd ../vhd/idct.d/vhdl/top.vhd ./src/assert_uut.vhd ./src/cp3_test.vhd ./src/fsm.vhd ./src/pkg_tb.vhd ./src/prog.vhd ./src/sync_ram.vhd ./src/tb.vhd -r tb
Exception STORAGE_ERROR raised
Exception information:
Exception name: STORAGE_ERROR
Message: stack overflow (or erroneous memory access)
Call stack traceback locations:
0x2aeec4f9519e 0x53bb51 0x559d19 0x562ee6 0x565b41 0x4baf79 0x55bc77 0x5f8663 0x5fd18a 0x5fb905 0x4bb2c1 0x408b4f 0x2aeec4f81eab 0x408137
******************************************************************

I tried to copy every source file into one single directory and use ghdl gain and then > no error :/

$ uname -a
Linux sequoia 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u3 x86_64 GNU/Linux

Tell me if you need mode info !

How to build ghdl minus libraries?

Hi Tristan

I'm attempting to cross native build ghdl with gcc backend (Cygwin build, Mingw host/target), and make errors when trying to build the std/ieee libraries. In order to work around this temporarily, I'd like to omit everything library related so make/make install completes to give me an executable, and then try compiling the libraries in Windows using a batch file similar to the mcode winbuild.bat, to at least check the executable works. I'm a configure/make newbie, so I was wondering if you have any advice.

BTW, I've successfully built from source the following configurations:
GHDL Mcode under windows
Cygwin native build of GHDL with GCC backend.
Cross native build of GCC without GHDL included

Many thanks
Ian

Type Real: Write, Read, Write produces a different number

Issue

While we expect floating point to be handled differently on different machines and different tools. OTOH, when working with a single tool, one would expect the number to be relatively stable. I was checking out some of the file writing capability of OSVVM. I would write out a coverage database file, read it back in, and write it back out. Then have a separate function that compares the two files, expecting them to be equal.

Unfortunately something in GHDL is causing it to produce a different number.

Test Case

fp_write_read_issue.txt

Observations

Other simulators look like they may be rounding while printing real numbers.

Impact

Medium. This impacts the validation of anything that needs to print using real numbers.

Really slow analyzing of memories with initialisations

I am finding that GHDL is VERY slow analyzing some VHDL memory files, that I populate with values via the VHDL file. It takes minutes on a 2.7GHz Core i7 to analyze each 64K x 9-bit memory.

To reproduce, type make cpu_test using the following:

gardners/gs4502b@f3fd553

Paul.

ghdl: unknown option '-Wl,' for command '-e'

I am getting this error, while linking C object file to vhdl binary.
ghdl: unknown option '-Wl,' for command '-e'

Another crash report

The attached code causes an internal error crash. While fixing the compile-time errors stops the crashing, I am inclined to think compilers should not crash regardless of input, correct or otherwise. The installed software is GHDL 0.33 (Dunoon edition) running on a current version of Ubuntu 14.04 LTS. The VHDL file may or may not cause a development version to crash.

I'm not pushing, but when is the next scheduled release of GHDL? While I have other things I can do, the other GHDL issue I reported (other than the coding error) is a bit of a show-stopper for me.

The files were deflated with zip.

Cheers
John

Exception raised by faulty VHDL code.

I did some experiments on custom defined attributes and uncovered an exception. See my attached reproducer for details.

I'm not sure if my code contains correct VHDL, so I just want to report an abnormal program exit.

bugreport_attribute.vhdl

Addendum:

1. The errors for 'image(...) can be solved by using (i+1 to i+1) on the left side.
2. My code is not correct. VHDL allows only _type_mark_s in attribute declarations.

Is is possible to compile the git-hash or date into the development version?

This is a feature request.

I compiled GHDL again and saw that the embedded date of 0.34dev is not the compile date. I think it would be nice for bug reporting to know the exact git-commit from which GHDL was compiled. So you can track if one reports bugs on a none up-to-date version.

How could it be solved?
GCC knows -D to pass defines into the compiler. The makefile and the Windows PoSH script could assemble a define based on:

• the short git-hash of HEAD
• the commit date of HEAD
• the current git branch
• the current date
• other data?

This should only be included in development builds.

Example:
GHDL 0.34dev - build from branch 'paebbels/master' (4742afe63) - 04.01.2015

Regards
Patrick

TYPES.INTERNAL_ERROR is raised if overlapping physical units are declared.

I made an error by defineing overlapping physical units. I tried to declare an angle (degree, minute, second). Unfortunately, GHDL handled my mistake with an exception instead of an error message.

This code should reproduce it:

type T_ANGLE is range INTEGER'range units
  sec;
  min = 60 sec;
  deg = 60 min;
end unit;

Issue 1

Using INTEGER'range causes an exception. Using INTEGER'low to INTEGER'high works as expected. My mistake was to write the range keyword in front of the INTEGER'range. Never the less, I think the error could be handled as an message instead of an exception :).

When I corrected my code I get an error saying T_ANGLE cannot be defined from another type. I don't see the problem, but I assume it's caused by the LRM (2008).

Issue 2:

I think my code collides with seconds and minutes from type TIME.

Example:

subtype T_PHASE is T_ANGLE range -360 deg to 360 deg;
constant NormalizedPhase : T_PHASE := 90 deg;
constant PhaseAsFactor : REAL := real(NormalizedPhase / 1 sec) / 1296000.0;

Reported error:

no declaration for "sec"

If I refactorsec to second in the physical type declaration and in the calculation, GHDL finds the correct value and operator overloads.

My question is: If I write sec, GHDL should report 2 possible secondary units found, shouldn't it? If reusing secondary units is a problem, shouldn't GHDL report this while declaration?
..... on the other hand if one doesn't use both types in the same package or entity the unit could be uniquely resolved ....

That's now up to you ... but something is wierd with my example and GHDL's reactions :)

GHDL 0.34dev - build date 2016.01.20

Integration of Tool Libraries in Regular Installation Flow & Alternative User Target Directory

Please, consider:

• to integrate the compilation of the third-party tool libraries into the regular installation flow by providing additional configure options like:
  • --tool-altera-quartusii=DIR compile Quartus II simulation libs.
  • --tool-xilinx-ise=DIR compile ISE simulation libs.
  • --tool-xilinx-vivado=DIR compile Vivado simulation libs.
  • --tool-osvvm=DIR compile OSVVM libs.
  • --tool-vunit=DIR compile VUnit libs.
• to place the system-wide tool libraries together with the installation into PREFIX/$libdirsuffix/tools, and
• to apply the [https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html](XDG Base Directory Specification) and allow users to compile their private tool libraries into a path searched by GHDL, e.g., $XDG_DATA_HOME/ghdl/lib/tools with a default of .local/share/ghdl/lib/tools.

universal integer bound must be numeric literal or attribute using 93 and 02

bug.vhd:

package pkg is
  procedure proc(s : string);
end package;

package body pkg is
  procedure proc(s : string) is
  begin
    for i in 0 to s'length - 1 loop
    end loop;
  end procedure;
end package body;

console output:

> ghdl -a --std=93 bug.vhd 
bug.vhd:8:16: universal integer bound must be numeric literal or attribute
ghdl: compilation error
> ghdl -a --std=02 bug.vhd 
bug.vhd:8:16:warning: universal integer bound must be numeric literal or attribute
> ghdl -a --std=08 bug.vhd 
> 

The about code works well in other simulators using all VHDL standards. Does it have to be an error? There are lot of such code out there.

Error compiling

Hi,

I'm attempting to compile ghdl on 32bit Linux, but am getting an error.
All goes well until:

gnatmake -o ghdl_mcode -aI./src -aI./src/vhdl -aI./src/psl -aI./src/vhdl/translate -aI./src/ghdldrv -aI./src/grt -aI./src/ortho -aI./src/ortho/mcode -gnaty3befhkmr -gnatwae -aO. -gnatf -gnat05 -g -gnata ghdl_jit.adb -bargs -E -largs memsegs_c.o chkstk.o  jumps.o times.o grt-cbinding.o grt-cvpi.o fstapi.o lz4.o fastlz.o -ldl -lm -Wl,--version-script=./src/grt/grt.ver -Wl,--export-dynamic
gcc-4.6 -c -I./ -I./src -I./src/vhdl -I./src/psl -I./src/vhdl/translate -I./src/ghdldrv -I./src/grt -I./src/ortho -I./src/ortho/mcode -gnaty3befhkmr -gnatwae -gnatf -gnat05 -g -gnata -I- /home/wbooth/git/ghdl/src/grt/grt-lib.adb
grt-lib.ads:26:09: warning: no entities of "Rtis" are referenced
gnatmake: "/home/wbooth/git/ghdl/src/grt/grt-lib.adb" compilation error
make: *** [ghdl_mcode] Error 4

My system reports:
Linux netbook 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:31:23 UTC 2014 i686 i686 i686 GNU/Linux

Any advice on this would be appreciated.

Cheers

deb package has not gcc dependency

I've just installed the 0.33 dep package (jessie, amd64) on a brand new Debian installation. It looks like gcc is no dependency of the ghdl package.

Support to evaluate PSL endpoints in VHDL code

GHDL already supports the PSL endpoint statement, which triggers at the last cycle of a sequence which was hit. However, you only can evaluate the endpoint in PSL code. In other simulators it is possible to read the value of the endpoint in VHDL code like this:

-- psl endpoint e_test is {req; not(grant); grant}@rising_edge(clk);

process is
begin
  wait until e_test;
  report "e_test hit";
  wait;
end process;

You can find an other example here: http://www.cvcblr.com/blog/?p=810

I don't know, if evaluating PSL endpoints in VHDL is defined in the PSL standard, but the tools that I now (Modelsim/Questa) support that. I will try on edaplayground, if Riviera also supports that, but I think it does. In the IEEE PSL standard endpoint was replaced by the ended() function, which is similar. But GHDL don't supports any PSL functions, so it would be a more easy way to enhance the already supported endpoint statement.

Generated process statement crashes with

Hi there,
I got the following message from ghdl while simulating a process created by a generate statement:

******************** GHDL Bug occured ****************************
Please report this bug on https://github.com/tgingold/ghdl/issues
GHDL release: GHDL 0.34dev (20151126) [Dunoon edition]
Compiled with GNAT Version: GPL 2015 (20150428-49)
In directory: C:\Projekte\test
Command line:
C:\Projekte\ghdl-dev\bin\ghdl.exe --elab-run --std=08 --work=lib --workdir=C:\Pr
ojekte\test\vunit_out\ghdl\libraries\lib -PC:\Projekte\test\vunit_out\ghdl\libra
ries\vunit_lib -PC:\Projekte\test\vunit_out\ghdl\libraries\lib test_tb beh -grun
ner_cfg=enabled_test_cases : test1,output path : C::/Projekte/test/vunit_out/tes
ts/lib.test_tb.test1/,active python runner : true --assert-level=error
Exception ORTHO_CODE.SYNTAX_ERROR raised
Exception information:
Exception name: ORTHO_CODE.SYNTAX_ERROR
Message: ortho_code-exprs.adb:461

I attached the source code for the vunit run. If you change the string in line 37 to a value without i every thing is fine. I also stumbled on some other issues arround this code with Program_Error raised but I cannot reproduce them yet.

test_tb.vhd.txt
run.py.txt

Error while compiling

I am getting the following error while compiling my design
Vhpi_Package.vhdl:5:10: package "utility_package" is obsoleted by package "std_logic_1164"

gnatlink error on Windows: win32.c:99: undefined reference to `_imp__StackWalk64@36'

I tried to compile GHDL on Windows to reproduce issue #2 with the latest version built from git sources. The compilation executes until gnatbind and exits with the following error message:

gnatbind -aID:\git\GitHub\ghdl\dist\mcode\windows -aID:\git\GitHub\ghdl\src  aID:\git\GitHub\ghdl\src\ghdldrv -aID:\git\GitHub\ghdl\src\psl -aID:\git\GitHub\ghdl\src\grt -aID:\git\GitHub\ghdl\src\ortho -aID:\git\GitHub\ghdl\src\ortho\mcode -aID:\git\GitHub\ghdl\src\vhdl -aID:\git\GitHub\ghdl\src\vhdl\translate -x ghdl_jit.ali
gnatlink ghdl_jit.ali -O -g -o ghdl.exe grt-cbinding.o clock.o grt-cvpi.o memsegs_c.o win32.o -Wl,--stack,8404992
win32.o: In function `get_bt_from_context':
D:/git/GitHub/ghdl/src/grt/config/win32.c:99: undefined reference to `_imp__StackWalk64@36'
collect2.exe: error: ld returned 1 exit status
gnatlink: error when calling C:\Tools\GNAT\2015\bin\gcc.exe

The compilation was called with this line:

.\winbuild.ps1 -Clean -Compile

Built environment:

OS:       Windows 7 Enterprise - German - x86-64
Shell:    PowerShell 4.0
Compiler: GNAT GPL 2015 (20150428-49)`

Using an alias to a protected type's method causes a GHDL exception.

I have a shared variable in VHDL-2008, which is a protected type. To offer a common interface for all language versions, I'm using aliases to hide the shared variable name in the call to the method.

Declaring the alias is no problem, but the usage causes a crash.

See my attached reproducer and the embedded issue report for more details.

bugreport_aliasprotected.vhdl.txt

--ieee option

What has become of this option ?
When invoking, for example :
ghdl -a --ieee=synopsis 220model.vhd
i get :
ghdl: unknown option '--ieee=synopsis' for command '-a'
I'm using ghdl-0.33 on Mac OS 10.9 :

ghdl --version
GHDL 0.33 (20150921) [Dunoon edition]
Compiled with GNAT Version: GPL 2015 (20150428-49)
llvm code generator

Dependancy

Hi,

It seems that libedit-dev is missing in the list of dependancies.

gnatbind -aI./src/ortho/llvm -aI./src/ortho -aI./src -aI./src/vhdl -aI./src/psl -aI./src/vhdl/translate -aI./src/ghdldrv -aI./src/grt -aI./src/ortho -aI./src/ortho/llvm -aO. -E -x ortho_code_main.ali
gnatlink ortho_code_main.ali -o ghdl1-llvm -g llvm-cbindings.o --LINK=clang++ -L/usr/lib/llvm-3.5/lib -lLLVMLTO -lLLVMObjCARCOpts -lLLVMLinker -lLLVMipo -lLLVMVectorize -lLLVMBitWriter -lLLVMIRReader -lLLVMAsmParser -lLLVMR600CodeGen -lLLVMR600Desc -lLLVMR600Info -lLLVMR600AsmPrinter -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSystemZAsmPrinter -lLLVMHexagonCodeGen -lLLVMHexagonAsmPrinter -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMAArch64Disassembler -lLLVMAArch64CodeGen -lLLVMAArch64AsmParser -lLLVMAArch64Desc -lLLVMAArch64Info -lLLVMAArch64AsmPrinter -lLLVMAArch64Utils -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcDisassembler -lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMSparcAsmPrinter -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMLineEditor -lLLVMMCAnalysis -lLLVMMCDisassembler -lLLVMInstrumentation -lLLVMInterpreter -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMProfileData -lLLVMMCJIT -lLLVMTarget -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMExecutionEngine -lLLVMMC -lLLVMCore -lLLVMSupport -lz -lpthread -lffi -ledit -ltinfo -ldl -lm
clang: warning: argument unused during compilation: '-shared-libgcc'
/usr/bin/ld: cannot find -ledit
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gnatlink: error when calling /usr/bin/clang++
gnatmake: *** link failed.
src/ortho/llvm/Makefile:11: recipe for target 'ghdl1-llvm' failed
make[1]: *** [ghdl1-llvm] Error 4
make[1]: Leaving directory '/work/bourgeal/local/opt/ghdl'
Makefile:220: recipe for target 'ghdl1-llvm' failed
make: *** [ghdl1-llvm] Error 2

The dependancies I already installed:

Package: llvm-dev                        
State: installed
Version: 1:3.5-25

Package: gnat                            
State: installed
Version: 4.9

System:

Linux sequoia 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u1 x86_64 GNU/Linux

GHDL Bug occured: trans-chap4.adb:306

Dear all,

ghdl crashed with the following message:

******************** GHDL Bug occured ****************************
Please report this bug on https://github.com/tgingold/ghdl/issues
GHDL release: GHDL 0.34dev (20151126) [Dunoon edition]
Compiled with GNAT Version: 5.2.1
In directory: /home/pim/git/bug_report/
Command line:
/usr/local/bin/ghdl1-llvm -P/usr/local/lib/ghdl/v93/std/ -P/usr/local/lib/ghdl/v93/ieee/ -c -o test.o test.vhd
Exception SYSTEM.ASSERTIONS.ASSERT_FAILURE raised
Exception information:
Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: trans-chap4.adb:306
Call stack traceback locations:
0x7fe4d3db5431 0x586799 0x593b0a 0x594373 0x5355b7 0x537350 0x5373fc 0x56a1ca 0x56695a 0x56707d 0x5b365f 0x5544f4 0x5b8816 0x46ce48 0x42fe13 0x7fe4d3233a3e 0x42f277 0xfffffffffffffffe
******************************************************************

How to reproduce : ghdl -a test.vhd, with the following test.vhd:

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

entity a is
port
(
    foo : in std_ulogic_vector
);
end a;

architecture rtl of a is
begin
end rtl;

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

entity b is
port
(
    bar     : inout std_logic_vector(7 downto 0)
);
end b;

architecture rtl of b is
begin

i_a: entity work.a
port map
(
    foo => std_ulogic_vector(bar)
);
end rtl;

The problematic line is foo => std_ulogic_vector(bar). The problem can be easily worked around by doing that:

architecture rtl of b is
    signal baz : std_ulogic_vector(bar'range);
begin

baz <= std_ulogic_vector(bar);

i_a: entity work.a
port map
(
    foo => baz
);
end rtl;

Best regards

Marc

Linking of C binary with VHDL binary

In older version of GHDL, there was an option to link C binary with VHDL binary for VHPI. Now I have tried with this version of GHDL it is not there. Can you please help me if there are some other options to do that.
Previously It was
ghdl -e -Wl,c-code.o ghdl-binary

I am getting following error:
ghdl: unknown option '-Wl,' for command '-e'

Compiling file with --std=08 and --ieee=synopsys

Hello there,

I try to compile the altera mega function simulation files (altera_mf). If I try to use --std= with --ieee the compilation fails with: "cannot find resource library "ieee""
If I remove the --std option everything is fine.

There are some other things with these options, that seem wrong. With --std=93 and --ieee=synopsys I get an error, with --ieee=synopsys only I get the same message but as warning.

Do I miss something with those two options?

Best regards,
Chris

Hierarchical names

I get this :

******************** GHDL Bug occured ****************************
Please report this bug on http://gna.org/projects/ghdl
GHDL release: GHDL 0.33 (20150921) [Dunoon edition]
Compiled with GNAT Version: GPL 2015 (20150428-49)
In directory: /Users/igmar/SpiderOak Hive/msx3/vhdl/
Command line:
/usr/local/bin/ghdl1-llvm --workdir=/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/z80 --work=z80 --std=08 -P/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/vunit_lib -P/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/osvvm -P/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/z80 -P/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/vunit_lib/ -P/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/osvvm/ -P/Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/z80/ -P/usr/local/lib/ghdl/v08/std/ -P/usr/local/lib/ghdl/v08/ieee/ -c -o /Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/ghdl/libraries/z80/tb_z80_noop.o /Users/igmar/SpiderOak Hive/msx3/vhdl/vunit_out/preprocessed/z80/tb_z80_noop.vhd
Exception SYSTEM.ASSERTIONS.ASSERT_FAILURE raised
Exception information:
Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: no field Named_Entity
Load address: 0x1038fb000
Call stack traceback locations:
0x1043bd791 0x103929ab5 0x103aaca8e 0x103acb458 0x103acc872 0x103a96756 0x103ace0a1 0x103ad62ac 0x103a2e88e 0x103a86fec 0x10393bc0e 0x1038fccda

---

ghdl: compilation error

Problems with parallel invocation of GHDL - GCC backend

A VUnit+GHDL user has reported a problem with running parallel simulations of the same test bench using GHDL with the GCC backend.
It seems similar to the problem I reported in ticket_87 which were fixed for the LLVM backend.

The problem manifests itself in the following way when running --elab-run on multiple tests in parallel on the same top level:

Error: can't open e~tb_test_lib-tb.s for reading: No such file or directory

Reading a file from within a protected type (file identifier local to pt)

Issue

When trying to read from a file from within a protected type using a local file identifier, the following error message results:
c:\tools\ghdl-0.33\bin\ghdl.exe:error: overflow detected
c:\tools\ghdl-0.33\bin\ghdl.exe:error: simulation failed

Test Case

VHDL Test File: pt_file_read_issue.txt
Required file to be read: TbAlertLog_t8_log1.txt

Impact: Important to OSVVM

Initialization of Memory Models created using MemoryPkg requires file reading. A coverage database may be written and then read in (used to randomize a configuration at the start of a test). The initialization for log enables within AlertLogPkg can be accomplished by reading a file. This issue prevents these from working.

Unhandled exception for assignment of signed(std_logic_vector(unsigned)) to a part of signed vector

Output:

eval_pos: cannot handle IIR_KIND_SUBSTRACTION_OPERATOR (loopfilter/loopfilter.vhd:22:37)

******************** GHDL Bug occured ****************************
Please report this bug on http://gna.org/projects/ghdl
GHDL release: GHDL 0.33 (20150921) [Dunoon edition]
Compiled with GNAT Version: 5.3.0
In directory: /home/prabhpreet/Documents/College/Notes/SEM8/DSP Project/Work/vhdl/
Command line:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/ghdl1 --std=93c --workdir=workdir -P/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/vhdl//v93/std/ -P/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/vhdl//v93/ieee/ -quiet -o workdir/loopfilter.s loopfilter/loopfilter.vhd
Exception TYPES.INTERNAL_ERROR raised
Exception information:
Exception name: TYPES.INTERNAL_ERROR
Message: errorout.adb:63
Call stack traceback locations:
0x64be13 0x65e1d7 0x660340 0x6dc748 0x6913b7 0x693454 0x698218 0x6a46c8 0x6a58a3 0x6bc076 0x6e40d9 0x6b2d13 0x6e5d55 0x632d6d 0x6100ce 0x9f97af 0x9fb44e 0x632dc9 0x60d1c7 0x7fd9e046670e 0x60db47 0xfffffffffffffffe
******************************************************************

Execution terminated by unhandled exception
Exception name: TYPES.INTERNAL_ERROR
Message: errorout.adb:63
Call stack traceback locations:
0x64be13 0x65e1d7 0x660340 0x6dc748 0x6913b7 0x693454 0x698218 0x6a46c8 0x6a58a3 0x6bc076 0x6e40d9 0x6b2d13 0x6e5d55 0x632d6d 0x6100ce 0x9f97af 0x9fb44e 0x632dc9 0x60d1c7 0x7fd9e046670e 0x60db47 0xfffffffffffffffe
ghdl: compilation error

Input file (shortened):

-- loopfilter.vhd
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity loopfilter is
  port(clk, reset: in std_logic;
      mult_error_op:in signed(38 downto 0);
      f_desired: in unsigned(5 downto 0);
      f_word_output: out unsigned(5 downto 0));
end loopfilter;

architecture loopfilter_arch of loopfilter is

  signal beta_e, alpha_e: signed(45 downto 0);
  constant alpha: signed(7 downto 0) := "01110011";
  constant beta: signed(7 downto 0) := "00011010";
  constant plus_one: signed(alpha_e'range) := ('0', others => '1');

...

begin

...

  ADDERS : process(clk, reset)
  variable freq_add_var : signed(beta_e'range);
  variable n_total_var: signed(alpha_e'range);
  variable temp: signed(n_total_var'range);
  begin
    if reset = '1' then
      freq_add_var := (others => '0');
      freq_add_var(42 downto 37) := signed(std_logic_vector(f_desired)); --This line is causing problems.
      n_total_var := (others => '0');
    elsif 
      ...
    end if;
   ...

  end process;

end loopfilter_arch;

I was also getting errors when I tried assigning freq_add_var as an aggregate

freq_add_var := (42 downto 37 => signed(std_logic_vector(f_desired)), others=> '0');

That also gave me another exception and the same error.

Full file at: https://ptpb.pw/eyf_

Detect simple recursion

GHDL loops forever if a file is opened via file_open (...). I get a message from Windows that ghdl.exe got killed.

A reproducer is attached.
Tested with GHDL 0.34dev on Windows (mcode) in VHDL-93 mode.

fileio.v93.vhdl

'others' choice not allowed for an aggregate in this context

Dear all,

It seems that unconstrained vectors are not supported by ghdl, is my code buggy or is it a missing feature?

example :

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

entity test is
port
(
    data                : out std_ulogic_vector
);
end test;

architecture rtl of test is
begin
    data <= (others => '0');
end architecture rtl;

ghdl gives me:test.vhd:14:16: 'others' choice not allowed for an aggregate in this context.

Thank you in advance

Best regards

GHDL Bug occured on invalid assignment.

The following selected signal assignment is invalid because of a duplicate entry:

entity tmp is end entity;
architecture arch of tmp is
    signal b : bit;
begin
    with true select b <=
     '0' when false | true,
     '1' when true;
end architecture;

Ghdl instead of reporting the error fails with:

******************** GHDL Bug occured ****************************
Please report this bug on https://github.com/tgingold/ghdl/issues
GHDL release: GHDL 0.34dev (20151126) [Dunoon edition]
Compiled with GNAT Version: 5.3.0
In directory: /tmp/
Command line:
ghdl -m tmp
Exception SYSTEM.ASSERTIONS.ASSERT_FAILURE raised
Exception information:
Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: iirs.adb:2475
Call stack traceback locations:
0x4f307f 0x419e14 0x43c4ee 0x4b50bf 0x4b9f98 0x49b7ab 0x49e224 0x49e87e 0x4c5d0b 0x46b84c 0x45c988 0x46aac2 0x475a46 0x49109a 0x480eb3 0x405706 0x4031bf 0x7f5b60f1660e 0x402747 0xfffffffffffffffe
******************************************************************

It has been tested wirh d3d07ba and 2ac8454, both failed.

Thanks!

Deep recursion detection

Suggested feature

I implemented a method like this in a protected type:

type JSON is protected
  impure function HasError return BOOLEAN;
end protected;

type JSON is protected body
  variable pHasError : BOOLEAN := FALSE;
  impure function HasError return BOOLEAN is
  begin
    return HasError;
  end function;
end protected body;

The typo is at the return statement where the method is called recursively instead of pHasError.

I assume GHDL has a control and data flow analysis, so is it possible to detect (deep) recursions and emit a warning?

What happens in case of such a recursive call? GHDL.exe was killed by Windows :).

Referencing an Alias within a use clause

Issue

Numeric_std_unsigned includes aliases to functions to provide a wider range of names and sometimes fix the evils of the past. I needed to reference a couple of functions from numeric_std_unsigned without replacing "=" (so I can correctly check for 'U'). Hence, to get access to to_slv, I did:

use ieee.numeric_std_unsigned.to_slv ; 

Error messages:

to_slv_issue.vhd:14:25: no overloaded function found matching 'to_slv'

Test Case and Work Around

Test case: to_slv_issue.txt

Work around: to_slv_issue_work_around.txt

Impact

This was done in a testbench model that was testing a memory model package (OSVVM 2015.06). When the memory location is uninitialized, it returns "UUUU", however, it the memory location was written to with an 'X' it returns "XXXX". I needed both an easy conversion from integer to std_logic_vector as well as a way to check for the values "UUUU" and "XXXX". I don't expect these to happen often.

"bound check failure" in parts of code that are unreachable

I stumbled upon some weird behaviour of ghdl:
When simulating ghdl complains about bound check failures in parts of code that should never be reached with the configuration for this entity.

I tried to replicate the behaviour in a minimal example, but couldn't really isolate it. I have attached an small example.

Steps to reproduce:

1. Download example, unzip and enter directory: bound_check_bug_example.zip
2. make
3. ./bug_example_tb

Simulation aborts with error

./bug_example_tb:error: bound check failure at zpu_core_flex.vhd:458
./bug_example_tb:error: error during elaboration

If we look at zpu_core_flex.vhd:458 (see code snippet below) we see that the line that would cause a bound check failure is inside an IF...THEN for which the condition is FALSE (the corresponding generic is set to REMAP_STACK => FALSE in bug_example_tb.vhd:39)

if REMAP_STACK=true then
    report "this message is never printed becasue REMAP_STACK was set to false";
    -- But ghdl still complains about a "bound check failure" here, 
    -- because stackBit > pc'LENGTH-1
    pc(stackBit)          <= '1';
end if;

As a test I added a report message. But this is never reported, which indicates that the code indeed is never reached. But still it causes the error.

Support for x86-64 windows (win32.c)

I'm attempting to cross native build ghdl with gcc backend (Cygwin build, Mingw host/target). Having replaced jumps.o with win32.o as Make targets, the build succeeds but when I run the VUnit user guide example, I get a run time exception (0xC0000005: Access violation reading location 0x00000000fffdf000.) during the elaboration step.

Difficult to debug, but I was wondering if there are other run time targets that should be include i.e. I currently have GRT_TARGET_OBJS=win32.o math.o clock.o. Also, do I need to be using pthreads?

Any help would be appreciated.

Missing source code line number.

I managed to calculate negative delay times, which causes GHDL to stop with an error.

ghdl.exe:error: negative timeout clause
ghdl.exe:error: simulation failed

Is it possible to report the VHDL source code line? I suspect it's in one of my procedures....

GHDL internal error

I have encountered a situation in which GHDL crashes out with an internal error. Details are contained within the attached zip archive, which was created with the current zip utility on Ubuntu 14.04 LTS. The archive contains source code, build files, and all messages GHDL emits before it crashes.

I raised this issue yesterday on the mailing list. The files expand to about 512k. Unfortunately, I am unable to reproduce the error with smaller files. I did not include object files as these total about 4Mbytes,

Someone (was it Patrick in Germany?) that a newer build was available than I have. I did not know that existed; I have posted the output from 0.33 released about October of last year.
Cheers
John
files.zip

Function overloading vs Indexing

Issue

overload_index_issue.txt:20:35: can't resolve overload for function call, slice or indexed name
overload_index_issue.txt:20:35: possible interpretations are:
c:/SynthWorks/Dev/_osvvm/src/CoveragePkg.vhd:414:21: function randcovpoint [real return integer]
overload_index_issue.txt:20:35: indexed name

Visible functions

function randcovpoint [real return integer]
function randcovpoint [return integer_vector]

Thoughts

There are a number of places where this happens and the function input is an integer. Hence, perhaps it is possible for the LRM to be unclear about whether function overload or indexing is possible, however, in this case, type real clearly cannot be used as a type for indexing as it is not a discrete type and is not used to index any array.

Going further, even in the cases where the input parameter is an integer, I have not encountered any issues among two popular commercially simulator vendors (and 3 different simulators).

Test Case

overload_index_issue.txt

Impact

OSVVM has numerous functions that are overloaded to return either integer or integer_vector. This is going to create a confusing issue for the user community - particularly since other tools do not have an issue with it.

Jumps.c errors when cross native compiling to Mingw

I'm attempting to cross native build ghdl with gcc backend (Cygwin build, Mingw host/target), and make errors when trying to compile jumps.c. The first error involves siginfo_t not being defined. Googling reveals that mingw may not support siginfo_t. In order to work around this temporarily, I've deleted the contents of jumps.c, and the build proceeds, but I suspect I may hit a run time issue at some point.

Can anyone help with a) a way of keeping the content of jumps.c and b) whether omitting its content will work going forwards

Recursive instantiation

I wrote a simple sorting network (odd even sort), that compiles in the following simulators:

• GHDL 0.33 (--std 93)
• QuestaSim 10.4c (--93 and --2008)

But when I compile the same code with GHDL and switch to --std=08, it crashes with the following error message:

******************** GHDL Bug occured ****************************
Please report this bug on http://gna.org/projects/ghdl
GHDL release: GHDL 0.33 (20150921) [Dunoon edition]
Compiled with GNAT Version: GPL 2015 (20150428-49)
In directory: D:\git\PoC\temp\ghdl\
Command line:
C:\Tools\GHDL\0.33\bin\ghdl.exe -r --syn-binding -P. -Paltera -Pxilinx -Posvvm -Pvuint --std=08 --work=test sortnet_OddEvenSort_tb
Exception CONSTRAINT_ERROR raised
Exception information:
Exception name: CONSTRAINT_ERROR
Message: ortho_code-decls.adb:122 index check failed
******************************************************************

The shrinked example design is attached as *.txt files (VHDL files can't be uploaded):

• sortnet_OddEvenSort.vhdl.txt
• sortnet_OddEvenSort_tb.vhdl.txt

(All files are compiled into a library called test.)

Receive error on generic package

Hi,

The following error is produced when compiling:

/root/workspace/uvvm/uvvm_vvc_framework/src/ti_generic_queue_pkg.vhd:26:10: 'signal', 'constant', 'variable', 'file' or identifier expected
/root/workspace/uvvm/uvvm_vvc_framework/src/ti_generic_queue_pkg.vhd:26:32: ',' or ':' expected after identifier
/root/workspace/uvvm/uvvm_vvc_framework/src/ti_generic_queue_pkg.vhd:26:32: (found: ;)

Line 26 - 28 from the source code:

generic (type t_generic_element;
GC_QUEUE_COUNT_MAX : natural := 1000;
GC_QUEUE_COUNT_THRESHOLD : natural := 950);

The documentation states that only parts of vhdl 2008 is supported, however I can't find any reference to generic packages. Does ghdl support this yet? Or do you have any other ideas about what goes wrong here?

Thanks

conditional assignment in a process not supported

Issue

Conditional assignment is a process not supported

Test Case

cond_assign_proc.txt

Impact

In OSVVM testbench. Changing testbench to make it a non-issue.

Creating an array of protected types causes a GHDL crash.

I have created an array type of an protected type. The file analyzes but causes a crash in elaboration. (GHDL 0.33 - 20150921 - windows)

According to this SO question it's currently not allowed in VHDL-2008, but I think GHDL should exits with an error message instead of an "TYPES.INTERNAL_ERROR exception in trans.adb:551

Regards
Patrick

building instructions for gcc libbacktrace for working with llvm

I downloaded the latest libbacktrace from https://github.com/gcc-mirror/gcc/tree/master/libbacktrace when i run configure i get:

configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

i checked shtool is available on my prompt

> shtool --version
GNU shtool 2.0.8 (18-Jul-2008)

GHDL doesn't set a non-zero return exit value on errors in Linux (gcc backend)

I was up to finish the vendor specific compile scripts for GHDL on Linux, when I noticed that GHDL (gcc backend) does not set a non-zero exit code if an error occurred. The Windows version (mcode backend) with returns "1".

Analyzing primitive 'C:\Xilinx\14.7\ISE_DS\ISE\vhdl\src\unisims\secureip\GT11CLK_MGT.vhd'
return=0
Analyzing primitive 'C:\Xilinx\14.7\ISE_DS\ISE\vhdl\src\unisims\secureip\GT11_CUSTOM.vhd'
ERROR: C:\Xilinx\14.7\ISE_DS\ISE\vhdl\src\unisims\secureip\GT11_CUSTOM.vhd:328:13: no declaration for "gt11"
ERROR: C:\Xilinx\14.7\ISE_DS\ISE\vhdl\src\unisims\secureip\GT11_CUSTOM.vhd:328:13: component name expected
return=1

The return line is reported by:
Write-Host "return=$LastExisCode"

Here is the equivalent Linux output:

Analyzing primitive '/opt/Xilinx/14.7/ISE_DS/ISE/vhdl/src/unisims/secureip/GT11_CUSTOM.vhd'
/opt/Xilinx/14.7/ISE_DS/ISE/vhdl/src/unisims/secureip/GT11_CUSTOM.vhd:328:13: no declaration for "gt11"
/opt/Xilinx/14.7/ISE_DS/ISE/vhdl/src/unisims/secureip/GT11_CUSTOM.vhd:328:13: component name expected
return 0

The return line is reported by:
echo "return $?"

Is it intended to be always zero? How can I test if an error occurred, except for parsing the complete output line by line :).

The source code for the compile script is available on my GHDL fork on branch paebbels/lib-compile-linux.

version requirement for gcc libbacktrace for building with llvm

If you want to have stack backtraces on errors (like assert failure or
index of out bounds), you need to configure and build libbacktrace from gcc

Is there any version requirement for libbacktrace or can i just use latest?

VHDL-2008 Matching Equality Relationals with erroneous warning message

Matching Equality Relationals are producing the following error message:
std_logic_1164.vhdl:58:3:@0ms:(assertion error): STD_LOGIC_1164: '-' operand for matching ordering operator
std_logic_1164.vhdl:58:3:@0ms:(assertion error): STD_LOGIC_1164: '-' operand for matching ordering operator
Oddly it seems that

each call produces two warnings

Why is an unconstrained constant vector in GHDL not considered to be static?

I have the following code:

entity test is
end entity;

architecture rtl of test is
  type T_TUPLE is record
    A  : NATURAL;
    B  : NATURAL;
  end record;
  type T_VECTOR is array (NATURAL range <>) of T_TUPLE;

  constant LIST : T_VECTOR := ((8, 32), (8, 20), (8, 36));
begin
  genTests : for i in LIST'range generate
    constant LOCAL_A : NATURAL := LIST(i).A;
    constant LOCAL_B : NATURAL := LIST(i).B;
  begin
    -- my tests
  end generate;
end architecture;

When I compile the code with VHDL-2008 enabled, I get the following error message for my generate statement:

... range must be a static discrete range

When I change my constant to a constrained variant it works...

constant LIST : T_VECTOR(0 to 2) := ((8, 32), (8, 20), (8, 36));

Why is the 2. example more static?

I also tried this code:

constant initial_LIST : T_VECTOR := ((8, 32), (8, 20), (8, 36));
constant LIST : T_VECTOR(initial_LIST'range) := initial_LIST ;

The error is the same at the generate statement. But there is no problem at the second constant declaration.

My local GHDL version is 0.33 (20150921). This PC had no build environment to check it in 0.34dev.

libbacktrace.a not installed with make install

When building GHDL with libbacktrace.a to enable back traces using the LLVM backend the file is not copied to the install directory. Thus when simulating the following error occurs:

gcc: error: /opt/ghdl/lib/ghdl/libbacktrace.a: No such file or directory