vhdl wait

Please review the snipped below.
I would expect the following scenario :
1. process p1 gets executed first. dummy is set to '0'. Then the
process is suspended until v_p1_enable is '1'
2. process p2 gets executed. After a suspension of 1us, it sets
v_p1_enable to '1'
3. process p1 comes out of suspension and resumes it tasks, setting
dummy to '1'

But simulation shows me that this is not the case... why not ?

architecture RTL of test is
shared variable v_p1_enable : std_logic := '0';
begin

p1:
process
variable dummy : std_logic;
begin
dummy := '0';
wait until v_p1_enable = '1';
dummy := '1';
end process;

p2:
process
begin
wait for 1 us;
v_p1_enable := '1';
end process;

end RTL;

Jan

Jan wrote:
> Please review the snipped below.
> I would expect the following scenario :
> 1. process p1 gets executed first. dummy is set to '0'. Then the
> process is suspended until v_p1_enable is '1'
> 2. process p2 gets executed. After a suspension of 1us, it sets
> v_p1_enable to '1'
> 3. process p1 comes out of suspension and resumes it tasks, setting
> dummy to '1'
>
> But simulation shows me that this is not the case... why not ?
>
> architecture RTL of test is
> shared variable v_p1_enable : std_logic := '0';
> begin
>
> p1:
> process
> variable dummy : std_logic;
> begin
> dummy := '0';
> wait until v_p1_enable = '1';
> dummy := '1';
> end process;
>
> p2:
> process
> begin
> wait for 1 us;
> v_p1_enable := '1';
> end process;
>
> end RTL;

Because p1 will immediately continue at the top of the process again, and set
dummy back to '0', and then wait for v_p1_enable to become '1' again.

Regards,

Pieter Hulshoff

Pieter Hulshoff

Fair enough... so let's change p1 to this :

p1:
process
variable dummy : std_logic;
begin
dummy := '0';
wait until v_p1_enable = '1';
dummy := '1';
wait for 1 us;
end process

still no movement on dummy in simulation...

Jan

On Tue, 20 Nov 2007 06:16:13 -0800 (PST), Jan <>
wrote:

>Please review the snipped below.
>I would expect the following scenario :
>1. process p1 gets executed first. dummy is set to '0'. Then the
>process is suspended until v_p1_enable is '1'
>2. process p2 gets executed. After a suspension of 1us, it sets
>v_p1_enable to '1'
>3. process p1 comes out of suspension and resumes it tasks, setting
>dummy to '1'
>
>But simulation shows me that this is not the case... why not ?

You can't wait on a shared variable; at least, not in
isolation. You need at least one signal.

VHDL's "wait until" command creates a sensitivity list from all
SIGNALS that take part in the wait expression. You have no
signals, so the wait statement has no sensitivity list and
will never release.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

p1 is an transmitting unit.
p2 is the receiving unit.

After transmitting something (p1), something is received (p2) in
response. p1 should meanwhile wait until the reception is complete.

How can i synchronize these two processes ?

Jan

On Tue, 20 Nov 2007 07:12:47 -0800 (PST), Jan <>
wrote:

>p1 is an transmitting unit.
>p2 is the receiving unit.
>
>After transmitting something (p1), something is received (p2) in
>response. p1 should meanwhile wait until the reception is complete.
>
>How can i synchronize these two processes ?

Like I said: use a signal (NOT a shared variable).

Basically, in VHDL communication between processes should
be achieved with signals. They have delta-delay update
semantics, guaranteeing freedom from races.

Shared variables are great for stuff like making configuration
information available throughout a testbench, or gathering
coverage data into a single tree. They're USELESS for
communication and synchronization between processes.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Jonathan Bromley

On Tue, 20 Nov 2007 06:16:13 -0800 (PST), Jan <>
wrote:

>Please review the snipped below.
>I would expect the following scenario :
>1. process p1 gets executed first. dummy is set to '0'. Then the
>process is suspended until v_p1_enable is '1'
>2. process p2 gets executed. After a suspension of 1us, it sets
>v_p1_enable to '1'
>3. process p1 comes out of suspension and resumes it tasks, setting
>dummy to '1'
>
>But simulation shows me that this is not the case... why not ?
>
>architecture RTL of test is
>shared variable v_p1_enable : std_logic := '0';
>begin
>
>p1:
>process
>variable dummy : std_logic;
>begin
> dummy := '0';
> wait until v_p1_enable = '1';

Do shared variables generate events? I didn't think they did.
In which case there's nothing to wake up this process.

I expect this would work if v_p1_enable was a signal.

- Brian

Brian Drummond

On 20 Nov., 15:16, Jan <jan.ki...@gmail.com> wrote:
> Please review the snipped below.
> I would expect the following scenario :
> 1. process p1 gets executed first. dummy is set to '0'. Then the

There is no such thing as "process p1 gets executed first" in the
language. Your simulator may start processes in any order. It is up to
you to implement handshakes or semaphores where needed.

The real problem was already good answered by the other posters.

bye Thomas

Thomas Stanka