
Minimizing FPGA Resource Utilization - jsnell
http://zipcpu.com/blog/2017/06/12/minimizing-luts.html
======
CamperBob2
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?

~~~
jacquesm
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.

~~~
lvoudour
>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

------
FullyFunctional
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](http://fpgacpu.org)

