RE: Event starvation

I don't see any particular problems with this. The workarounds are fairly straight forward.

Tor

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Friday, November 19, 2010 4:37 AM
To: systemc-p1666-technical@eda.org
Subject: Event starvation
Folks,
A few of us have been having a side conversation about how we incorporate sc_pause into the scheduler. One issue that we have thrown up that I would like to refer back to everyone is what happens on event starvation.
As we have already discussed, the current OSCI sim does this...
sc_start(100, SC_NS);  // Event starvation at sc_time(50, SC_NS)
sc_assert( sc_time_stamp() == sc_time(100, SC_NS) );
We have proposed making the following change
sc_start(100, SC_NS); // Event starvation at sc_time(50, SC_NS)
sc_assert( sc_time_stamp() == sc_time(50, SC_NS) );
This is a change to 1666-2005 and is not backward compatible with the current OSCI sim, but we believe it is the better solution. The old behavior can be achieved as follows:
ev.notify(100, SC_NS);
sc_start(100, SC_NS); // Simulation will run for the full 100 ns
Is everyone okay with this change?
Thanks,
John A
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.