This is a (proof of concept) library/framework of virtual components which can be reused for building testbenches using Hardware Description Languages (HDLs) and including software models/visualizations of non-trivial peripherals. Each virtual component is composed of three parts:
- Frontend (HDL module/component).
- Transport layer/mechanism.
- Backend (software library).
The purpose of this repository is to document the APIs used between the frontend and the transport, and between the tansport and the backend. Multiple projects exist which combine either GHDL, Icarus Verilog or Verilator with foreign languages (C/C++, Python, m, golang, JavaScript, etc.). Many of them implement the same peripherals (e.g. virtual VGA screen, pushbuttons, LEDs, etc.). However, there is no documented framework for sharing common resources. For instance, drawing the content of a framebuffer in a window is independent from how it is filled (either from VHDL, Verilog or some other HDL). Documenting intermediate APIs can hopefully help code reuse in the open source hardware development community.
- Frontend: See OSVB: Simulators | Compilers and OSVB: Frameworks and Methodologies.
- Transport: VPI/DPI, VHPI/VFFI/VDPI, etc. See OSVB: Co-simulation.
- Backend: ImageMagick, Xlib, Gtk, Qt, HTML/JS/CSS, DBHI, etc.
All of these simulators and virtual peripherals can be executed on high-performance workstations or on low-cost SBCs. Some solutions are available on Android smartphones/tablets too. See hdl/packages for further info about packaging/distribution alternatives for open source EDA tooling.
Tha main languages used for interfacing HDLs (VHDL, Verilog and/or System Verilog) with foreign languages are C/C++, since standard co-simulation interfaces are defined in those terms. However, several languages have built-in support for interacting with shared libraries and executable binaries using C semantics. Python, Rust or Julia, to name a few, provide built-in features for doing so. Moreover, libffi provides a generalized solution for defining target functions at runtime, instead of compile time.
With regard to distribution, there is work in progress for using *.core (YAML) files as a portable solution for defining filesets. See OSVB: Core.
- Line follower robot.
- BLDC motor.
- GPS sensor.
- Virtual Nexys-4 like board (gitlab.ensta-bretagne.fr/bollenth/ghdl-vpi-virtual-board):
- Visualization of hyperspectral/multispectral image processing cores (VUnit/vunit#568):
- ghdl/ghdl-cosim
- gitter.im/ghdl1/Lobby: 2019/07/12 8:12AM
- VUnit/cosim
- roby2014/virtual-board-vhdl
- renode.io
- antmicro/renode-board-visualization
- Related to hdl/constraints, and j0ono0/pinout (hdl/constraints#3)
- antmicro/renode-board-visualization
- hackfin/ghdlex
- sylefeb/Silice: Silice Verilator graphical simulation framework
- yaqwsx/Pinion: generate interactive and nice-looking diagrams for your PCBs! (yaqwsx.github.io/Pinion)
- olofk/vidbo (vidbo#5)
- tblink-rpc
- MathInspector/MathInspector
- ZipCPU/vgasim
- 8bitworkshop.com
- adumont/hrm-cpu@master/gui
- stevenbell/animatetiming
- isotel/mixedsim
- labsland.com
- redwoodeda.com
- tinkercad.com/circuits
- gitpod.io
- TerosTechnology/terosHDL
- GHDL, GRT and clock-gating: use
unsigned(63 downto 0)instead of twointeger. See https://github.com/VUnit/vunit/commit/89957a9b227ace890bfbfab0d50ff59940560b5c. - Python web frameworks:
- hipolitoguzman/virtualboard