RE: Draft P1666 LRM for review - updated

Hi John,

Thanks for the explanation.

So if the main motivation is implementation then why note leave the
whether the semantics of the process control is immediate implementation
dependent?

In this way deterministic and parallelizable implementations can be
standard compliant.

Regards

Yossi

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, January 14, 2011 12:00 PM
To: Veller, Yossi
Cc: systemc-p1666-technical@eda.org; bpriya@cadence.com;
philipp.hartmann@offis.de
Subject: RE: Draft P1666 LRM for review - updated

Hi Yossi,

Yes, you've made that point before, and it is a valid one.

Back in the early days, we did have a long and very explicit discussion
about the immediate process control semantics, including reset(). Some
of us thought that having delta cycle semantics throughout the process
control extensions was the more natural approach, others thought that
immediate semantics were right. We had the debate, and the conclusion
was to go with the immediate semantics. Part of the rationale was that
the process control extensions with immediate semantics have been
prototyped and proven over a period of years (by Cadence and in the OSCI
PoC simulator), and we did not want to rip the whole thing up.

Practically, I do not think anyone (apart from you, clearly) is
motivated to go in this direction right now, but people will have to
speak for themselves...

Cheers,

John A

From:

"Veller, Yossi" <Yossi_Veller@mentor.com>

To:

<john.aynsley@doulos.com>

Cc:

<systemc-p1666-technical@eda.org>

Date:

14/01/2011 02:30

Subject:

RE: Draft P1666 LRM for review - updated

________________________________

In 6.2.12 and 6.6.6.4 there is a reference for reset call and others
having an immediate affect or during the current evaluation phase.
  
Immediate notification is a source for dependence of the simulation
results on the simulator's scheduler and a basis for non parallelizable
code (e.g. in such an implementation the reset action may come after the
reset thread executes or before) . SystemC had chosen to provide
immediate notification for the user to use upon his/her responsibility.
However immediate notification should not be a 'standard' behavior of
operations provided by the kernel.
  
Then unless there are compelling reasons, e.g. from simulation speed
degradation, I believe that the kill and reset effects should be delayed
to the next evaluation phase.
The same should be applied to suspend (even though it becomes very close
to disable).
  
Regards
Yossi
  
From: owner-systemc-p1666-technical@eda.org
[mailto:owner-systemc-p1666-technical@eda.org
<mailto:owner-systemc-p1666-technical@eda.org> ] On Behalf Of
john.aynsley@doulos.com
Sent: Friday, October 01, 2010 11:15 AM
To: systemc-p1666-technical@eda.org
Subject: Draft P1666 LRM for review - updated
  
Folks,

I have posted an updated version of the P1666 draft LRM on

       http://www.eda.org/twiki/bin/view.cgi/P1666/WebHome
<http://www.eda.org/twiki/bin/view.cgi/P1666/WebHome>

This includes the process control extensions and sc_max_time. Just
search for "ADDITION"

Please review and provide your feedback.

You can also check the status of the plan from this same web page

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.