I found these minutes on 4/1. John, Brian, I think both of you sent emails but I don't recall seeing them. John, Please send me the "information text" so I can pursue this on my end. Thanks, Shabtay ________________________________ From: John Stickley [mailto:john_stickley@mentor.com] Sent: Wednesday, October 18, 2006 7:08 AM To: Shabtay Matalon Cc: brian_bailey@acm.org; itc@eda.org Subject: 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 ________________________________________________________________
This archive was generated by hypermail 2.1.8 : Wed Oct 18 2006 - 10:37:34 PDT