signal assignment

[Ronan Guivarc'h]

Hello,

i discover something strange today concerning signal assignment.
I used to think that when a signal is reevaluated at time t,
the computed values of the future of t are destroyed and we computed
new ones with their delay assigment. Until the following example

entity evaluation is
end evaluation;

architecture arch_evaluation of evaluation is

signal A : integer := 0;
signal B : integer := 10;

begin

A <= 1, 2 after 10 ns;

process

begin
wait on A;
if(A = 1) then
B <= 2 after 30 ns;
elsif(A=2) then
B <= 2 after 25 ns;
end if;
end process;

end arch_evaluation;

I thought that
- the first assignment of A would produce the estimate of B
with the value 2 at 30 ns
- the second assignment of A (before 30 ns then before B assignment)
would destroy this estimate and produce the estimate of B
with the value 2 at 35 ns.

Then B would be assigned only at time 35 ns

In fact with my simulators (nclaunch or simili), B is assigned at 30 ns.

And when i put two different values in B,

if(A = 1) then
B <= 2 after 30 ns;
elsif(A=2) then
B <= 4 after 25 ns;
end if;

B is only assigned at 35 ns with the value 4 (the first estimate is
destroyed)

Is it normal ?
what is the physical explanation ? My example has perhaps no physical
reality ?

thanks for your answers

Ronan

 

[Jonathan Bromley]

On Thu, 10 Feb 2005 16:32:56 +0100, Ronan Guivarc'h
<Ronan.Guivarch@enseeiht.fr> wrote:

i discover something strange today concerning signal assignment.

You have discovered the defined behaviour of inertial
assignment in VHDL.

what is the physical explanation ?

That's the way VHDL defines it. Future assignments *to the same
value* do not overwrite earlier assignments. It is done that
way to provide an approximation to the behaviour of RC delays.

My example has perhaps no physical reality ?

Indeed it does not; but neither has anything else in a digital
simulator The rules are set up to make typical examples
behave in a physically sensible way, without the need for
full analogue simulation.

For some styles of modelling you may find it's better to use
transport delay:

y <= TRANSPORT newvalue after T;

This adds a scheduled assignment after time T without
affecting existing scheduled assignments.
--
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, 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.