I did something kind of like this for a college project. We were taking a course on FPGA soft-processors, and for our final project, we had to build A Thing.
My team chose to reimplement Space Invaders. The soft-core was supported by a C compiler, so we wrote the game in C, with carefully-chosen functions for graphics rendering containing #ifdefs that gated either direct memory accesses (for the FPGA VGA hardware) or SDL calls.
Our "init()" function would initialize the VGA hardware on the FPGA, and create an SDL window when compiled on a computer with an OS.
Using this, the hardware and software people were able to work together in parallel, and we won best project for our class, with a grand prize of "we'll show your cool project to the next classes".
As I recall, we wrote most of the game using SDL backend, and only tested it on "real" hardware a few days before the final project. We found a single bug (during the integration) that took us on the order of half an hour to debug, and that was that.
While Verilog is not SystemVerilog, it’s more or less a subset of it. And SystemVerilog had much more industry support for design verification. So if I were to design some open source software for HDLs, that reason alone would make VHDL a non-starter.
Sure it's capable, but there's certainly a cost of having to use multiple languages in your test bench/DUT. I'd argue that's one of the reasons why Verilator, CocoTB, Chisel, etc. haven't taken off in the "traditional" semiconductor industry (i.e. not FPGAs).
at the same time, if you're transpiling from something else, verilog is MUCH better than VHDL because as a language it has a much smaller surface area.
Modulo "HDL is different because everything is synchronous" and the testing DSL, You can learn most of verilog in a day, not so much VHDL.
And that's why Verilog has mostly "won". But syntax isn't the whole story of a language. VHDL's type system is much superior to Verilog's. I once worked for an EDA company and we had a product that emitted HDL (Verilog or VHDL depending on what the user chose). At some point we had requests from customers to fix linting warnings in the generated code. My job was to placate the linter. For the VHDL code generator there wasn't much to fix - just not a lot of linting problems due to the type system. For the verilog code generator, though, there were lots of linting warnings to fix.
I imagine you think pascal and ada have horrible syntax too?
For me, the syntax is ideal. On the plus side VHDL seems to have actually been designed with the intention of being used for FPGA designs. Verilog on the other hand just seems like a hack in comparison.
Verilog is weakly typed and VHDL is strong. That is already a pretty big deal when dealing with vector signals, where Verilog happily assigns a 32-bit signal to a 16-bit signal.
VHDL also supports defining record types, such that a collection of signals can be assigned together.
VHDLs type system is pretty rock solid it’s based off Ada after all. Which if you have looked at in any detail its a great type system!
I dont like the begin end style syntax and some the verbosity that entails with VHDL. However, I would rather create designs in VHDL than verilog when given the choice.
I come from a VHDL background (the industry I work in is purely VHDL), but recently I've been enjoying Systemverilog
in my personal projects and it fixes a lot of these issues!
It's true that SystemVerilog fixed a lot of Verilog's deficiencies and took it more in the direction of VHDL. But a lot of free tools don't support SystemVerilog.
Hm, every vendor with free tools (Xilinx/Altera/Lattice/Microsemi etc), seem to be fine with it, along with the usual vendor-specific Modelsim. In fact, most "verilog" synthesis tools actually synthesize SystemVerilog. Out of curiosity what tool are you referring to?
There's few open source tools for any HDL full stop.
Indeed I'd say SystemVerilog is doing better on that front, as Verilator (https://www.veripool.org/verilator/) supports SystemVerilog and is probably the best open source tool for 'real' HDL work (note the number of industrial users).
I didn't mean open source, no, and it looks like the free version of yosys has limited support of systemverilog.
What I meant were the free toolchains provided by all of the FPGA vendors. They typically support SystemVerilog in synthesis and modelsim as far as I have seen.
One nice feature of VHDL we could use in modern software is different styles of descriptions of the same object in the same model: behavioral, structural, dataflow. The model can be given to tools operating at different levels: synthesis, simulation, verification etc.
This looks really helpful! I have been working on FPGA stuff and have never really been able to figure out how to tie the knot with Verilator, even though I knew this was theoretically possible.
I can empathise. I was aware of Verilator for ages before I started simulating my own designs with it. The Verilator documentation is good, but it can do so much that it's hard to know where to start.
Verilator can simulator a subset of SystemVerilog, mostly that which is synthesizable (though work is on-going to expand its capabilities so it can run UVM code).
So it's a replacement for modelsim if you're just using it to run your actual design RTL. You need to build a synthesisable testbench or write one in C++ (or check cocotb: https://github.com/cocotb/cocotb)
My team chose to reimplement Space Invaders. The soft-core was supported by a C compiler, so we wrote the game in C, with carefully-chosen functions for graphics rendering containing #ifdefs that gated either direct memory accesses (for the FPGA VGA hardware) or SDL calls.
Our "init()" function would initialize the VGA hardware on the FPGA, and create an SDL window when compiled on a computer with an OS.
Using this, the hardware and software people were able to work together in parallel, and we won best project for our class, with a grand prize of "we'll show your cool project to the next classes".
As I recall, we wrote most of the game using SDL backend, and only tested it on "real" hardware a few days before the final project. We found a single bug (during the integration) that took us on the order of half an hour to debug, and that was that.