[Fwd: Re: Is there an ISAC meeting today?]

Should we meet?
John and Francoise can't attend,  and
the primary reason for the meeting is to
get feedback from VHPI.

Chuck Swart


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

attached mail follows:

Thanks, but
 
I cannot attend, it will be 11 pm my time and I just moved into my new
house
I do not have a phone yet... 
 
John can represent the VHPI opinion.
 


________________________________

	From: Chuck Swart - MTI [mailto:cswart@model.com] 
	Sent: Thursday, April 03, 2008 5:01 PM
	To: Francoise Martinolle
	Subject: Re: Is there an ISAC meeting today?
	
	
	Francoise Martinolle wrote: 

		Can you send the teleconference # if the VHPI is going
to be discussed?
		 
		Francoise
		       '

	Telecon info (same as always) 
	US 800-637-5822 
	Other +1 647-723-3937 
	Access Code 6850821 
	
	the meeting is scheduled for 8pm Pacific daylight time.
	I'm attaching the IR and including John's comments.
	
	To get to the IRs go to eda.org
	click on ISAC then select
	Issue reports for the VHDL-2002 revision
	
	John's comments:
	
	

		Hi Chuck, 
		
		I am sorry but I find this flawed.  first, your comment
in the first paragraph may be a representation of a perceived problem,
but also speaks to a profound misunderstanding of the intent of the
callback. I know it came from Ajay and I think Francoise should have
that information.  She may wish to discuss it with him. For you not to
state a balanced view calls to question the ability of the ISAC to
evaluate the specification in this area.  Your judgment as the "double
indeterminacy making the callback potentially less useful"  is
particularly  unbalanced. 
		
		I also find the analysis flawed. It misrepresents the
VHPI position and hides rationale in its summary, and shows some
misunderstanding of, or ignoring, the purpose of the callback.  I can
accept the misunderstanding.  It is the LRM strategy to approach this
problem by specifying VHDL resumption in this way, and to be silent
about non-determinism. It is an artificial point in the simulation cycle
that indeed has healthy non-determinism with no bad behavior inherent in
exploiting it. Too bad non-determinism is a dirty word. Fine, you said
it a different way.  But then it is incumbent upon the author not to
hide the real rationale that VHPI had. It is a disservice to any who
would wish to review and understand this in proper perspective.  That
part disturbs me. I presume that, in part, is why some ISAC reviewers
see this in a bad light. IMHO, your comments only make it worse in some
noble attempt to appease someone. 
		The LRM text revision itself is well done, given the
considerations.  The note in 8.1 could have reflected that VHPI
callbacks match the optimized behavior (which is the intent and has
value), but instead it is just cast as fact and left to perceive whether
that is a flaw. It is OK, but not great. If you want to appreciate the
change, read the isac analysis and your comments, accept them as expert
opinion, and then you almost have to view this as flawed decision.  If
you believed that, you should have pushed it back. 
		I trust you will convey to the ISAC my disappointment in
the way this has been done. 
		
		Regards, John 
		
		
		Chuck Swart - MTI wrote: 
		The attached comment will be added to the analysis of
this IR. Please review this ASAP and 
		let me know of any changes you wish to make. I am
including the most recent version of the IR also. 
		
		Chuck Swart 
		


	Finally, here is the comment which I proposed and John responded
to:
	
	

		[Comments added by Chuck Swart as a result of ISAC
review:
		
		Several ISAC members are concerned that the callback
triggers are
		optional under optimized implementations. This implies
that when an
		application receives such a callback, the condition may
or may not be
		true. Also, when the condition is false, the callback
may or may not
		be executed. This double indeterminacy makes such a
callback
		potentially non portable and less useful.
		
		In response, there are several things that the
application can do to
		avoid this issue. The situation in which the callback is
not executed
		applies only to optimized implementations, so the
application could
		choose to disable (some) optimizations.  Also, instead
of a resume
		callback, the application could place a callback on the
statement
		after the wait statement.(This callback would also be
executed when
		the timeout expired.)
		
		The proposed LRM change affects only callbacks related
to VHPI, and
		thus does not introduce any new indeterminism outside of
VHPI
		applications. The VHPI working group has carefully
considered the
		possible solutions and has determined that flexibility
in optimized
		implementations is more important that avoiding a
relatively rare
		potential indeterminacy.
		
		Since the VHPI has deliberately chosen this solution,
the ISAC
		recommends that their decision be accepted.]