confusion about signal assignments...

[Neil]

hi, all,

I want to know some feathures of signal, so i just write a test design file
as follow to check
how the signal assignment works. but it doesn't work as I think.
In my opinion, finally, bOut should be 22, and aOut should be 11, since
there is a delta delay for the assignment of signal.
but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
11.
so what's wrong in my thought, can anyone explain it? thank you.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity test is
port(
aOut : out integer range 0 to 100;
bOut : out integer range 0 to 100);
end entity test;

architecture behave of test is
signal a: integer range 0 to 100 := 11; -- assign the initial values
signal b : integer range 0 to 100 := 22;
begin
process(a, b) -- the current value of a is 11 as default, and the b is
22 as default
begin
a <= b; -- assign the current value of b to a, but not really
assigned yet
b <= a; -- assign the current value of a to b, but not really
assigned yet
aOut <= a; -- assign the current value of a to aOut, but not really
assigned yet
bOut <= b; -- assign the current value of b to bOut, but not really
assigned yet
end process; -- and now, all assignments take effect, and the value
of a is 22, the value b is 11
-- and with next process execution, the value of aOut
and bOut is 22 and 11 for each
end architecture behave;

but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
11

Best Regards!
-- Neil

 

[eko]

You generate combinational logic. Combinational logic pretty much does everything at the same time. Whenever a signal changes, this change affects whatever other signals are tied to it right away.
In order to get a discrete, sequential processing you will need a clock driven process.

 

[kennheinrich]

hi, all,

I want to know some feathures of signal, so i just write a test design file
as follow to check
how the signal assignment works. but it doesn't work as I think.
In my opinion, finally, bOut should be 22, and aOut should be 11, since
there is a delta delay for the assignment of signal.
but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
11.
so what's wrong in my thought, can anyone explain it? thank you.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity test is
port(
aOut : out integer range 0 to 100;
bOut : out integer range 0 to 100);
end entity test;

architecture behave of test is
signal a: integer range 0 to 100 := 11; -- assign the initial values
signal b : integer range 0 to 100 := 22;
begin
process(a, b) -- the current value of a is 11 as default, and the b is
22 as default
begin
a <= b; -- assign the current value of b to a, but not really
assigned yet
b <= a; -- assign the current value of a to b, but not really
assigned yet
aOut <= a; -- assign the current value of a to aOut, but not really
assigned yet
bOut <= b; -- assign the current value of b to bOut, but not really
assigned yet
end process; -- and now, all assignments take effect, and the value
of a is 22, the value b is 11
-- and with next process execution, the value of aOut
and bOut is 22 and 11 for each
end architecture behave;

but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
11

Best Regards!
-- Neil

In Modelsim 6.0, I get an "iteration limit reached at time 0 ns".
This makes sense; you're basically saying that you want signals a and
b to exchange values every time the process executes, so you'll either
have a steady-state with a=b (if they happen to be the same initial
values), or a never-ending exchange (oscillation). Since there's no
time parameter involved, this process executes at time 0, swaps the
values, the drivers update, all delta cycles are finished, then the
process gets put back on the ready queue (since a and b changed,
that's your sensitivity list), but still at time 0. This happens
forever, always at time 0, presumably until Modelsim decides to pull
the plug.

- Kenn

 

[Mike Treseler]

so what's wrong in my thought, can anyone explain it? thank you.

1. Your asynchronous process loops more than once.
2. Signals always contain the value
received in the *previous* loop.

I prefer a synchronous process because
it loops only once per rising_edge(clock).

I prefer process variables because
they always use the *present* value.

I believe that this is more in line
with what a new student of
hardware description expects.

-- Mike Treseler

 

[Duane Clark]

hi, all,

I want to know some feathures of signal, so i just write a test design file
as follow to check
how the signal assignment works. but it doesn't work as I think.
In my opinion, finally, bOut should be 22, and aOut should be 11, since
there is a delta delay for the assignment of signal.
but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
11.
so what's wrong in my thought, can anyone explain it? thank you.

Stick a wait just before the end process, and you can see what is happening.

wait for 1 us;
end process;
end architecture behave;

 

[Duane Clark]

wait for 1 us;
end process;
end architecture behave;

And remove the sensitivity list...

 

[jens]

For something that may be more interesting and is a closer match to a
real-world scenario, try this (and predict or figure out why the
outputs are doing what they're doing):

entity test is
port
(
clk: in std_logic;
input: in integer;
output1: out integer;
output2: out integer;
output3: out integer;
output4: out integer
);
end entity test;

architecture behave of test is
signal a1: integer;
signal b1: integer;
signal c1: integer;
signal a2: integer;
signal b2: integer;
signal c2: integer;
begin
process(clk)
variable a3: integer;
variable b3: integer;
variable c3: integer;
variable a4: integer;
variable b4: integer;
variable c4: integer;
begin
if rising_edge(clk) then

-- output1
a1 <= input;
b1 <= a1;
c1 <= b1;
output1 <= c1;

-- output2
output2 <= c2;
c2 <= b2;
b2 <= a2;
a2 <= input;

-- output3
a3 := input;
b3 := a3;
c3 := b3;
output3 <= c3;

-- output4
output4 <= c4;
c4 := b4;
b4 := a4;
a4 := input;

end if;
end process;
end architecture behave;

 

[Mike Treseler]

For something that may be more interesting and is a closer match to a
real-world scenario, try this (and predict or figure out why the
outputs are doing what they're doing):

I'll bite, since your example is clean
and includes an entity.
I would recommend turning this job over to
synthesis once the lesson is learned.

if rising_edge(clk) then

-- output1
a1 <= input;
b1 <= a1;
c1 <= b1;
output1 <= c1;

-- output2
output2 <= c2;
c2 <= b2;
b2 <= a2;
a2 <= input;

The order of cascaded signal assignments makes no difference.
Only the input has an immediate value.
I'd expect four cascaded regs in either case:

input-[a]--[c]-[o]-output


Order matters with variables,
and all values are immediate.

A variable right before left
*or* on the right of a port
makes a reg.

-- output3
a3 := input; -- wire
b3 := a3; -- wire
c3 := b3; -- wire
output3 <= c3; -- reg

input-----------[o]-output

-- output4
output4 <= c4; -- reg
c4 := b4; -- reg
b4 := a4; -- reg
a4 := input; -- reg

input-[a]--[c]-[o]-output


-- Mike Treseler

 

[neil3w]

Stick a wait just before the end process, and you can see what is happening.

wait for 1 us;
end process;
end architecture behave;

yeah, I try to add "wait for 50 ns", and it works to change the
value...
but I can't not simulate this in QuartusII, does QuartusII 7.2SP2 not
support wait for statement? Analyzing is OK, but can't to generate the
function netlist, it prompts:
"Error (10533): VHDL Wait Statement error at test.vhd(23): Wait
Statement must contain condition clause with UNTIL keyword"
and even if I add the until condition, it still doesn't work.

Regards!
-- Neil

 

[neil3w]

1. Your asynchronous process loops more than once.
2. Signals always contain the value
received in the *previous* loop.

I prefer a synchronous process because
it loops only once per rising_edge(clock).

I prefer process variables because
they always use the *present* value.

I believe that this is more in line
with what a new student of
hardware description expects.

-- Mike Treseler

thanks, Mike.

it seems I almost know the why...

 

[neil3w]

1. Your asynchronous process loops more than once.
2. Signals always contain the value
received in the *previous* loop.

I prefer a synchronous process because
it loops only once per rising_edge(clock).

I prefer process variables because
they always use the *present* value.

I believe that this is more in line
with what a new student of
hardware description expects.

-- Mike Treseler

but, one more problem:
the assignment(changing) of a and b will always trigger the process,
so the process will loop all the time until simulation time ends.
if thinking in this way, the value of a and b will exchage all the
time since all the statements in a process totally execute for each
trigger. especially with following feature:

2. Signals always contain the value
received in the *previous* loop.

and at least, at the simulation time 0, the aOut shoule be the
previous value of a which is 11, and the bOut should be the previous
value of b which is 22.

this makes me confusion again... thank you!

Regards!
-- Neil

 

[Mike Treseler]

yeah, I try to add "wait for 50 ns", and it works to change the
value...
but I can't not simulate this in QuartusII, does QuartusII 7.2SP2 not
support wait for statement? Analyzing is OK, but can't to generate the
function netlist, it prompts:
"Error (10533): VHDL Wait Statement error at test.vhd(23): Wait
Statement must contain condition clause with UNTIL keyword"
and even if I add the until condition, it still doesn't work.

Adding the wait was a demonstration
to answer your vhdl question,
not a recommendation for synthesis code.

I stand by my advice to vhdl novices
to start with a synchronous process
for synthesis code.

Note also that the Altera-Modelsim
simulator that comes with a quartus
license is far superior to any
of the 'free' simulators that
I have tried.

-- Mike Treseler

 

[neil3w]

In Modelsim 6.0, I get an "iteration limit reached at time 0 ns".
This makes sense; you're basically saying that you want signals a and
b to exchange values every time the process executes, so you'll either
have a steady-state with a=b (if they happen to be the same initial
values), or a never-ending exchange (oscillation). Since there's no
time parameter involved, this process executes at time 0, swaps the
values, the drivers update, all delta cycles are finished, then the
process gets put back on the ready queue (since a and b changed,
that's your sensitivity list), but still at time 0. This happens
forever, always at time 0, presumably until Modelsim decides to pull
the plug.

- Kenn- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

- ÏÔʾÒýÓõÄÎÄ×Ö -

hi, Kenn,

thank you.

so, that means, if the sensitivity list changes and there is no longer
delay(which is much larger than delta) after all delta cycles
finished, the process will be triggerd again immediately without push
simulation time forward?
but this should not make the values of aOut and bOut both 11 ... at
least, at simulation time 0, the results of aOut and bOut should be 22
and 11 each.

 

[Duane Clark]

but, one more problem:
the assignment(changing) of a and b will always trigger the process,
so the process will loop all the time until simulation time ends.
if thinking in this way, the value of a and b will exchage all the
time since all the statements in a process totally execute for each
trigger.

In a synchronous process, you only have CLK in the sensitivity list, so
that will not happen.

 

[Andy]

Order matters with variables,
and all values are immediate.

A variable right before left
*or* on the right of a port
makes a reg.

To clarify, the assignment to the port in a clocked process,
regardless of whether a variable or anything else appears on the
right, is a register. If there is a reference to a variable on the
right has not been written in that clock cycle, then that variable
reference is also a register (two total).

-- two registers between in_port and out_port
if rising_edge(clk) then
out_port <= var;
var := in_port;
end if;

-- one register between in_port and out_port
if rising_edge(clk) then
var := in_port;
out_port <= var;
end if;

Just remember that variables execute like software, and the synthesis
tool will insert registers to make the cycle-cycle timing of the
hardware match that of the process.

Andy