Signal transactions


T

Tim Frink

Hi,

assume this VHDL entity is given:

ARCHITECTURE behaviour OF example IS
SIGNAL x : BIT := '0';
BEGIN
p:pROCESS
BEGIN
x <= '1' AFTER 2 ns;
x <= '1' AFTER 4 ns;
x <= '1' AFTER 6 ns;
WAIT ON a;
END PROCESS p;
END behaviour;

When I simulate this program, I get a waveform
where signal x is set to '0' at time t=0 and then
sets x to '1' at time t=6. Due to the inertial model
I would assume that x is set to '1' at t=4 because
the inertial model keeps only the current transaction, the
previous transaction with same value (here x=1 at t=4) and
the current transaction. So, for "x <= '1' AFTER 6 ns;"
the transaction at time t=0, t=4 and t=6 would be
kept and the first transaction in p (x <= '1' AFTER 2 ns;)
would be deleted.

Any ideas what I did wrong?

Regards,
Tim
 
Ad

Advertisements

K

KJ

Tim Frink said:
Hi,

assume this VHDL entity is given:

ARCHITECTURE behaviour OF example IS
SIGNAL x : BIT := '0';
BEGIN
p:pROCESS
BEGIN
x <= '1' AFTER 2 ns;
x <= '1' AFTER 4 ns;
x <= '1' AFTER 6 ns;
WAIT ON a;
END PROCESS p;
END behaviour;

When I simulate this program, I get a waveform
where signal x is set to '0' at time t=0 and then
sets x to '1' at time t=6. Due to the inertial model
I would assume that x is set to '1' at t=4 because
the inertial model keeps only the current transaction, the
previous transaction with same value (here x=1 at t=4) and
the current transaction. So, for "x <= '1' AFTER 6 ns;"
the transaction at time t=0, t=4 and t=6 would be
kept and the first transaction in p (x <= '1' AFTER 2 ns;)
would be deleted.

Any ideas what I did wrong?

Couple of things. The signal assignments inside a process do not take
effect until either the process completes or it hits a wait statement.
Second with the inertial model, any signal assignments basically 'wipes out'
any previous assignments.

So at t=0, the simulator runs across three assignments to signal 'x'.
Effectively, only the last assignment gets scheduled and when you hit the
'wait on a' statement, the signal will actually get updated.

Lastly, it's not clear what you're trying to accomplish in the first place
by continually setting x to 1

To do what it appears you are trying to do you need the following

x <= '1' after 2 ns, '1' after 4 ns, '1' after 6 ns;

Kevin Jennings
x <' 1' after 2 ns
 
T

Tim Frink

Sorry, I forgot to mention that signal a is set from 0 to 1
at time 10.
Couple of things. The signal assignments inside a process do not take
effect until either the process completes or it hits a wait statement.
Second with the inertial model, any signal assignments basically 'wipes out'
any previous assignments.

So at t=0, the simulator runs across three assignments to signal 'x'.
Effectively, only the last assignment gets scheduled and when you hit the
'wait on a' statement, the signal will actually get updated.

This was what I would also expect. However, the last assignment (x <= '1'
AFTER 6 ns;) did not remove the first assignment (x <= '1' AFTER 2 ns;)
because signal x is set to '1' at t=2 and not! t=4. It seems to me that
the inertial model keeps all (not the last) transactions with the same
value w.r.t. the current transaction.
Lastly, it's not clear what you're trying to accomplish in the first
place by continually setting x to 1

This was just an example with no real purpose.

Tim
 
Ad

Advertisements

K

KJ

On Tue, 05 Feb 2008 12:07:10 +0000, KJ wrote:


This was what I would also expect. However, the last assignment (x <= '1'
AFTER 6 ns;) did not remove the first assignment (x <= '1' AFTER 2 ns;)
because signal x is set to '1' at t=2 and not! t=4.

In your original post you said "x is set to '0' at time t=0 and then
sets x to '1' at time t=6"...which is different than what you're
saying now.
It seems to me that
the inertial model keeps all (not the last) transactions with the same
value w.r.t. the current transaction.

Inertial delays have to do with rejecting pulses (i.e. different
values being assigned at different times to a signal). If the value
being assigned doesn't change then it can't be considered a 'pulse' so
the earlier assignment at t=2 ns wouldn't get tossed by the
assignments at 4 ns or 6 ns since neither assignment is attempting to
change the value of signal x.

So I was a bit off on my first post. Earlier scheduled inertial
assignments to a signal that have not occurred only get tossed if the
new assignment is going to assign a different value than the one that
is currently scheduled. I'm not quoting the LRM on this, perhaps
someone else can chime in on the exact verbage, chapter and verse.
This was just an example with no real purpose.

OK, but persuit of knowledge should not be considered 'no purpose'
either.

Kevin Jennings
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top