RE: Minutes from John

Hi John,

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Brian

>Bailey

>Sent: Saturday, October 14, 2006 11:31 AM

>To: itc@eda.org

>Subject: Minutes from John

> 

>John sent these minutes from an un-authorized email account, so it did
not

>go through. Forwarding on John's behalf.

>   - There was also a short discussion on further defining

>     "undefined" behavior as per the SystemVerilog LRM when

>     calling certain SV utility functions, specifically

>     svGetScope() and svGetUserData() from within non-context

>     imported DPI functions.

> 

>     JohnS pointed out that this would support quite a useful

>     use model and that currently, because it is "undefined"

>     as per SV LRM, we can possibly take the lead on adding

>     definition. Shabtay said he thought it was explicitly

>     forbidden in the LRM, JohnS thought not.

> 

>   ACTION:

>       Shabtay to try to find text in LRM that states

>       where it is forbidden.

> 

>   ACTION:

>       JohnS to provide informational text as to why it would

>       be useful (assuming it is not forbidden).

 [Shabtay] I underlined the relevant sections in the LRM. I conclude
that your request is explicitly forbidden by the LRM and will result in
an error. I thus don't think it can fall into the "undefined behavior
category" which we may attempt to extend and thus we may be prohibited
from amending this in SCEMI 2.0. 

 

However, I suggest that you still send me the informational text as to
why it I useful and I will try to explore the position of our SV gurus
on this issue and the option that they will accommodate our request in
the SV working group. Once I get their feedback, we can discuss this
further.

 

Page 585 : F.8 Context tasks and functions

 

 

Some DPI imported tasks and functions require that the context of their
call be known. For example, those

calls can be associated with instances of C models that have a
one-to-one correspondence with instances of

SystemVerilog modules that are making the calls. Alternatively, a DPI
imported task or function might need

to access or modify simulator data structures using PLI or VPI calls or
by making a call back into System-

Verilog via an export task or function. Context knowledge is required
for such calls to function properly. It

can take special instrumentation of their call to provide such context.

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 noncontext function, a system error

shall result.

 

Looking into section F.8.3 I see:

 

F.8.3 Working with DPI context tasks and functions in C code

DPI defines a small set of functions to help programmers work with DPI
context tasks and functions. The

term scope is used in the task or function names for consistency with
other SystemVerilog terminology. The

terms scope and context are equivalent for DPI tasks and functions.

There are functions that allow the user to retrieve and manipulate the
current operational scope. It is an error

to use these functions with any C code that is not executing under a
call to a DPI context imported task or

function.

 

By this I understand that calling svGetScope()from non-context functions
(such as from SystemC) will result in an error.