Different Processes

[ALuPin]

Hi,

I am writing a VHDL testbench with the following structure:
For the purpose of clarity
I want to assign values to a signal in process A.
When reaching a certain value I want to continue assigning
values to the same signal in a different process B.

Is this possible somehow?

Thank you for your opinion.

A: process
begin
l_signal <= 0;
wait until rising_edge(clk);
wait until rising_edge(clk);

l_signal <= 1;
wait until rising_edge(clk);
l_signal <= 2;
wait until rising_edge(clk);
-->change process;
wait;
end process A;

B: process
begin
l_signal <= 3;
wait until rising_edge(clk);
l_signal <= 4;
wait until rising_edge(clk);
wait;
end process B;

 

[rickman]

Hi,

I am writing a VHDL testbench with the following structure:
For the purpose of clarity
I want to assign values to a signal in process A.
When reaching a certain value I want to continue assigning
values to the same signal in a different process B.

Is this possible somehow?

Thank you for your opinion.

A: process
begin
l_signal <= 0;
wait until rising_edge(clk);
wait until rising_edge(clk);

l_signal <= 1;
wait until rising_edge(clk);
l_signal <= 2;
wait until rising_edge(clk);
-->change process;
wait;
end process A;

B: process
begin
l_signal <= 3;
wait until rising_edge(clk);
l_signal <= 4;
wait until rising_edge(clk);
wait;
end process B;

It is possible in VHDL using shared variables (":=" instead of "<=").
But I don't think your code will do what you are expecting. Do you
expect the above code to produce the sequence 0, 1, 2, 3, 4 (assuming
you change it to use a shared variable)? It won't. It will first
produce a random result of either 0 or 3 depending on which process is
run first making this illegal code by the standard. Then it will assign
the other value. One clock later it will assign the value 4, a clock
later it will get the value 1 and a clock later the value 2.

What are you trying to do and why do you thing two processes are clearer
than one?

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

What are you trying to do and why do you thing two processes are clearer
than one?

Oooops, that should be "why do you THINK"...

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[cristian]

Oooops, that should be "why do you THINK"...

--

Rick "rickman" Collins

(e-mail address removed)
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

Processes are sequential within them, but concurrent betweem them.
Therefore, you have to be very carefull on the way of using common
signals between processes.
I agree with rick, maybe just one process works better in this case.

regards,

 

[Martin Bishop]

ALuPin

All you have to do, to code your testbench like this, is use a resolved
type (with a suitable resolution function) for 1_signal and a control /
arbitration mechanism to coordinate the multiple driver processes to
preclude illegal bus conditions (e.g. multiple conflicting drivers). The
canonic example is a multi-master processor bus, implemented using
Std_Logic_Vector. The most critical point is that no more than one process
drives the bus at any instant; inactive processes, in the SLV case, would
drive 'Z'. Obviously, if SLV / Unsigned / Signed are unsuitable you can
roll your own types.

If a static control / arbitaration mechanism is insufficient, e.g. the
second process represents an interupting source accessing a resource, the
multiple driver processes can be supervised by a suitable protocol. The
canonic (multi-master) arbitration mechanism is to use signals of a resolved
type to implement Arbitration [Cohen] / ForkJoin [Bergeron] - hardware /
software paradigms for the same thing.

You may also care to read up on bus functional models [BFMs].

HTH

Martin

References:
LRM
Resolved types: Cohen; ISBN 0-7923-8474-1; p115ff & p236ff
Arbitration of access to SharedVariables: Cohen; ISBN 0-7923-8115-7; p50ff
(section1.9)
ForkJoin in VHDL: Bergeron; ISBN 1-4020-7401-8; p199ff(sample4-79..)
BFMs:
Cohen; ISBN 0-7923-8474-1; p320ff(s11.1.4) & p327ff(s11.2.1.2)
Cohen; ISBN 0-7923-8115-7; p254(s8.5)
Bergeron: op cit; p137ff (Encapsulating BFMs) & p325ff(VHDL Test Harnesses)

 

[roller]

Hi,

I am writing a VHDL testbench with the following structure:
For the purpose of clarity
I want to assign values to a signal in process A.
When reaching a certain value I want to continue assigning
values to the same signal in a different process B.

you cant, process are concurrent, which one will start?

Is this possible somehow?

yes, somehow

use a mux to select which "temporal" signal driven by each process is going
to drive the "final" one

though, i dont see why you want to do it that way...you could use a single
process, or a FSM...

 

[ivailokroumov]

Dear ALuPin, I can't understand you, why do you want to use two processes
but it's your business. The nature of the processes is that they are
concurently each to other. It does mean that they are work at same time.
The operators whitin the process are sequential. O'K, It it is just as
information. The code that was posted from you, I guess won't produce the
result which you expect. It'll give you error, because you try to conduct
"l_signal" in different process. At first time,the signal would be shared
type. About my opinion , should be better to use code which represent
chain processing of this signal.

A: process
begin
while l_signal < 3 loop
l_signal := l_signal + 1;
end loop;
wait until rising_edge(clk);
end process A

B: process
begin
while l_signal <= 4 loop
l_signal := l_signal + 1;
end loop
wait until rising_edge(clk);
wait;
end process B

Keep in mind that all process are started just one every time when you
start your simulation.