[sv-champions] Issue 50: Action Item

Hi, Champions,

At the last P1800 meeting, Oz Levia was given the action item (from the unapproved minutes):
Action Request [Oz Levia]: On 3 December 2005, Oz is to send out an impact analysis and come up with possible non-obtrusive suggestions to resolve issue 50.

The P1800 has asked that the Champions review Oz's findings and make a recommendation, for example, the Champions can indicate that the SV-CC should review the proposal. Please review the following email and the attached proposal so that we can discuss it as the first issue discussed in the Champions meeting on Tuesday.

I have cc'ed Charles Dawson on this mail, and will discuss with him the possibility of inviting members of the SV-CC to our champions meeting for this discussion.

Charles, here is the meeting info:

SV Champions Meeting December 7 from 10am to 12 noon Pacific time. The callin information is:
PARTICIPANT CODE: 53904
Toll Free Dial In Number: (888)635-9997
International Access/Caller Paid Dial In Number: (763)315-6815

Thanks,

Karen

>From: "Oz Levia" <ozlevia@synopsys.COM>
>To: "'Srouji, Johny'" <johny.srouji@intel.com>
>Cc: "'Brophy, Dennis'" <dennisb@model.com>,
> "'Karen Pieper'" <pieper@synopsys.COM>,
> "'Oz Levia'" <ozlevia@synopsys.COM>
>Subject: Issue 50: Action Item
>Date: Fri, 3 Dec 2004 12:09:40 -0800
>X-Mailer: Microsoft Outlook, Build 10.0.6626
>Importance: Normal
>
>Johny,
>
>
>
> As agreed I would like to provide this follow up on my action item from the last P1800 meeting regarding issue 50. I copy Dennis so this can be recorded and Karen so that she can forward to the Champions and the Chairs of CC in advance of Monday s meeting.
>
>
>
> We have spoken to over two dozen customers that have known use of legacy bit representation (aka Vec32) that is documented in SystemVerilog 3.1 and 3.1a. Time did not permit the negotiation of release of names or projects. To a limited extent I can do so verbally. The concern from customers is that old code will work differently in 3.1 or 3.1a vs. P1800 without a way for the user to tell. The code will link but will not produce correct results. In other words the change is insidious.
>
>
>
> Overall, we propose to retain the alignment between DPI and VPI and retain of the resolution on issue 50 (as resolved by CC), but would suggest a modification that will strengthen the alignment and at the same time resolve customer concerns about back ward compatibility.
>
>
>
> The proposal is attached, but in short it can be summarized:
>
>
>
>· A user call will be added that will return the version of SV being implemented by the simulator. This is generally useful.
>
>· DPI data type (with the 3.1(a) byte / bit order) and function will remain as is and will remain compatible with 3.1 and 3.1a, but will be deprecated in P1800 version of the standard. Old code will continue to link and work as before, but implementations will not be required to support this Interface going forward. Traditionally, deprecation is used for exactly that purpose. Over time, deprecated portions can be removed from the standard.
>
>· VPI data type will be used with similarly named (new) functions. This will achieve perfect alignment with VPI and DPI since hence forward they will use the same data type. No confusion can be claimed.
>
>· That it&
>
>
>
>Please see attachment.
>
>
>
>-Oz.
>
>
>
>