This page contains ideas for enhancing GHDL that can fit internship programs, such as Google Summer of Code.
VHDL frontend for Yosys¶
Yosys is an open-source synthesis tool with built-in Verilog support and partial SystemVerilog support. ghdlsynth-beta is an experimental plugin for Yosys that allows to use GHDL (precisely, libghdl) as a frontend for Yosys. Although functional, Synthesis is work in progress: multiple features are not supported yet, and others need to be tested for bugs.
Currently, GHDL does not include profiling features, which would allow to speed-up simulations and/or to detect hotspots in user designs.
Improve LLVM backend¶
There are several possible enhancements to the current implementation of LLVM backend
- Debugging is supported with LLVM 3.5 only, although up to version 9.0 is supported for simulation.
- The C++ API of LLVM should be used instead of the C API.
- There was no real try to find the best order of optimization passes. This can significantly improve performance, since GHDL is currently single-threaded and CPU-bound.
- Code coverage is not supported.
Support 64-bit with mcode on Windows¶
The built-in in-memory code generator (mcode backend), is supported on 64 bit GNU/Linux, but not on Windows 64 bit. Compared to other backends, this would provide a lightweight and fast analyser, although it doesn’t try to optimise.
Multiple proofs of concept exist for co-execution of HDL simulators with other tools, such as QEMU. However, there is no open-source solution that allows to co-simulate VHDL and Verilog sources using recent versions of the standards. Some possible approaches for this task are:
- Use procedural interfaces, VPI or VHPIDIRECT (see Interfacing to other languages).
- Transpile/convert the HDLs into a common intermediate representation.
- Have GHDL use the API of another tool or the other way round.
Thre are three different approaches for mixed-signal simulation with GHDL:
- Built-in VHDL-AMS support. It is currently possible to analyze VHDL-AMS files with GHDL (almost all the features are handled). However, it is analysis only (yet). A DAE solver needs to be pluged into GHDL compute the simulation.
- Co-execution of GHDL and an analog simulator through VPI or VHPIDIRECT (see Interfacing to other languages).
- Generation of simulation models from VHDL-AMS, like ADMS.
Currently, GHDL can be wrapped in a foreign language (such as Ada or C) through VHPIDIRECT (see Interfacing to other languages). However, runtime management of the simulation is not supported. The API should be enhanced to support stepped execution. Moreover, interfacing with some types is not straightforward. Header files with the definition of those types would simplify data transference between language domains during simulation.
ghdl-language-server is an experimental LSP server written in Python (which uses libghdl-py), along with clients for different editors (e.g. VSCode, Emacs or Vim). Although functional, it is work in progress: multiple features are not supported yet, and others need to be tested for bugs.
Project configuration file format¶
ghdl-language-server supports a configuration file named hdl-prj.json. The format of this file is undocumented and lightly defined. This is because it would be desirable to use a configuration format that can be shared with other similar tools, such as rust_hdl or pyVHDLParser. In the context of GHDL, the same configuration file might be used for the language server, simulation, synthesis, etc.
Packaging for Windows and/or macOS¶
GHDL can be installed with the most known package managers on GNU/Linux distributions (apt, dnf, pacman, etc.). However, this is not the case on Windows and/or macOS.
On Windows, PKGBUILD files for MSYS2 are available, but not upstreamed. Nonetheless, it would be desirable to distribute an standalone package that does not depend on a ful MSYS2 installation (see Building GHDL from Sources).
On macOS, a Homebrew formula might be written.
Ideally, these packages would be built/generated and tested in a CI workflow.