HDL - FAQs

As with any skill, the only way to improve and to grasp concepts is to practice. This page details some perspectives on writing HDL. They are mostly perspective based, and the way you conceptualize creating hardware may be different. In the same way that there are often many approaches to solving problems, there are many ways to implement solutions in hardware. However, they don't all work, and some are definitely better than others. The hope is that this page helps you to be able to better grasp writing HDL and how your thinking needs to change in order to understand how to solve the problems you're given.

How is HDL Different from Writing Software?

Hardware Descriptor Languages (HDLs - most commonly VHDL or Verilog) is fundamentally different from the programming languages you’re used to.

With writing software, you’re describing how to solve a problem. When writing HDL, you’re describing how hardware works. Ideally your description should be the description to a solution.

When writing HDL you need to think about HOW the code translates to hardware. I find it helpful to think of my project as a breadboard, modules as IC’s, registers as, well, registers in the module, wires as connections between modules, and inputs/outputs as pins on the IC. Output registers are just registers tied directly to an “output pin”. It isn’t a perfect analogy of course - sometimes it makes more sense to think of the current module you’re in as the primary breadboard (but in that case I just imagine I’m designing the IC).

Why isn't this loop working as I expect?

You can’t directly translate the constructs you’re used to in software to programming constructs in hardware. A good example is for loops. You may be tempted to use a for loop as a delay, but a for loop in hardware operates rather differently to a for loop in software. Think about how you might implement a for loop as you understand it – the easiest to do is have a register, incrementally increase that register’s value, and then perform your operation once that register reaches the desired value. Nandland (a great resource for all things FPGA) has a nice discussion on for loops in HDL (https://www.nandland.com/vhdl/examples/example-for-loop.html) but for the most part there’s no need to use a for loop, or any kind of loop for that matter.

Why is my code taking a long time to compile?

“Compile” isn’t technically correct here – it’s synthesizing, converting to a netlist, and then creating a bitstream. But we all know what each other means, so I suppose it’s okay. This is usually quite a time consuming process, which is why testbenches and simulation are such a great and easy way of testing code changes before trying to run it on the board.

Single core performance is really the biggest factor in synthesis. There is use for multicore, but a lot of the synthesis -> bitstream generation is mostly sequential (I’ve been told that the Altera/Intel tools only see about a 10% improvement when moving to the multicore/multi-threaded implementation of the synthesis tools). That probably makes a difference when creating projects that take hours to synthesize, but, for practicals and most applications, high performance PCs won’t really make all that much of a difference as most modern CPUs have similar enough single-core throughput (assuming a modern architecture).

Memory (RAM) is also a big contributing factor, but according to https://www.xilinx.com/products/design-tools/vivado/memory.html the XC7A100T (the FPGA found on the Nexys A7) uses at MOST 3GB of RAM. An implementation of a simple wall clock display only requires about 700-800mb

Always relevant XKCD