-
Notifications
You must be signed in to change notification settings - Fork 347
Ideas: GSOC
This page contains ideas for enhancing GHDL that can fit internship programs, such as Google Summer of Code (GSOC).
Yosys is an open-source synthesis tool with built-in Verilog support and partial SystemVerilog support. ghdl-yosys-plugin is an experimental plugin for Yosys that allows to use GHDL. Although functional, synthesis support is work in progress: multiple features are not supported yet, and others need to be tested for bugs.
Refs:
Currently, GHDL does not include profiling features, which would allow to speed-up simulations and/or to detect hotspots in user designs.
Refs:
There are several possible enhancements to the current implementation of the LLVM backend.
- 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.
- Debugging is supported with LLVM 3.5 or >=6.
Refs:
- FOSSI GSOC 2018 | GHDL: Improve LLVM backend
- #866, #667, #744, #286
- freecompilercamp.org/clang-llvm-landing
The built-in in-memory code generator (mcode), 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.
Refs:
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 ghdl-cosim).
- Transpile/convert the HDLs into a common intermediate representation.
- Have GHDL use the API of another tool or the other way round.
Refs:
- FOSSI GSOC 2018 | Framework for Mixed-Language Simulation
- FOSSI GSOC 2017 | Open Source Mixed-Language HDL Simulation
- #908, #800, #1335
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 :ref:
USING:Foreign
). - Generation of simulation models from VHDL-AMS, like ADMS.
Refs:
Currently, GHDL can be wrapped in a foreign language (such as Ada or C) through VHPIDIRECT (ghdl-cosim). 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.
Refs:
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.
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.
Refs:
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 and upstreamed. Nonetheless, it would be desirable to distribute an standalone package that does not depend on a full 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.
Refs: