Issues re process suspend/resume and callbacks

Dear colleagues,

This is to alert you to two related issues that have been discussed in the
Accellera VHDL-TC LRM-SC recently. They concern the definition of the
simulation cycle and when certain callbacks are executed. Input is sought
from the VHPI task force to identify requirements. The ISAC then needs to
recommend how to revise the LRM text to implement the requirements. I have
entered these issues into the ISAC tracking system.

The intention is NOT to delay the release of the Accellera draft standard to
the IEEE pending resolution of these issues. It would be approriate for ISAC
to publish interpretations or corrigenda if the draft is approved before the
issues are resolved. Alternatively, if the issues are resolved earlier, they
can be rolled into the IEEE draft.

Cheers,

PA
--


Issue 1. Process resumption and callbacks

The LRM is unclear about precisely when a process is said to
resume. This affects when certain VHPI callbacks are triggered. At
issue is whether a process that is suspended on a wait statement with
an until clause is said to resume only when the condition is true, or
whether is also resumes in order to test the condition.

In 8.1, there is a paragraph:

  The suspended process can also resume as a result of an event
  occurring on any signal in the sensitivity set of the wait
  statement. If such an event occurs, the condition in the condition
  clause is evaluated. If the value of the condition is TRUE, the
  process will resume. If the value of the condition is FALSE, the
  process will resuspend. Such resuspension does not involve the
  recalculation of the timeout interval.

This is unclear. On the one hand, it specifies that when an event
occurs, the condition is evaluated, and if TRUE, the process
resumes. On the other hand, it says that if the condition is FALSE,
the process resuspends. For it to resuspend, it presumably must have
unsuspendend, namely, resumed. So this could be interpreted as saying
the process resumes in order to test the condition.

In 12.6.2, there is the text:

  ... The occurrence of an event will cause the resumption and
  subsequent execution of certain processes during the simulation
  cycle in which the event occurs, if and only if those processes are
  currently sensitive to the signal on which the event has occurred.

This could be interpreted as saying the processes resume upon events,
regardless of any conditions in wait statements being true or
false. That would be consistent with the second interpretation of the
quoted paragraph from 8.1.

In previous versions of VHDL, the distinction between the two
interpretations was not apparent. An implementation could optimize
evaluation of conditions in wait statements to avoid a full process
resumption.

However, in 1076c later, the difference is exposed. In 12.6.4.2 of
1076c, step a) substep 3) specifies:

  For each nonpostponed process P that has resumed in the current
  simulation cycle, each registered and enabled vhpiCbResume callback
  associated with P is executed.

Thus, depending on whether a process with a false condition is
interpreted as having resumed or not, the callback will or will not be
executed.

It is not clear from the LRM which of the two interpretations is
correct. Rather, is a matter of requirements analysis. The VHPI Task
Force needs to consider the issue and recommend which interpretation
is preferred. Based on their recommendation, the quoted sections can
be revised to clarify the intent.


Issue 2. Order of process and callback execution

The LRM specifies an ordering of steps in the simulation cycle that
may be overly restrictive. In 1076-2002, 12.6.4, process execution in
the simulation cycle was specified as:

  d) For each process, P, if P is currently sensitive to a signal, S,
     and if an event has occurred on S in this simulation cycle, then
     P resumes.

  e) Each nonpostponed process that has resumed in the current
     simulation cycle is executed until it suspends.

This allows interleaved execution of the resumed processes. In
1076c-2007, this was changed to incorporate execution of
callbacks. The revised text in 12.6.4.2 is:

  2) For each process, P, if P is currently sensitive to a signal, S,
     and if an event has occurred on S in this simulation cycle, then
     P resumes.

  3) For each nonpostponed process P that has resumed in the current
     simulation cycle, each registered and enabled vhpiCbResume
     callback associated with P is executed.

  4) Each nonpostponed process that has resumed in the current
     simulation cycle is executed until it suspends, and each
     registered and enabled vhpiCbTimeOut and vhpiCbRepTimeOut
     callback whose triggering condition is met is executed.

  5) For each nonpostponed process P that has resumed in the current
     simulation cycle, each registered and enabled vhpiCbSuspend
     callback associated with P is executed.

This specifies that all of the vhpiCbResume callbacks are executed,
then the resumed processes and timeout callbacks are executed, then
the vhpiCbSuspend callbacks are executed. The division into three
steps constrains the available parallelism in a way that may not have
been intended. Moreover, it may prevent certain optimizations of the
way in which processes and callbacks are executed.

An alternative and less constraining approach would be to allow
interleaving of process and callback execution, provided, for each
process that has resumed, any associated vhpiCbResume callback is
executed before the process is executed and any associated
vhpiCbSuspend callback is executed after the process suspends.

Apart from the difference in potential parallelism between these two
approaches, the difference may be exposed to the callback routines. As
the LRM currently stands, the resumption callbacks are guaranteed that
no processes or suspension callbacks have started execution.
Similarly, the suspension callbacks are guaranteed that all
resumption callbacks have completed and all processes have
suspended. A VHPI program may be written in a way that depends on
these assumptions. Should the ordering be relaxed, the assumptions
would no longer hold.

Input is sought from the VHPI task force whether the relaxed ordering
is permissible or desirable. If the VHPI task force recommends
adoption of the relaxed ordering, the ISAC can revise the LRM to
implement that intent.

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone: +61 8 7127 0078
Australia                     Mobile: +61 414 70 9106


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