One simulation difference is that signals in a process all get updated at
the end of the process....sooo..
a <= b and c; -- #1
d <= e and f; -- #2
You have no 'control' over whether #1 or #2 gets evaluated first so there
may be a simulation delta time between when signals 'a' and 'd' change.
If you have the same statements within a process (with the appropriate
sensitivity list of course) then 'a' and 'd' will always change at the exact
same time on the same simulation delta time as well.
It's very rare where this subtle difference makes any difference at all.
I've never needed it when writing code that needs to be synthesizable, I
have in a couple instances used this when writing non-synthesizable
simulation models...unfortunately the situation where it was useful escapes
me just now but since you're asking a 'basic VHDL question' my guess is that
you won't run across a need for this for a while if ever.
From a synthesis perspective it makes no difference, both ways will produce
the same result.
From a practical standpoint, just putting the equations without a process is
somewhat cleaner since you don't have to check (and recheck) that you have
all the appropriate signals in the sensitivity list. For example, look at
the following code. If you run with a proper simulator, signal 'd' will not
get updated when signal 'e' and 'f' change...unless they happen to be
coincident with signals 'b' and 'c' changing since only 'b' and 'c' are in
the sensitivity list so the process only gets executed when there is a
change to either 'b' or 'c'.
a_proc
rocess(b,c)
begin
a <= b and c; -- #1
d <= e and f; -- #2
end process;
If you take this code and synthesize it, your synthesis tool will probably
kick out a warning about an incomplete sensitivity list and implement what
you had probably had intended all along (i.e. 'd' will get updated when
either 'e' or 'f' change. Although that is probably what you had intended
it does mean that what gets compiled into your physical device will not be
the same thing that you're seeing in simulation. From my perspective having
simulation not matching reality is a bad thing. As a general guideline I
personally tend to avoid processes other than clocked processes for just
this reason....much less chance for mucking up something since of course
'real' code will not be quite so easy to spot that signals are missing from
the sensitivity list.
KJ