RE: "Scheduling Insights" for Process Control Constructs

Bishnupriya,

It always struck me as odd that resume had its effect in the next delta
cycle, because this is the only mention of delta cycles in the scheduling
semantics of the process control extensions, and delta cycle behavior is
usually associated with primitive channels. It would seem more consistent
if resume were to cause the process to be runnable in the current
evaluation phase. It also means that

p.suspend();
p.resume();

would become a null statement in effect, without the need for any special
case. So I would be in favor of this change.

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
03/09/2010 11:26
Subject:
RE: "Scheduling Insights" for Process Control Constructs

John,
 
I'm not entirely happy with this scenario either. This is the case that
prompted me to write up the "Scheduling Insights" section. Does that give
you any insights on why it is what it is? One purpose of that section is
to "enable the LRM writers to determine if the LRM rules for the process
control constructs are accurate and complete".
 
I believe the rules do come out consistent, if resume() causes
resume_event to be notified immediately, i.e. w/o the delta cycle delay.
Then the lines below become
 
"The effect of resume() shall be the same as immediately notifying the
resume_event that the target process was sensitive to".
 
"Note that if a process is already scheduled, and then suspended and also
resumed before it executes, it shall still execute in the current delta
cycle, following the rules laid down here".
Do you (or anyone else) see any gotchas with notifying the resume_event
immediately? In the original specification, there wasn't a strong reason
to make the notification be with a delta delay, we went with one of the 2
choices. I quickly tried out this change in the Cadence implementation,
and the house didn't break down - as expected, there were process
execution order changes in a couple of tests.
 
Thanks,
-Bishnupriya
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, September 02, 2010 8:05 PM
To: Bishnupriya Bhattacharya
Cc: systemc-p1666-technical@eda.org
Subject: Re: "Scheduling Insights" for Process Control Constructs

Bishnupriya,

Aaaagh! 8=)

The spec says "The effect of resume() shall be the same as notifying the
resume_event that the target process was sensitive to, with a delta cycle
delay."

You have now added "If a process is already scheduled, and then suspended
and also resumed before it executes, there shall be no effect on the
process, and it shall execute in the current delta cycle as if the
suspend() and resume() have cancelled each other."

These two statements seem mutually contradictory to me.

p1.resume(); // means make runnable in the next eval phase (with a delta
delay)

p2.suspend();
p2.resume(); // means make runnable in the current eval phase

Duh? You are effectively saying that resume() has a history; it remembers
whether or not the process was suspended at the start of the current eval
phase.

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>,
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Date:
02/08/2010 07:27
Subject:
"Scheduling Insights" for Process Control Constructs

John, All,
  
As promised, here is an updated process control spec with a new section 4
"Scheduling Insights" - the intent is this section will further augment
and clarify the current content. Besides the addition of this section,
I've also made some minor modifications. The complete list of changes is
described below. Change bars are turned on, so the changes are easy to
find.
  
Note that the changes do not include any of the
clarifications/modifications that have already happened as part of the
p1666 discussions so far.
  
Thanks,
-Bishnupriya
Any place that mentions behavior for "before simulation has started" has
been augmented to also include "before the process has executed for the
first time" to include spawned processes
clarification provided for suspend-resume if process is already scheduled
the behavior of disabling a process before it has executed for the first
time has been modified to align with the behavior of disabling an already
scheduled process - rationale being if dont_initialize() has not been
specified then the two cases are the same
clarification provided for reset() on currently executing process
behavior of sync_reset_on() on a process before it has executed for the
first time was inaccurately stated - it has been corrected
for some MSWord inexplicability, Section 3 had to be copied and re-pasted;
so it is showing up as a change, actually it is the same as before
added Section 4 "Scheduling Insights"
 
 
-------------------------------------------------------------------------------------------------------------------------------------

    Bishnupriya Bhattacharya | R&D - SystemC Simulation, Debug &
Analysis | Cadence
    P: +91.80.4184.1197 www.cadence.com
-------------------------------------------------------------------------------------------------------------------------------------

 [attachment "ProcessControlLWG_July2010.doc" deleted by John
Aynsley/doulos]

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.