deleting old transactions

J

JohnSmith

Guest
The following code schedules transaction for 200 ns. It will be
removed by the simulator? (it seems). When there are some transactions
which time stamp is greater than the newly scheduled transaction, all
will be removed?

----------------------
library ieee;
use ieee.std_logic_1164.all;

entity test is
end test;

architecture arch of test is
signal a: std_logic := '0';
signal b: std_logic;
begin

a <= not a after 70 ns;

process(a)
variable w: integer := 1;
begin
if w = 1 then
b <= '1' after 200 ns;
w := 2;
else
b <= '0' after 100 ns;
end if;
end process;

end arch;
-------------------

Thanks
 
On Sep 26, 11:25 pm, JohnSmith <csnew...@gmail.com> wrote:
The following code schedules transaction for 200 ns. It will be
removed by the simulator? (it seems). When there are some transactions
which time stamp is greater than the newly scheduled transaction, all
will be removed?
Click to expand...
That's right. Think of the basic mechanism this way: for each process,
there's a time-ordered list of "current" transactions that have
already been scheduled. If this list only has one entry, that reflects
just a plain old assignment (no time specified) that has taken place.
When you execute an assignment statement, the statement provides a
"new" list (which may be as simple as one transaction, or could be a
longer list). Executing the assignment basically corresponds to
"merging" the two lists. The merging first shortens the "current" list
by deleting transactions later than the earliest transactions
specified in the assignment, then concatenating the "new" list onto
the end of the shortened "current" list. Then there's also some
fiddling that needs to happen to handle the "pulse rejection" limit
semantics.

As an aside, this "list" I'm talking about is exactly what VHDL calls
a "driver" for a signal.

In your example code, the 200 ns transaction is scheduled, but then
the next assignment runs at t=70 ns, which schedules a transaction for
170 ns. This wipes out the 200 ns transaction as I described above.

I think you may see different behaviour depending on the period of the
clock, because when the clock is very large, the list will always be a
singleton element when the assignment is executed, whereas with a
shorter clock, the list will variously have 1,2 (maybe 3?) elements as
the two assignments execute at different times.

Don't beat me up about the details too much - they're not 100%
accurate - I'm just trying to convey the basic idea :)

- Kenn
 
On 27 Sep, 04:25, JohnSmith <csnew...@gmail.com> wrote:
The following code schedules transaction for 200 ns. It will be
removed by the simulator? (it seems). When there are some transactions
which time stamp is greater than the newly scheduled transaction, all
will be removed?

----------------------
library ieee;
use ieee.std_logic_1164.all;

entity test is
end test;

architecture arch of test is
 signal a: std_logic := '0';
 signal b: std_logic;
begin

 a <= not a after 70 ns;

 process(a)
  variable w: integer := 1;
 begin
  if w = 1 then
   b <= '1' after 200 ns;
   w := 2;
  else
   b <= '0' after 100 ns;
  end if;
 end process;

end arch;
-------------------

Thanks
Click to expand...
As a point to note, Modelsim doesnt always delete transactions.
Consider the following:

process
begin
a <= false, true after 1000 ns;

wait for 500 ns;

a <= false;

wait;
end process;

The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.
 
Tricky wrote:

As a point to note, Modelsim doesnt always delete transactions.
Consider the following:

process
begin
a <= false, true after 1000 ns;

wait for 500 ns;

a <= false;

wait;
end process;

The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.
Click to expand...
I don't understand your comment. The second assignment *does* remove the
transaction at 1000 ns, that's why a does not become true. 500 ns is
earlier than 1000 ns. Modelsim is correct,

regards
Alan

--
Alan Fitch
Doulos
http://www.doulos.com
 
Tricky wrote:
On 29 Sep, 11:06, Alan Fitch <alan.fi...@spamtrap.com> wrote:
Tricky wrote:

As a point to note, Modelsim doesnt always delete transactions.
Consider the following:
process
begin
a <= false, true after 1000 ns;
wait for 500 ns;
a <= false;
wait;
end process;
The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.
I don't understand your comment. The second assignment *does* remove the
transaction at 1000 ns, that's why a does not become true. 500 ns is
earlier than 1000 ns. Modelsim is correct,

regards
Alan

--
Alan Fitch
Douloshttp://www.doulos.com

But why does the simulation continue, when it should halt at 500ns?
Click to expand...
Sorry, I see what you mean. Let me try it...
Alan

--
Alan Fitch
Doulos
http://www.doulos.com
 
Tricky wrote:
On 29 Sep, 11:06, Alan Fitch <alan.fi...@spamtrap.com> wrote:
Tricky wrote:

As a point to note, Modelsim doesnt always delete transactions.
Consider the following:
process
begin
a <= false, true after 1000 ns;
wait for 500 ns;
a <= false;
wait;
end process;
The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.
I don't understand your comment. The second assignment *does* remove the
transaction at 1000 ns, that's why a does not become true. 500 ns is
earlier than 1000 ns. Modelsim is correct,

regards
Alan

--
Alan Fitch
Douloshttp://www.doulos.com

But why does the simulation continue, when it should halt at 500ns?
Click to expand...
Hallo Tricky,
I had a look at the LRM (sections 8.4 and 12.6) and it looks like
you're correct, the simulation should stop at 500 ns.

I tried Modelsim and Cadence Incisive, and both simulate to 1000 ns. I
tried Aldec, and that simulates to 500 ns.

regards

Alan

--
Alan Fitch
Doulos
http://www.doulos.com
 
On 29 Sep, 11:06, Alan Fitch <alan.fi...@spamtrap.com> wrote:
Tricky wrote:

As a point to note, Modelsim doesnt always delete transactions.
Consider the following:

  process
  begin
    a <= false, true after 1000 ns;

    wait for 500 ns;

    a <= false;

    wait;
  end process;

The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.

I don't understand your comment. The second assignment *does* remove the
transaction at 1000 ns, that's why a does not become true. 500 ns is
earlier than 1000 ns. Modelsim is correct,

regards
Alan

--
Alan Fitch
Douloshttp://www.doulos.com
Click to expand...
But why does the simulation continue, when it should halt at 500ns?
 
On Sep 29, 9:38 am, Alan Fitch <alan.fi...@spamtrap.com> wrote:
Tricky wrote:
On 29 Sep, 11:06, Alan Fitch <alan.fi...@spamtrap.com> wrote:
Tricky wrote:

As a point to note, Modelsim doesnt always delete transactions.
Consider the following:
  process
  begin
    a <= false, true after 1000 ns;
    wait for 500 ns;
    a <= false;
    wait;
  end process;
The 2nd assignment to "a" should remove the first timed assignment,
but in modelsim it doesnt, so the simulation runs for 1000ns but "a"
does not become true at 1000 ns. I have raised this with Mentor but
they say this is how they have chosen for their simulator to work.
Afaik, this wont happen in Active HDL.
I don't understand your comment. The second assignment *does* remove the
transaction at 1000 ns, that's why a does not become true. 500 ns is
earlier than 1000 ns. Modelsim is correct,

regards
Alan

--
Alan Fitch
Douloshttp://www.doulos.com

But why does the simulation continue, when it should halt at 500ns?

Hallo Tricky,
   I had a look at the LRM (sections 8.4 and 12.6) and it looks like
you're correct, the simulation should stop at 500 ns.

I tried Modelsim and Cadence Incisive, and both simulate to 1000 ns. I
tried Aldec, and that simulates to 500 ns.

regards

Alan

--
Alan Fitch
Douloshttp://www.doulos.com
Click to expand...
I found a similar effect with a wait until... for statement. Removing
transactions does not necessarily remove associated events. I suppose
such an optimization is possible, but probably introduces more
overhead into the task of removing transactions, which may be a losing
battle (takes more time to try to optimize than it will ever save). At
any rate, the extra execution time on the simulator to do one more
event is negligible. It just looks funny when your waveforms have this
long quiet time at the end.

Andy
 
On Sep 29, 2:46 pm, Andy <jonesa...@comcast.net> wrote:
I found a similar effect with a wait until... for statement. Removing
transactions does not necessarily remove associated events. I suppose
such an optimization is possible, but probably introduces more
overhead into the task of removing transactions, which may be a losing
battle (takes more time to try to optimize than it will ever save). At
any rate, the extra execution time on the simulator to do one more
event is negligible. It just looks funny when your waveforms have this
long quiet time at the end.

Andy
Click to expand...
Optimizing transacations when there's no change to the outputs and
state of the simulation is reasonably safe. But it's easy to see that
this particular change can be unsafe. I think I could write a test,
something in a process like

wait for 1250 ns;
assert a'quiet(500 ns) report "txn not deleted";

This could clearly affect the simulation output and would then be a
simulator bug.

- Kenn
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top