On Sep 25, 4:21 am, Tricky <Trickyh...@gmail.com> wrote:
> That is true, but that can make the code harder to read for someone
> else. If you use variables to imply registers or not, then it can be
> hard for someone to work out when or if a register is implied. Never
> hold a variable value over a clock edge.
>
> I find it best to use variables ONLY for combinational logic and let
> Signals imply the registers. It then makes the code easier to read for
> others. It also means if you need to access that that register value
> in another process, its always available.

I find most "readers" are more interested in the functionality, rather
than the resulting structure of the implementation. Thus, a
description that executes more like SW (what most folks are most used
to reading) is more "readable".

If I cannot divine the implemented structure from a piece of code, I
run it through a synthesis tool and look at the schematic (RTL or
gates) view. Synplify Pro is really good at that. Besides, if you rely
on the structure you think you will get from reading the code, you
will likely miss optimizations, etc. that a specific synthesis tool
will make (or not).

If I wanted my code to describe the smallest structural level of the
design (i.e. gates & flops), I'd code a net list. The whole point of
HDL is to be able to describe a functionality over time, and have the
tool figure out the best way to implement that in gates and flops. If
I don't like that implementation (it takes up too much time and/or
resources), then I worry about giving more hints about a structure I
think will help. But that is a last, rather than a first, resort.

Using variables also PREVENTS other processes from accessing the data,
unless it is "passed" to them on a signal. This keeps local things
local, and global things global (within an architecture). I could use
blocks and signals to accomplish that, but I prefer variables for
other reasons, as stated. In my designs, signals are used ONLY for
data passed between processes and/or ports. This also makes
synchronization boundaries easier to police without requiring separate
blocks or entity/architectures.

Andy