Re: Meeting minutes 050825

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