wait for signal change

[Andy Peters]

I think I should be able to do this, but I can't figure out what signal
attribute or other magic incantation is necessary. The following is
for a test bench.

Given a signal:

signal InData : std_logic_vector(7 downto 0); -- or whatever

assigned in some process somewhere:

InDataDrive : process is
begin
InData <= foo;
wait until FooIsHappy;
InData <= bar;
wait until BarIsHappy;
end process InDataDrive;

I'd like to have a process somewhere detect that InData changes and
then do something with the new value:

DealWithIt : process is
begin
... do some stuff
wait until InData'event;
... do more stuff
end process DealWithIt;

This all works wonderfully except when foo and bar are the same. In
that case, the wait until InData'event triggers on the initial change
(imagine that some other process changes both foo and bar during the
time BarIsHappy is false) but when InData is assigned bar (same as
foo), DealWithIt doesn't trigger.

I also tried

wait until InData'active;

which also didn't work.

Seems to me that even though the values assigned to InData are the
same, there are still transactions on InData.

I'm using ModelSim XE 6.0a. Perhaps there's an optimization happening?

I tried

wait until (InData'transaction = '1');

but that was even more evil -- my entire simulation suspended here.

Any ideas? I was trying to be clever and avoid adding a "New Data
Available" signal to this test bench logic.

Thanks,
-a

 

[Egbert Molenkamp]

Maybe the quiet attribute?
Here an example. Since p is changed after a delta delay. De process resumes
after a delta. Then p1 is assigned at the second delta the process resumes
after the second delta and wait forever.

Egbert Molenkamp

entity demo is
port (a : in integer := 0);
end demo;

architecture bhv of demo is
signal p, p1 : integer := 0;
begin
process
begin
p <= a;
wait until not p'quiet;
report "test" severity note;
p1 <= p;
wait until not p1'quiet;
wait;
end process;
end bhv;

 

[Andy Peters]

Maybe the quiet attribute?
Here an example. Since p is changed after a delta delay. De process resumes
after a delta. Then p1 is assigned at the second delta the process resumes
after the second delta and wait forever.

Ahhh, that did the trick.

-a

 

[Klaus Falser]

I think I should be able to do this, but I can't figure out what signal
attribute or other magic incantation is necessary. The following is
for a test bench.

Given a signal:

signal InData : std_logic_vector(7 downto 0); -- or whatever

assigned in some process somewhere:

InDataDrive : process is
begin
InData <= foo;
wait until FooIsHappy;
InData <= bar;
wait until BarIsHappy;
end process InDataDrive;

I'd like to have a process somewhere detect that InData changes and
then do something with the new value:

DealWithIt : process is
begin
... do some stuff
wait until InData'event;
... do more stuff
end process DealWithIt;

This all works wonderfully except when foo and bar are the same. In
that case, the wait until InData'event triggers on the initial change
(imagine that some other process changes both foo and bar during the
time BarIsHappy is false) but when InData is assigned bar (same as
foo), DealWithIt doesn't trigger.

I also tried

wait until InData'active;

which also didn't work.

Seems to me that even though the values assigned to InData are the
same, there are still transactions on InData.

I'm using ModelSim XE 6.0a. Perhaps there's an optimization happening?

I tried

wait until (InData'transaction = '1');

but that was even more evil -- my entire simulation suspended here.

The statement
wait until InData'active;

has a implicit sensitivity list of InData. If InData
gets no new value (foo and bar are the same) there is
no event on InData and the wait clause is not triggered,
even if InData'active is true.

InData'transaction gives a signal which toggles between
'1' and '0' every time a transaction ( = assignment)
on InData is made, regardless of whether the new value is
the same as the old value.
You can trigger on this signal and it will work perfectly
if you write

wait on Indata'transaction;

Regards
Klaus