Variable Read Before Assigned

If a variable is read before being assigned in a clocked process, I
understand that a register will be generated during synthesis.

So, with the code below:

PROCESS (RESET, CLOCK)
BEGIN
IF (RESET = 1) THEN
a := '0';
ELSIF (CLOCK = '1' AND CLOCK'EVENT) THEN
CASE a IS
WHEN IDLE => a := '1';
....
END IF;
END PROCESS;

1. Does the assignment in the reset condition cover "assigned before
being read", or is this separate from the clocked portion of the
process?

2. Does the case statement case expression (i.e. CASE a IS) count as
the variable being read? In this instance the CASE expression is read
first, then there is an action to assign the variable based on the
present state.

Thanks.

Analog_Guy

On Nov 5, 12:13*pm, Analog_Guy <analog_...@hotmail.com> wrote:
> If a variable is read before being assigned in a clocked process, I
> understand that a register will be generated during synthesis.
>

But your understanding is not firm enough...leading to the question

> So, with the code below:
>
> PROCESS (RESET, CLOCK)
> BEGIN
> * IF (RESET = 1) THEN
> * * a := '0';
> * ELSIF (CLOCK = '1' AND CLOCK'EVENT) THEN
> * * CASE a IS
> * * * WHEN IDLE => a := '1';
> ...
> * END IF;
> END PROCESS;
>
> 1. Does the assignment in the reset condition cover "assigned before
> being read", or is this separate from the clocked portion of the
> process?
>

Sounds like you're getting hung up on terminology, maybe a different
description of the behaviour will help.

Every time you re-enter a process, variables will have whatever value
was last assigned to them. So when your process is entered with reset
active, 'a' will be set to '0' and since there is nothing else to do,
the process will then suspend. The next time the process is entered
due to a change in reset or clock, 'a' will still have the value of
'0' since that what you last assigned it to.

Note that it is quite permissable for the process to wake up and not
assign to anything. In your case this would occur at the rising edge
of reset or the falling edge of clock. Since no new assignments will
be made to 'a' on those process wake ups, 'a' will remain at whatever
it was last assigned to.

> 2. Does the case statement case expression (i.e. CASE a IS) count as
> the variable being read? *In this instance the CASE expression is read
> first, then there is an action to assign the variable based on the
> present state.
>

The case statement will evaluate 'a' based on the last value that was
assigned to it which by looking at your code would have to been from
an earlier execution of the process. Any code after this...
> WHEN IDLE => a := '1';
> ...
that looks at 'a' (say perhaps another 'case' statement or an 'if'
statement) would use a value of '1' for 'a' since the assignment in
the 'when idle' branch would've been the last thing that updated 'a'.

If you think in terms of hardware, each and every assignment to a
variable in a process creates a line in the sand. Prior to the
assignment, the variable has one meaning (in your example, 'a' would
be the 'Q' output of a flip flop). After the assignment, the variable
has a different meaning (in your example, 'a' would be the 'D' input
of a flip flop).

Thinking of it in this way, will likely give you headaches. Like it
or not, the easier way to view variables in a process is by thinking
of it in terms of how software typically works...i.e. when something
updates 'a', everything that happens 'downstream' will use the updated
variable.

Kevin Jennings

KJ

Analog_Guy wrote:
> If a variable is read before being assigned in a clocked process, I
> understand that a register will be generated during synthesis.
>
> So, with the code below:
>
> PROCESS (RESET, CLOCK)
> BEGIN
> IF (RESET = 1) THEN
> a := '0';
> ELSIF (CLOCK = '1' AND CLOCK'EVENT) THEN
> CASE a IS
> WHEN IDLE => a := '1';
> ...
> END IF;
> END PROCESS;
>
> 1. Does the assignment in the reset condition cover "assigned before
> being read", or is this separate from the clocked portion of the
> process?

That would be an asynch reset input to the 'a' flop,
if a flop is required for synthesis.


> 2. Does the case statement case expression (i.e. CASE a IS) count as
> the variable being read?

Yes.

> In this instance the CASE expression is read
> first, then there is an action to assign the variable based on the
> present state.

That would be a syntax error as 'a' is std_ulogic,
not a type enum.

Here is the template I use for variable registers:
http://mysite.verizon.net/miketresel...c_template.vhd


-- Mike Treseler

Mike Treseler

Both Mike and Kevin have given you good and accurate descriptions of
how variables work in processes (including clocked processes).

However, it is important to also understand that each and every
reference to (i.e. read from) a variable in a clocked process can
represent a delayed (registered) and/or instantaneous (combinatorial)
value. So the same variable may be both registered and combinatorial
in one process, depending on whether or not, at each access, it was
written prior to that access (within the same clock cycle) or not. Of
course multiple references to the registered value of the same object
will all use the same register.

Kevin's description of what happens inside the case statement leaves
out (or maybe just assumes) one minor detail: It is not whether a
variable access "appears in the code" after a write or not, but
whether the access is executed after the write or not. Since in a vhdl
case statement, all targets are mutually exclusive, references to 'a'
in other case targets would not be executed (within the same clock
cycle) after the existing one, regardless of whether they appeared
later or not.

You can even have a single reference to a variable be both a register
and a combinatorial value;

if rising_edge(clk) then
if condition then
timer := timer - 1;
end if;
if timer < limit then
output <= '1';
else
output <= '0';
end if;
end if;

In this case timer may have been updated or not, based on "condition,"
when it is compared to limit. What you will get for the input to the
comparison is a mux, controlled by "condition" that selects between
the registered value of timer and the combinatorial value of "timer +
1". It turns out that this mux is identical to the clock-enable
feedback mux created by the "if condition" statement.

The important thing to remember is that the synthesis tool will create
hardware that will mimic the cycle-cycle behavior of the code as it
would be simulated. If it needs a register to do that, it will use
one. In other words, if the simulator has to "remember" the previous
value of a variable, the synthesis tool will use a register.

Andy

Andy

Andy wrote:

> The important thing to remember is that the synthesis tool will create
> hardware that will mimic the cycle-cycle behavior of the code as it
> would be simulated. If it needs a register to do that, it will use
> one. In other words, if the simulator has to "remember" the previous
> value of a variable, the synthesis tool will use a register.

Well said.

Using variables makes synthesis harder
for humans, but not for quartus.

Most complaints about variables
end up in stories about manual synthesis.

If I didn't think that using variables
made my code easier to write, read, sim, and trace,
I wouldn't use them.


-- Mike Treseler

Mike Treseler

Mike Treseler wrote:
> Andy wrote:
>
>> The important thing to remember is that the synthesis tool will create
>> hardware that will mimic the cycle-cycle behavior of the code as it
>> would be simulated. If it needs a register to do that, it will use
>> one. In other words, if the simulator has to "remember" the previous
>> value of a variable, the synthesis tool will use a register.
>
> Well said.
>
> Using variables makes synthesis harder
> for humans, but not for quartus.
>
> Most complaints about variables
> end up in stories about manual synthesis.
>
> If I didn't think that using variables
> made my code easier to write, read, sim, and trace,
> I wouldn't use them.

Exactly. Note how simple the conceptual explanation is,
and how complicated, verbose and probably confusing the
hardware-oriented explanations elsewhere in this thread.

This shows why "think hardware" is a suboptimal paradigm.
It may make you blind for the elegant coding solutions
that variables offer. You might even give up on them.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

Jan Decaluwe