RE: Alternatives to VHDL/Verilog for hardware design

johnbeetem — Wed, 29 Oct 2014 03:33:58 GMT

I don't like Verilog or VHDL. Given the choice, I mostly use Verilog since I don't want to type more than necessary and I have limited storage space for listings.

My main problem with Verilog and VHDL is that they were designed for simulation. Synthesis was added as an afterthought. It's quite difficult for an inexperienced user to know how to write Verilog to get the synthesizer (I mostly use Xilinx's XST) to create the logic the user wants. XST matches "language templates" to find things like flip-flops, registers, and RAMs. "Language templates" are hidden in ISE's Edit menu. Many new users don't know about the templates, and merrily write Verilog or VHDL from textbooks and it simulates fine. Then they try to synthesize and get frustrated.

Here's how I write Verilog: I imagine what hardware I want, and then I write my Verilog to match the template for each piece of hardware. This is basically compiling in reverse: you imagine the object code, and then write your source code so that the compiler does the right thing. I'm probably better at this than most designers since I've written compilers and digital design tools, so it's easy for me to guess at what Xilinx tools do.

Jonathan makes the comment "these languages can generate sub-optimal, faulty hardware which can be very difficult to debug." This is quite true. I'm able to create high-quality hardware using "reverse compilation" and fit complex functionality into inexpensive Spartan-3A chips, but if you write Verilog naïvely you are likely to end up with sub-optimal results. This is actually advantageous to FPGA vendors and sales reps, because if your logic is too large and/or too slow, you need to use larger, faster, more expensive FPGAs to complete your design. However, it's also disadvantageous because it makes people think twice about using FPGAs at all.

The Xilinx tools make it hard to tell what the synthesizer actually generated, so if you made a mistake it's hard to track down, as Jonathan said. If you're doing CPLD design, Xilinx lists the Boolean equations implemented by the macro cells. There's no equivalent for FPGA design. They do provide automatically-generated schematics, but IMO those are only useful for simple designs.

My favorite commercial FPGA design language was Altera Hardware Description Language (AHDL). It was basically registers and Boolean expressions, without any of this Verilog/VHDL behavioral nonsense. So it was easy to tell AHDL what logic you wanted, and easy to look at the report and see that AHDL actually generated the correct logic.

My favorite non-commercial FPGA design language is GalaxC for Hardware Design (GCHD), which is part of my 21st Century Co-design (XXICC) project [link]. GCHD is a work in progress, but you can read about it in The XXICC Anthology rev 0.0k if you're interested. You can see some simple working GCHD examples in Flavia: the Free Logic Array.

GCHD is an extension of the GalaxC Programming Language [Programming in the GalaxC Language rev 0.0j], and uses the same compiler for parsing and semantic analysis. The GalaxC compiler calls module post-processing functions to convert GalaxC's intermediate language PSI (Postfix Stack Interpreter) into executable code for simulation, or logic networks for synthesis. Unlike Verilog and VHDL, GCHD describes the hardware you want rather than the behavior you want. Thus what you write is in a form that is easily synthesized.

RE: Alternatives to VHDL/Verilog for hardware design

Former Member — Tue, 28 Oct 2014 18:26:25 GMT

Nice write-up, but one important clarification.

You can download a command line (offline) tool of PSHDL

https://pshdl.org/releases/ or http://code.pshdl.org/pshdl.commandline/wiki/Home

While the syntax of PSHDL is inspired by C, that's about it. Its not intended to be compatible to any C code. Personally I think that the most viable HLS candidate is OpenCL as Altera is pursuing it. The code that was produced by people coding for OpenCL was with parallelization in mind, which probably allows the biggest re-use of existing code. The idea to take general C code and turn it into optimized logic is really far down the road. Maybe some-day we don't have to care about the costs of FPGA logic (both from a power and economic point of view), that this becomes viable. But so far even the use-cases for any FPGA are rather limited, or in other words: CPUs are becoming so powerful and cheap that it is hard to compete with them.