readme: add section 'References'

[umarcor]

This PR adds a 'References' section to the README. Two items are added:

• olofk/verilatio, which I assume is related to the 'Specification' in this repo.
• dbhi/vboard, which is a superset of this repo, since it targets additional languages and protocols.

[olofk]

This is great. Been meaning to talk to you to see where we can find points of collaboration, but I didn't remember the presentation side of vboard was this advanced last time I looked at it. Very excited to see what we can come up with.

Let's drop the verilatio link though. This is pretty much the same thing with a new name, so I'm intending to just remove the verilatio repo after I have transferred the data from there.. Hmm... maybe we could have the link until then and I'll just mark verilatio as deprecated

Anyway. Thanks. Picked and pushed

[umarcor]

This is great. Been meaning to talk to you to see where we can find points of collaboration, but I didn't remember the presentation side of vboard was this advanced last time I looked at it. Very excited to see what we can come up with.

Actually, the challenge in vboard is that there are half a dozen different quite good looking frontends, but each of them is completely independent.

• VUnitCoSim VUnit/vunit#568 were the first demos I did 3-4 years ago, using a Vue.js frontend, a Flask backend, VUnit for compilation/running, and VUnit/cosim for sharing data between HDL and the "virtual peripherals". The HDL part is GHDL and VHPIDIRECT. My focus back then was achieving step-by-step co-simulation for graphically inspecting the BRAM (buffers) deep inside some hyperspectral image processing cores. Hence, I deal with hyperspectral cubes instead of video. Similar, but not the same.
• https://github.com/dbhi/vboard/tree/main/vga and https://ghdl.github.io/ghdl-cosim/vhpidirect/examples/arrays.html#vga-rgb-image-buffer are the demos I did in 2020, while cleaning up and enhancing the cosimulation documentation in GHDL.
  • It is particularly interesting that ghdl-cosim includes mixed-signal co-simulation examples, using Xyce. So, potentially, we can combine analog and digital devices in our "virtual boards", should we have "simulation models" for them.
  • In fact, working on GHDL's cosim features, led me to get involved in the VHDL Analysis and Standardization Group (VASG). The next revision of VHDL is expected to include an specification for a VHDL Foreign Function Interface (VFFI) or VHDL Direct Programming Interface (VDPI), which we hope to be as close/compatible as possible to SV's DPI. See https://github.com/VHDL/Compliance-Tests/tree/master/cosim for further info.
• https://gitlab.ensta-bretagne.fr/bollenth/ghdl-vpi-virtual-board is an awesomely good looking GTK based frontend by a french student (see Learning VHDL with GHDL ghdl/ghdl#1291 (comment)). Similarly to my demos, it uses GHDL, but it is based on the VPI interface instead of VHPIDIRECT.
• People from Antmicro have designers working on the frontends, so the result is very nice: https://github.com/antmicro/renode-board-visualization. They are also working intensively on adding SV support to Verilator, and coherently adding AXI verification components using that solution. I talked to them about providing HDL users "black boxes" they can instantiate, similarly to how the "virtual VGA screen" is instantiated in https://github.com/dbhi/vboard/blob/main/vga/test/hdl/VGA_tb.vhd#L46-L56.
• https://8bitworkshop.com/v3.8.0/?platform=verilog&file=framebuffer.v is THE REFERENCE. Nice, clean, good performance. It does not have "a board" as a frontend, though, just the screen peripheral.
• In Add pinout diagrams hdl/constraints#3 we've been talking about using j0ono0/pinout and yaqwsx/PcbDraw for generating board drawings from KiCAD sources. For most open source boards, that'd provide the foundation for animating them in this repo.

I created the diagram in dbhi/vboard to hopefully start wrapping our heads around a similar set of layers, that can help us reuse pieces. As you see:

• The "Specification" in vidbo matches the "HTTPS(s)" block in vboard.
• The "Backend" in vidbo matches the "Transport" and "Backend" blocks of a "Virtual peripheral" in vboard.
• The "Frontend" in vidbo matches the "JS/TS frontend" in vboard.

Hence, the structure of vidbo does fit in the vboard conceptual model, except it's missing the "virtual HDL component instantiation", because it is common for verilator users to hook themselves into the hierarchy of the verilated output. That's one of the issues I talked with @kgugala and @PiotrZierhoffer about. In order for virtual peripherals to be useful for HDL designers, they should be used in HDL as it is done with regular Verification Components or Bus Functional Models. Virtual peripherals/boards are, in fact, "just fancy verification models".

The "gRPC, ZeroMQ..." block in vboard is worth an additional comment. Some years ago, I prototyped having "virtual Stream queues" using gRPC: dbhi/gRPC. That allows having multiple "clients" running on development boards, workstations, laptops, SBCs... Some clients are HDL simulations, others are pure software, others might be actual hardware. Each client pushes/pulls to queues in a common pool, identified by a name. In the context of vidbo/vboard, some of the "virtual peripherals" might be attached as clients to those queues. This is something we discussed during the last months in gitter.im/hdl/community both with @pepijndevos (NyanCAD) and @ktbarrett (cocotb).

Last, but not least, managing the sources for co-simulation along with HDL sources and the software sources for embedded CPUs is the main challenge I want to solve in the context of the discussions we had about FuseSoC, .core files, edaa-org.github.io, etc. When I started using co-simulation solutions 4 years ago, I found that existing "project management" tools were too focused on "traditional" simulation and/or synthesis (which is fair, not a criticism). See dbhi.github.io/concept/run. That represents 5-10 "digital twins".

/cc @LarsAsplund @mithro @sylefeb @Paebbels @JimLewis