Minimizing FPGA Resource Utilization | Hacker News Reader

Minimizing FPGA Resource Utilization

zipcpu.com

73 pointsjsnell6 comments

Great post. I see a lot of constructs like this:

     always @(posedge i_clk)
	     A <= A + 1'b1;
     always @(posedge i_clk)
	     C <= C + 7;

What's the upside to breaking these nonblocking assignments into multiple always blocks?

There really aren't any. The compiler will compile the code the same either way.

Readability. Just like you can cram a whole bunch of code on a single line for a regular program it doesn't help a person trying to understand the code.

Like this the steps required to build your mental model of what is going on are smaller, and so this makes it easier to construct that model. And hopefully with fewer errors between what you think it does and what it actually does.

The repetition establishes local context, it also allows you to make changes later that will affect the one but not the other construct without making a larger change.

I find myself being extremely skittish when changing FPGA code and I tend to play it safe until stuff works and then I'll remove that short of pattern when I'm sure I won't be inserting / removing bits or changing the conditions. Initially it helps me to write out the various conditions without any kind of optimization in mind (and besides the real optimizations are usually done by the toolchain).

This is one of the main problems I have with FPGA work, I've done so much software that it is hard to get back into the mindset of programming a device and small steps really help. I also find it considerably harder to read FPGA code (my own or someone else's, of any flavor) than to read a program and to figure out what it does.

>Readability. Just like you can cram a whole bunch of code on a single line for a regular program it doesn't help a person trying to understand the code.

Language syntax is also a major problem. For example, if the author chose to join those two always statements he/she would have to use begin/end keywords which are ugly and cause visual "clutter". VHDL is not better in that regard, I'd say it's even worse (e.g. converting back and forth between std_logic_vector and signed/unsigned).

The only drawback I see in the author's code is that using (lots of) multiple always blocks may slow down simulation, but that's a fair price to pay if the code is more readable

Mostly a style preference, but for one thing it emphasizes that A is a flip-flop. Keeping them separate this way makes it easier if one should change a flip flop to a wire later.

All sound advise. Much of this is covered by Jan Grey's great blog [1].

However I'm disappointed seeing the ancient Cyclone IV compared to a the current seven series. A fairer comparison would refer to Cyclone V, which uses the ALM, kind of a LUT6+ (that is, can sometimes even be a LUT7 or 8). This has an important impact on the optimization considered.

[1] http://fpgacpu.org

Reply on news.ycombinator.com