RE: Meeting minutes 050825

John, ITC fellows,

The point I was making in my email is that the interface should be
considered based on its merit in the context of each language and we
should not constraint it being functional or non-functional before
evaluating each approach. 

For SystemVerilog we support a DPI-based functional interface. 

As to Verilog/VHDL, whatever interface is proposed (functional or
instantiation/ macro-based), it must work within the constraints of the
language and should not require the infrastructure linker to parse and
interpret language extensions. Such a flow is in particular unacceptable
to simulation users who are expected to use common VIP that also run in
acceleration.

Macro interface just serves as a positive proof that such requirement is
not unreasonable, and that it can actually be easily implemented. If ITC
finds a way to do the same with functional interface across all
languages, we will definitively study it very carefully and contrast it
with the macro /instantiation-based approach based on its merits.

John,

In that context I asked you on 9/8 if "the latest Revision you have sent
(I believe this was Revision 1.5) is compatible with your statement here
(about no requiring any language extensions) or do you plan to publish a
different revision that you see as compatible with this statement". You
have not responded yet to this email!

To your note, elimination of "Infrastructure Linker" phase is NOT a
requirement (although this would be desirable is possible). What is
important is what kind of flow and implementation is embedded in the
"Infrastructure Linker" phase.

Last on a procedural note;

I have not attended in the meeting on 6/30/05 following the meeting
where we agreed on the Mentor SCE-MI II proposal as the basis for SCE-MI
2 and haven't noticed the brief description in the notes when I returned
from my vacation. But following your comment below, I read the summary
again and also approached Matt who briefed me on the discussion at the
meeting. Matt indicated that he raised his objections throughout the
meeting where "a functional call interface" has been agreed as a
compromise. 

Given that this issue associated with multi-language support in SCE-MI
2.0 is so fundamental to Cadence, I am conveying now that we are NOT in
agreement with the summary published on 6/30/05 stating that "There will
be a functional call interface available in each language" and that our
position on Verilog and VHDL is stated in the email that I have sent
below and my clarifications above.

Brian,

Please take a note the Cadence objection to mandating "a functional call
interface" for Verilog and VHDL in the summary you published on 6/30/05.


Thanks,

Shabtay



>-----Original Message-----
>From: John Stickley [mailto:John_Stickley@mentor.com]
>Sent: Thursday, September 08, 2005 7:58 AM
>To: Shabtay Matalon
>Cc: itc@eda.org; Brian Bailey; Stephen Seeley; Jason Rothfuss; Matt
Kopser
>Subject: Re: Meeting minutes 050825
>
>Shabtay,
>
>In the interest of not backtracking from decisions made so far,
>I would like to reiterate the agreement made in the meeting
>minutes following the meeting where we agreed on the Mentor
>SCE-MI II proposal as the basis for SCE-MI 2 that the
>function call interface would be supported across all
>three languages. If we retract on this decision, a more
>complex use model emerges because of the inconsistent interfacing
>paradigm across the 3 languages.
>
>Furthermore I think the agreement was that the macro interface
>would be considered as an add-on to the function call interface
>but not a replacement.
>
>I don't agree with your arguments that extra infrastructure
>linking is not required for macros but is for functions.
>
>Both approaches require code analysis support by the infrastructure.
>
>And with some of the recent proposals we've been discussing,
>all function declarations can be made via attributes which
>are part of both Verilog and VHDL. So if people are uncomfortable
>with pragmas, this is another approach that is fully consistent
>with existing, supported language features and requires no
>langauage extensions as you suggest below.
>
>-- johnS
>
>Shabtay Matalon wrote:
>> Brian, ITC members
>>
>>
>>
>> This email is a response to the 8/25/2005 minutes and the call for
each
>> company to send to the reflector the SOLUTION that they would like to
>> see for the Verilog datatype coercion issue. However, the scope of
this
>> email is broader than simply replying to your question as evident by
the
>> analysis flow we followed.
>>
>>
>>
>> The criteria that we have applied in our analysis are quite simple:
>>
>>
>>
>>    1. Interface proposals can only be defined within the supported
>>       capabilities of a standard language.
>>    2. Interface proposals must be supported in both simulation and
>>       acceleration mode. In this regard, a reasonable criterion is
that
>>       it would be supported by IUS, MTI and VCS.
>>    3. The interface implementation effort should be reasonable.
>>
>>
>>
>> When we analyzed the proposal delivered by John Stickley on 8/24/05
>> SCE-MI 2 DPI "Data type support for "old Verilog" outlines 3 options"
we
>> observed that it made the following assumptions:
>>
>>
>>
>>    1. That DPI import/export functions could be supported in the
context
>>       of Verilog 2001 and VHDL.
>>    2. That the interface definition within a model (such as a BFM)
could
>>       be separated from the language being used.
>>    3. That it is a reasonable effort to parse the user's code by the
>>       Infrastructure Linker
>>
>>
>>
>> We do not agree with the above assumptions, and have thus reached the
>> following conclusions:
>>
>>
>>
>>    1. The proposed data types are acceptable by SystemVerilog and we
are
>>       supporting the use of these types as part of a DPI based
interface
>>       using import/export functions _for SystemVerilog BFMs_.
>>    2. We do not support coercion of data types nor do we support the
use
>>       of DPI import/export within Verilog 2001 given the simple
reason
>>       that_ DPI is not part of the Verilog 2001 standard_.
>>
>>
>>
>>             The solution that we propose for Verilog 2001 is to let
>> users choose between the following two options:
>>
>> a.       Migrate Verilog 2001 BFMs to SystemVerilog. This effort will
>> mainly imply eliminating any SystemVerilog keywords and making sure
that
>> Verilog data types would work in the context of the SystemVerilog
>language.
>>
>> b.       Use interface methods that are supported within the Verilog
>> language (but not DPI). We propose using a module instantiation
approach
>> such as the variable length message macros that Cadence has proposed
for
>> SCE-MI 2.0.
>>
>>    3. We do not support coercion of data types nor do we support the
use
>>       of DPI import/export within VHDL given the simple reason that_
DPI
>>       is not part of the VHDL standard_. The following are the
specific
>>       considerations for VHDL.
>>
>> a.       Because migration of VHDL BFMs to SystemVerilog presents a
>> significant challenge to VHDL users, we propose using a module
>> instantiation approach such as the variable length message macros
that
>> Cadence has proposed.  While possibly a different interface could be
>> used for VHDL than the one proposed for Verilog, we suggest that
SCE-MI
>> 2.0 should offer a solution that can be mostly shared between the two
>> languages if possible.
>>
>> b.       We would support a proposal to IEEE-affiliated VHDL standard
>> committee to include DPI into VHDL. Should this extension be approved
by
>> IEEE by the time that SCE-MI 2.0 is finalized, it would allow for
also
>> using DPI import/export calls in VHDL BFMs.
>>
>>    4. We believe that the effort of implementing the Infrastructure
>>       Linker in SCE-MI 2.0 per the proposal is unreasonable because
>>       designs based on the proposal cannot be interpreted using
standard
>>       simulation compilers that support Verilog 2001, VHDL and
>>       SystemVerilog. The code will have to be interpreted by
proprietary
>>       compilers that understand non-standard extensions to Verilog
and
>>       VHDL.
>>
>>
>>
>> _Summary:_ Our proposal is that usage of DPI import/export functions
>> should be confined to SystemVerilog BFMs. We propose using an
>> instantiation based approach for Verilog 2001 and VHDL such as the
>> variable length message macros that Cadence has proposed. We support
an
>> industry effort to include DPI support in the VHDL language. In the
>> event that such extensions were to be made to the VHDL LRM, we would
>> also support the use of DPI import/export within VHDL as a basis for
>> SCE-MI 2.0 support. It is important to note that if VHDL DPI support
is
>> approved, coercion between DPI C types and VHDL types will be
defined,
>> eliminating the need for defining these by this committee.
>>
>>
>>
>> -------------------------------------
>>
>>
>>
>> Shabtay Matalon
>>
>> Solution Architect
>>
>> R&D, CVA
>>
>> Phone: (408) 428 5081
>>
>> email: shabtay@cadence.com
>>
>>
>>
>
>--
>
>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
>________________________________________________________________