Re: Minutes from John

ITC Techies,

Does anyone have my earlier detailed e-mail sent out about this ? I 
cannot seem to
find it and it is not on the ITC e-mail log.

-- johnS

Shabtay,

Shabtay Matalon wrote:

>
>>   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._
>

Shabtay,

This is one of the sections that has been reworded to say this is not an 
error
but undefined behavior as we have been discussiing - see official agreed
to updates from SV-CC committee below.

I had sent out a detailed e-mail of this but, for the life of me I cannot
find it. Do you have a copy ?

Anyway, as we have been discussing extensively, the new to re-worded 
text says this
is not illegal and that has been agreed to by the SV-CC committee.

So, again, not illegal behavior - just "undefined" and begging for 
clarification !
(Which is the whole point of our discussion.)

 


  In F.8. Context tasks and functions


*Replace*

 

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.

 

*With*

 

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 DPI-C context 'call chain' is a sequence of C function or 
task invocations that starts with a SystemVerilog entity calling a DPI-C 
import declared with the *context* keyword and continues in C, unbroken 
by a call back into SystemVerilog.  A small set of DPI utility functions 
are is available to assist programmers when working with context tasks 
or functions (see F.8.3). If those The behavior of DPI utility  
functions are used with any noncontext function, a system error shall 
result that manipulate context is undefined when they are invoked by any 
function or task that is not part of a DPI context call chain (see 
26.4.3). Similarly, the behavior of exported tasks or functions is 
undefined when they are invoked by a DPI call chain that lacks the 
context characteristic.


> __
>
> _ _
>
> 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.
>
> _ _
>
>  
>
>  
>

johnS:

Same story here. This has also been reworded to remove "illegal" from 
the language:

 


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

 

*Replace*

 

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.

 

*With*

 

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. A 
DPI context imported task or function is declared with the *context* 
keyword. A DPI-C context 'call chain' is a sequence of calls to C 
functions or tasks that begins with a SystemVerilog entity calling a DPI 
context import and continues in C, unbroken by a call back into 
SystemVerilog.

 

There are functions that allow the user to retrieve and manipulate the 
current operational scope. It is an error to use The behavior of these 
functions is undefined if they are invoked by an entity other than with 
any C code that is not executing under a call to a member of a DPI 
context call chain* *imported task or function. The behavior of exported 
tasks or functions is undefined when they are invoked by a DPI call 
chain that lacks the context characteristic.



-- 

This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________