Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   Re: Two processes writing one signal (http://www.velocityreviews.com/forums/t21359-re-two-processes-writing-one-signal.html)

Jonathan Bromley 06-30-2003 10:27 AM

Re: Two processes writing one signal
 

"Jeremy Pyle" <jeremyp@rochester.rr.com> wrote
in message news:mSNLa.6780$4J6.5280@twister.nyroc.rr.com...
> Ok, I got a problem. I have two processes inside an architecture writing
> the same signal. One process runs at startup and initializes the signal
> while the other one runs after that, it's guaranteed that they never run

at
> the same time. However, when I simulate it the signal, which is local to
> the architecture, never leaves the U value. If I comment out the write in
> the second process(not the initialization one), then the signal changes

like
> it's supposed to. I know if two modules both write to one data bus then
> when one is writing the other must write all Z's, is this also true for
> signals in an architecture?
> I realize a way to fix this is to just have them both write from the same
> process, but I want to make sure I understand it, because I'm sure it's in
> other places too.


A signal is not the same as a Verilog register! Each process that drives
a VHDL signal represents a driver on that signal. Each driver has its
own copy of the value that its process is trying to drive. So, your
"initialisation" process is trying to drive (let's say) '0'. But the
other process starts by trying to drive 'U', because that's the default
initial value for any STD_LOGIC driver. The 'U' wins the conflict.
I guess that your "working" process was expecting to see your
desired initialisation value, not 'U', so it gets confused. In
any case this wouldn't work because whatever the second process
does, the "init" process is permanently trying to drive '0'
on to the signal.

The bottom line is that code in one process cannot influence the
values that are driven from within another process.

Since this is presumably a test bench, it's completely reasonable
to get rid of the "initialisation" process altogether, and
give the signal an initial value as part of its declaration:

architecture foo of bar is
...
signal S: std_logic := '0';
...
begin
...
process begin
loop
wait for 5 ns;
S <= not S; --- OK because S is initially '0'

This has the added advantage that the signal initialisation
is guaranteed to take effect BEFORE any process starts to
run, whereas your "two process" initialisation will suffer
from the problem that the initialisation would not take
effect until one delta time after the start of simulation.

So, you are right: the correct fix is to do everything in
one process.

If you're worried about this, you could consider declaring
your signals as STD_ULOGIC. This is an unresolved type,
and you'll get an explicit error message from the simulator
if more than one process drives a signal of such type.

HTH
--
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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





All times are GMT. The time now is 07:30 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.