For me the key to making everything understandable was adding more constraints to keep myself out of trouble. Everything is a finite state machine, exclusively non-blocking assignments, always loops use the rising edge of the clock signal only.
I would also recommend to use non-blocking assignments only for register updates, not in any description of combinational logic. It is (IMHO) much easier to read Verilog code with blocking assignments for logic since you basically can read the statements one after the other and mentally think that the RHS in a statement has been updated.
IF I may point to my own code, the prince cipher core shows how I use non-blocking assignments in a very simple reg update process. The datapath is in a separate, pure combinational process. And the control path is handled by the finite state machine update logic process at the end.
(Yes, I should really move the functions to a separate include file.)
The SystemVerilog always_comb and always_ff type of processes makes the distincion much clearer. But the same strategy holds for Verilog, and IMHO helps out understand the code. And often makes it less complex.
Another strategy to make life easier is to separate data flow (the transformation of inputs to outputs) and control flows. The control flow knows the context, and given the current state decides how the data flow transformation is performed.
Think of an ALU that can perform add, sub, shift operations. The ALU implementation simply accepts operands and perform one of the supported operations to generate the output. The control flow would in this case look at an opcode and decide which of the ALU operations to perform.
I tried Verilog at first but found myself liking vhdl quite a lot more. It just fit my mental model better and helped avoid some really silly errors I kept making as a beginner.
I could probably pick up Verilog now a bit quicker, I’d jump straight to system Verilog though if I did.
Verilog does make it fantastically easy to create bugs! It feels like very early C versions that are way too lenient. The biggest bang-for-the-buck you can get here is adding "`default_nettype none" at the top of every file, which makes undeclared identifiers an error. I believe this is SystemVerilog, though, and I agree that's what you should learn.
You should try out Chisel. I learned and used VHDL first, but after switching to Chisel I realized it was much better designed and avoided many of the footguns you'll likely encounter with Verilog or VHDL. And in general, it is a joy to work with.
I like the idea of a newer language but inevitably it feels like anything not Verilog or vhdl is missing direct tooling support from the vendors.
Do any vendors intend on supporting chisel? Does chisel have enough control to ensure generated vhdl/Verilog match the what vendors look for to infer certain things like certain ram and dsp instances? Does chisel have a fast simulator like ghdl?
Chisel is compiled to Verilog so it has excellent interoperability. You can use Chisel in an existing Verilog project or use existing Verilog modules in a Chisel project. Therefore it is already supported by practically all vendors and simulators.
I've used Chisel to interface with proprietary Lattice DSPs and RAM modules, and I'm sure you could do the same with other vendors as well. All you have to do is define the IOs and parameters of the module. In Chisel this is called a "Blackbox". Example: https://github.com/fayalalebrun/6502-exp/blob/master/src/mai...
SystemVerilog or a modern language like Chisel/HardCaml is the way to go. Combine SV with a good linter and you can avoid most of the silly bugs the language lets you do.
Greg Stitt shares amazing training materials freely (he uses them for his undergraduate and graduate courses). His synthesizable HDL methods are really empowering for beginner developers
In my case, building a miner and computation accelerator with FPGA boards really help me understanding the applications of FPGA. Though I have started learning HDL languages to build digital circuits, to me, that' not such an interesting subject, however, accelerated computing with FPGA had been very interesting experience.
Seems like fpga are more for hardware designs that need more compute than a DSP can provide. It’s nearly impossible to beat modern GPUs for compute power, but they also can’t or aren’t be integrated into a board that controls a microwave transponder, radar, or whatever. I’m a laymen though, hopefully someone will correct this post.
I think the answer is that it depends on what exactly you're optimizing for and what the workload is. I no expert either, but some of my predictions would be: DSPs and FPGAs will be great at compute per watt. FPGAs will have the highest initial cost. GPUs might beat FPGAs on floating point performance.
I started playing with FPGAs and HDLs a couple years ago with no hardware design background (I'm mostly a software architect/engineer) and in the end found that a "higher-level" HDL suited me better.
I chose Chisel (https://www.chisel-lang.org/) an HDL based on Scala (technically a Scala DSL) which can provide many facilities to hardware generation.
I'd highly advise looking into it although also knowing Verilog helps a lot.
As others have already mentioned the Lattice ice40 family is supported by OSS chains through project icestorm [0].
There were some nice boards floating around though you may have to watch out for supply chain issues still plaguing this market. Examples:
- icoboard: has the 8k LUTs chip, comes with soldered PMODs[1], if you get it watch out as you either need a RaspberryPI with GPIOs soldered to program it, or you purchase their USB FTDI interface in addition. See: http://icoboard.org/
I've had good experiences using Upduino 3.0 and 3.1 [0] with the IceStorm tools via apio [1]. I wrote a blog post [2] with some info on getting things set up via Linux. All you need is the Upduino board, which interfaces to your host system via USB (so no special programmer is needed).
QuickLogic [1] seems to support and target the open tool environment for their devices -especially the F4PGA [2] toolkit (known earlier as symbiflow). Others have mentioned Lattice FPGAs. But the impression I got from Lattice is that they like the development of open tools, but don't want to invest too much in it. QuickLogic on the other hand, contribute code and design directly to F4PGA project and allied ones like Migen.
Yep. I'm using the iCE40HX FPGA on an open "source" Olimex Board [1] and my toolchain is all free and open source tools: yosys, arachne-pnr (which is replaced by nextpnr, but I haven't upgraded yet), flashrom, iceprogduino, iverilog.
Yosys, the underlying compiler of ice studio, also targets the much bigger ECP5 FPGA, also by Lattice, which is called Project Trellis: https://github.com/YosysHQ/prjtrellis
Yosys functions more like a software open source tool. So command line compiling. It also has a REPL. It is very quick compared to the commercial solutions. Especially around compile times which can take seconds instead of minutes. YMMV, but I think the consensus is that it's a lot more convenient to use.
In general the hardware toolchains feel very ancient compared to software toolchains.
Yosys / project Trellis and nextpnr are amazing - I've played with them using an IceSugar-Pro board (which despite its name has an ECP5-25 FPGA) - but there's also an experimental branch for Xilinx 7-series devices now - Project X-ray, with an even more experimental branch of that targetting the Kintex7-325 FPGA on one of the QMTech (AliExpress) boards. That's of particular interest since that FPGA is large / high-end enough not to be supported by the free version of Vivado!
In the past I worked on a project with a soft CPU (Altera NIOS) with some custom Verilog written for glue logic. It was nice because the NIOS is just like a generic microcontroller so it's painless to try out some different Verilog blocks without having to interface an external micro. The toolchain is monstrous though, although free versions are available it's just a huge clunker to work with.
