Why does the placement of a statement mater in vhdl, I thoug

[Morten L. Haugen]

Why does the placement of a statement mater in vhdl, I thought it was a
parallel language )-:



What vhdl mechanism occurs when the placement of a statement (before or
after an if statement) makes a complete different result in a clocked
process? First process below generates a flip-flop for rd_1_en, while the
second process below generates just a constant '1' for rd_2_en.

Seems to be valid construction, checked with modelsim, synplify, Xilinx XST.



I guess its delta delays defining what happens, any body who understand this
in detail?

Same result in all tools?



p_one_ff : process(clk)

begin

if rising_edge(clk) then

rd_1_en <= '1'; -- statement in question !!!!!!!!

if (sel_low = '1') then

rd_1_en <= '0';

end if;

end if;

end process p_one_ff;



p_constant_1 : process(clk)

begin

if rising_edge(clk) then

if (sel_low = '1') then

rd_2_en <= '0';

end if;

rd_2_en <= '1'; -- statement in question !!!!!!!!

end if;

end process p_constant_1;



Morten L. Haugen,

GE Vingmed Ultrasound, Norway

 

[backhus]

Hi Morten,
There are parallel as well as sequential statements available in VHDL.
Assignment has identical syntax, but you have use e.g. "WITH" instead of
"CASE" and "WHEN" instead of "IF" outside of a process.

Inside a process you can use only sequential statements. You may also
use variables, which behave like variables in a programming language.
Their values are updated immediately after an assignment.

Signals behave different in a process. You have to keep the
reader-driver model of signals in mind. While the process is running all
actual values of a signal are taken from it's reader-value. The Driver
value will be overwritten on each occuring assignment of that signal
during a process. At the end of a process or when a wait-statement stops
the process the driver-value will be forwarded to the reader of the signal.
This behavior of Signals can be very handy. Assume you have a large
(combinatoric) case construct with a lot of output signals that rarely
change. Instead of putting the whole list of output signals in each case
branch you can put a default value list in front of the case and only
vallues that differ from the default into the case branches. e.g.:

process (selector, out1) is
begin
out1 <= '0'
out2 <= '0'
out3 <= '0'
case selector is
when 1 => null;
when 2 => out1 <= '1';
when 3 => out2 <= 'out1';
when 4 => null;
when 5 => out3 <= 'Z';
when 6 => null;
when others => out3 <= '1';
end process;

Delta delays have nothing to do with this.
Delta delays happen when processes have to run multiple times to
evaluate the results of all changing signals, caused by a single signal
event.
Assume selector changes from 1 to 2. This causes the above process to
execute once which increments the delta delay value and causes out1 to
change. This change again triggers the above process and increments the
delta delay value. Since there's no change of any signal in this second
run the simulator comes to a halt after two delta delays and looks for
further events scheduled in the future to continue. (there may be more
signals in your design!)


Your process p_one_ff uses the signal rd_1_en in a similar way as
described above.
In p_constant_1 the assignment of rd_2_en at the end renders the
if-construct useless. (the driver of rd_2_en will always be '1' at the
end of the process, so rd_2_en never changes)

Have a nice simulation
Eilert


Morten L. Haugen schrieb:

Why does the placement of a statement mater in vhdl, I thought it was a
parallel language )-:



What vhdl mechanism occurs when the placement of a statement (before or
after an if statement) makes a complete different result in a clocked
process? First process below generates a flip-flop for rd_1_en, while the
second process below generates just a constant '1' for rd_2_en.

Seems to be valid construction, checked with modelsim, synplify, Xilinx XST.



I guess its delta delays defining what happens, any body who understand this
in detail?

Same result in all tools?



p_one_ff : process(clk)

begin

if rising_edge(clk) then

rd_1_en <= '1'; -- statement in question !!!!!!!!

if (sel_low = '1') then

rd_1_en <= '0';

end if;

end if;

end process p_one_ff;



p_constant_1 : process(clk)

begin

if rising_edge(clk) then

if (sel_low = '1') then

rd_2_en <= '0';

end if;

rd_2_en <= '1'; -- statement in question !!!!!!!!

end if;

end process p_constant_1;



Morten L. Haugen,

GE Vingmed Ultrasound, Norway

 

[ghelbig]

On Sep 17, 10:20 pm, "Morten L. Haugen" <morten.l.hau...@bluezone.no>
wrote:

Why does the placement of a statement mater in vhdl, I thought it was a
parallel language )-:

What vhdl mechanism occurs when the placement of a statement (before or
after an if statement) makes a complete different result in a clocked
process? First process below generates a flip-flop for rd_1_en, while the
second process below generates just a constant '1' for rd_2_en.

Seems to be valid construction, checked with modelsim, synplify, Xilinx XST.

I guess its delta delays defining what happens, any body who understand this
in detail?

Same result in all tools?

p_one_ff : process(clk)

begin

if rising_edge(clk) then

rd_1_en <= '1'; -- statement in question !!!!!!!!

if (sel_low = '1') then

rd_1_en <= '0';

end if;

end if;

end process p_one_ff;

p_constant_1 : process(clk)

begin

if rising_edge(clk) then

if (sel_low = '1') then

rd_2_en <= '0';

end if;

rd_2_en <= '1'; -- statement in question !!!!!!!!

end if;

end process p_constant_1;

Morten L. Haugen,

GE Vingmed Ultrasound, Norway

You are getting exactly the results I would expect.

In each process you have two assignments to the same signal. The
assignments will be done from top to bottom, just like any other
procedural language.

Your first process has a common method for avoiding latches; set every
signal in the process at the beginning, then change some of them
according to conditions.

(BTW, Verilog behaves the same way.)

Hope that helps,
G.

 

[Brian Drummond]

On Thu, 18 Sep 2008 07:20:55 +0200, "Morten L. Haugen"
<morten.l.haugen@bluezone.no> wrote:

Why does the placement of a statement mater in vhdl, I thought it was a
parallel language )-:

It is a parallel language, but...

What vhdl mechanism occurs when the placement of a statement (before or
after an if statement) makes a complete different result in a clocked
process?

within the boundaries of a process, it is a serial language.

Your result follows.

Same result on all non-broken tools.


(Within a process you have all the usual facilities of procedures,
functions, variables etc you are used to within a single process in C or
Ada.)
NOTE: variables obey the usual semantics of assignment in a process, but
signals do not: that is because they are the inter-process communication
mechanism; they do not really have an equivalent in C, though they are
related to the Ada rendezvous. That is where delta cycles come in)

- Brian

 

[Alan Fitch]

Morten L. Haugen wrote:

Why does the placement of a statement mater in vhdl, I thought it was a
parallel language )-:



What vhdl mechanism occurs when the placement of a statement (before or
after an if statement) makes a complete different result in a clocked
process? First process below generates a flip-flop for rd_1_en, while the
second process below generates just a constant '1' for rd_2_en.

Seems to be valid construction, checked with modelsim, synplify, Xilinx XST.



I guess its delta delays defining what happens, any body who understand this
in detail?

Same result in all tools?

Hi Morten,
as other people have said, statements in processes are sequential.

When you make a signal assignment, the signal does not change value
straight away - it is scheduled to change at the next "update phase"
of the scheduler.

If you make two signal assignments (as you've shown) with no delays
between them (no wait statement) then that is known as "inertial delay"
or "last assignment wins". The second assignment schedules a new value
on to the signal which deletes the previous pending assignment.

You can think of the scheduler approximately as follows (*)

(1) execute all processes until they suspend
(2) update all signals, creating events and possibly making new
processes runnable
(3) if any processes are runnable, go back to step (1)
(4) advance time (may make processes runnable)
(5) if processes are runnable go back to step (1)
(6) finish simulating

steps (1) and (2) consist of evaluation/update. That is the delta cycle.

regards
Alan

(*) or why not come on our VHDL training course

--
Alan Fitch
Doulos
http://www.doulos.com

 

[Andy]

While the subject of sequential execution of statements inside a
process has been well covered here, the concept of signal assignments
and updates has not.

There are two kinds of objects that can be assigned in a process: a
variable or a signal. As mentioned earlier, variable assignments
operate just like in C or any other sequential language.

Signal assignments in processes are executed sequentially, but to
avoid ambiguity in inter-process communication (separate processes can
execute in any order), signal value updates are delayed until the
process suspends (waits). There is one and only one update to a given
signal when the process suspends, regardless of the number of
assignments to it that were executed. If multiple assignments are
executed to a signal between successive process suspensions, the last
executed assignment determines the update value.

Hope this helps,

Andy