[sv-cc] [Fwd: BOUNCE sv-cc@eda.org: Non-member submission from [John Stickley <john_stickley@mentor.com>]]

From: Charles Dawson <chas_at_.....>
Date: Wed Feb 01 2006 - 13:53:40 PST
-------- Original Message --------
Subject: BOUNCE sv-cc@eda.org:    Non-member submission from [John Stickley <john_stickley@mentor.com>]
Date: Wed, 1 Feb 2006 13:41:51 -0800 (PST)
From: owner-sv-cc@eda.org
To: sv-cc-approval@eda.org

 >From owner-sv-cc Wed Feb  1 13:41:50 2006
Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131])
	by server.eda.org (8.12.10/8.12.0.Beta7) with ESMTP id k11Lfl6T017619;
	Wed, 1 Feb 2006 13:41:49 -0800 (PST)
Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58])
	by relay1.mentorg.com with esmtp
	id 1F4PjX-0006zg-6r from john_stickley@mentor.com ; Wed, 01 Feb 2006 13:41:47 -0800
Received: from SVR-CAS-EXC-02.mgc.mentorg.com ([134.86.188.54]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 1 Feb 2006 13:41:47 -0800
Received: from [127.0.0.1] ([172.17.252.3]) by SVR-CAS-EXC-02.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 1 Feb 2006 13:41:46 -0800
Message-ID: <43E12B1F.70502@mentor.com>
Date: Wed, 01 Feb 2006 16:41:51 -0500
From: John Stickley <john_stickley@mentor.com>
Organization: Mentor Grahpics Corp.
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sv-cc@server.eda.org
CC: itc@server.eda.org
Subject: restrictions on non-context DPI import functions too tight ?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Feb 2006 21:41:46.0420 (UTC) FILETIME=[4CC55F40:01C62778]
X-Virus-Scanned: ClamAV 0.83/1265/Wed Feb  1 11:08:45 2006 on server.eda.org
X-Virus-Status: Clean

Greetings SV-CC Techies,

Long time no talk !

A question came up in our
ITC committee work for the SCE-MI 2 standard.

In P1800 Annex F8, 2nd paragraph it states the following:

"To avoid any unnecessary overhead, imported task and function
calls in SystemVerilog code are not instrumented unless the imported
task or function is specified as context in its SystemVerilog import
declaration. A small set of DPI utility functions are available to
assist programmers when working with context tasks or functions (see
F.8.3). If those utility functions are used with any non-context
function, a system error shall result."

While I agree with what it is saying in general about restrictions
of the use of VPI calls and other API calls in non-context
imports, we need some clarification here.

It is not clear to me why the use of svGetScope() and
svGetUserData() should cause any errors if used in a non-context
imported DPI function.

It seems that if the user just wants to get pre-stashed user data
associated with the imported function's calling scope that these
calls are generally implementable without paying the performance
price of having to implement a full "instrumented" context
function.

It is not clear to me that all the utility functions in F.8.3
mentioned above should be lumped into the same category of
requiring an error when called from a non-context imported
DPI function.

If vendors can implement these functions efficiently, why
should the user be penalized for using them in the more
efficient non-context flavor of imported functions ?

BTW, I can think of at least one vendor who shall remain
nameless (:-) that does not give currently an error when
svGetScope() and svGetUserData() are called from non-context
imported functions. And that is as it should be !

-- johnS



-- 
Charles Dawson
Senior Engineering Manager
NC-Verilog Team
Cadence Design Systems, Inc.
270 Billerica Road
Chelmsford, MA  01824
(978) 262 - 6273
chas@cadence.com
Received on Wed Feb 1 13:53:45 2006

This archive was generated by hypermail 2.1.8 : Wed Feb 01 2006 - 13:54:43 PST