Discussion of IR 2123: Process resumption and callbacks

I'll start thing going. Although I have discussed these issues in 
general with Ajay, this represents my own
opinion. Others will have to state their individual opinions. Also, I 
don't vote on ISAC issues, unless
there is a tie, which hasn't occurred for many years.

The IR deals with the technical issue of exactly when in the simulation 
cycle a process resumes. Specifically,
does it resume when an event occurs on a signal in the sensitivity 
clause or when such an event occurs and,
in addition, the condition clause evaluates to TRUE. Currently, this is 
important only for determining when
a vhpiCbResume occurs (and possibly when a corresponding vhpiCbSuspend 
occurs).

The VHPI indicated that a suspended process resumes (proposed LRM 
wording) "as a result of an event occurring on any signal
in the sensitivity set of the wait statement...."

In addition to this decision, the VHPI also stated (proposed LRM wording)  

 "An implementation may optimize execution of a wait statement in such
  a way as to obviate some or all resumptions of the suspended process
  due to events on signals in the sensitivity set provided that, when
  an event occurs on any signal in the sensitivity set and that event
  would result in the condition in the condition clause evaluating to
  TRUE, the process does resume."

This change is worrisome to me. I think that it is poor language design 
because it allows non-portable implementations
at the wrong level. The VHPI has many implementation dependent features, 
but,
as far as I can tell, no others that affect whether or not a callback is 
made. I can
think of two similar situations. First, many optimized executions do not 
do "required"
range checks. I believe that this is perfectly acceptable, but we don't 
add wording
to the standard stating that such implementations may skip these tests. 
The second situation is
event suppression. At first I was going to say that no simulation would 
ever suppress an event,
but I realized that for performance reasons events are often suppressed, 
but only if their suppression
is not detectable to the user. In my opinion, the proposed paragraph 
exposes a detectable non-portable
situation.

The ISAC believed that VASG voters should be aware of this situation 
when they vote on this proposed language
change.

There are some secondary issues which will probably come to the surface 
in this discussion, but I'm trying to concentrate on the
most important cause of contention.

Chuck Swart



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