Re: P1666 Ballot resolution discussion - Part 2

All,

The next set of issues arising from the OSCI Proof-of-concept work was a
set of clarifications to the wording of the LRM. There are NO changes of
intent here. The people involved (Andy, Bishnupriya, Philipp, and myself)
were unanimous concerning the proper interpretation of the LRM, but agreed
that the existing LRM wording was somewhat ambiguous in each case.

I am not expecting anyone to object to the following clarifications, but
comments are always welcome, of course.

5.3.4.2 Function sc_start

Clarify the LRM with respect to the corner case where the very first call
to sc_start has a zero-valued time argument. The description of
sc_start(0) says the scheduler shall run an evaluation phase, an update
phase, and a delta notification phase. The clarification is that for the
very first call to sc_start, the scheduler shall instead run the
initialization phase (as described in an earlier paragraph).

Clarify the LRM with respect to the case where sc_start is called with a
non-zero time argument. The clarification concerns the case where there is
no timed notification phase occurring precisely at the end time. The
scheduler shall execute up to the most recent timed notification phase
occurring before or at the end time.

5.3.4.2 Function sc_start
5.5.7 Functions to detect pending activity

Consider:

int sc_main( int, char*[] )
{
  ...

  while( sc_pending_activity() ) {
    sc_start( sc_time_to_pending_activity() ); // Never executed
  }

  return 0;
}

By default sc_pending_activity() will return false, so sc_start would not
be called in the example above. We propose to make this clear in the LRM
by adding an example such as the following:

int sc_main( int, char*[] )
{
  ...
 
  sc_start( SC_ZERO_TIME ); // Run up to initialization phase and create
pending activity in the first delta cycle
 
  while( sc_pending_activity() ) {
    sc_start( sc_time_to_pending_activity() );
  }

  return 0;
}

6.6.6

Clarify the LRM with respect calls to sync_reset_on and throw_it where
their argument is set to SC_INCLUDE_DESCENDANTS: although such calls to
method processes have no effect on the process itself, the calls shall
still be propagated down to any and all descendant processes regardless of
whether their ancestors are thread or method processes.

6.6.6.2 disable and enable

Clarify the LRM to say that if a process is disabled during elaboration
and subsequently enabled during simulation, the call to enable shall not
cause the process to be run: the process will only run when triggered by
its static sensitivity, if any.

6.6.6.6 Class sc_unwind_exception

The LRM describes side-effects caused by destructors as a result of calls
to kill or reset. Clarify the LRM to emphasize that calls to kill, reset
and throw_it can in general be chained, that is, called as a result of
unwinding a process (side-effects are not restricted to destructors).

Moreover, the LRM says that "care should be taken to avoid mutual
recursion". Clarify the LRM to say that since calls to kill, reset and
throw_it take immediate effect, the call chain may get interrupted by a
process killing or resetting itself, which could happen directly or
indirectly as a result of killing or resetting an ancestor of the calling
process. In particular, an immediate call that has SC_INCLUDE_DESCENDANTS
could get interrupted by itself getting killed or reset.

6.6.6.10 throw_it

Clarify the LRM to say that throw_it should remove any dynamic sensitivity
(in the same way as it does for reset)

Clarify the LRM to say that the para starting "throw_it is only applicable
when the target process instance has been suspended" also applies to
processes that are in the set of runnable processes. Moreover, when the
target of throw_it is a runnable process, throw_it shall remove the target
from the set of runnable processes.

6.6.7 sc_get_current_process_handle

Clarify the LRM in the case where sc_get_current_process_handle is called
from a process that is unwinding as a result of a call to kill(), reset(),
or throw_it(). The clarification is that when called from the target
process (of such a process control method call),
sc_get_current_process_handle shall return a handle to the target process,
not a handle to the caller of the process control method. (Hence function
sc_is_unwinding is well-defined.)

6.8.5
int size() const;

Clarify the LRM in the case where an event list contains duplicate events:
duplicates do not count toward the value returned by size.

6.10.4 Constructors, destructor, and event naming
virtual ~sc_event();

The destructor is NOT virtual.

The wording should be clarified to include the removal of top-level events
as well as events that have a parent in the object hierarchy.

John A

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