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
________________________________________________________________