RE: [sv-cc] Updated 1716 proposal (rand/randc)

Ralph,
 
What does "the C portion of the DPI interface" refer to?
 
-- Is this the part of the client application that interfaces
with the C routines defined by the 1800 standard?  I don't think
so, since "the C portion" is charged with ignoring the semantics
of the qualifier, which should have been stripped out before
the client application C code even sees the data.
 
-- Does this refer to the implementation of the C routines
defined as part of the DPI standard?  If so, this sounds like
we're assuming a particular implementation model in which the
C routines are implemented separately from the rest of
SystemVerilog.  Is it appropriate to assume such a model
as part of the standard?
 
Some thoughts.
 
Regards,
Jim
 

---------------------------------------------------------
James H. Vellenga                            978-262-6381
Engineering Director                   (FAX) 978-262-6636
Cadence Design Systems, Inc.         vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
---------------------------------------------------------- 

 


________________________________

	From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
Of Ralph Duncan
	Sent: Tuesday, January 30, 2007 1:31 PM
	To: sv-cc@eda.org
	Subject: [sv-cc] Updated 1716 proposal (rand/randc)
	
	

	I've updated the proposal for Mantis item #1716.  It deals with
qualifiers, 
	like rand and randc, which have no corresponding C semantics and

	can appear with data types that DPI otherwise handles. 

	The changes address concerns or suggestions from Doug Warmke and

	Jim Vellenga: 

	. The text now emphasizes that the C side does not 'zero out' or
manipulate 
	  any extra bits associated with the qualifier in any way. 

	. Various changes in the last F.5 paragraph either simplify or
clarify the text. 

	Thanks for the feedback. 
	
	Ralph 


	-- 
	This message has been scanned for viruses and 
	dangerous content by MailScanner <http://www.mailscanner.info/>
, and is 
	believed to be clean. 


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