Re: HDL Support (was RE: Meeting minutes 050825)

From: John Stickley <John_Stickley_at_.....>
Date: Fri Sep 16 2005 - 12:52:45 PDT
Greetings ITC Techies,

Before just the C/C++ aspect of this discussion evolves too much
further, let me make a simple observation that probably makes
that part a moot discussion.

DPI, by design, is an ANSI C interface. This is so that on the C/C++
side, DPI is a "lowest common denominator" interface that works
identically (even down to symbol mangling and linkage) in *any*
C or C++ environment.

There was considerable discussion on this topic in the early days
of DPI development and there was pressure to define a C++ version
of it as well, but this was pushed back and what resulted was an ANSI C-only
interface that easily plugs into any C++ env as well.

This is in contrast to SCE-MI I which defines both C++ and C versions.

-- johnS

Per Bojsen wrote:
> [I removed the CC lists since everybody is on the mailing list.  No need
> for duplicate emails :-)]
> 
>  > SCE-MI 2.0 compliance should mean supporting all the 3 languages
>  > (SystemVerilog, VHDL or Verilog 2001). We should not support the concept
>  > of building SCE-MI 2.0 as SystemVerilog only standard or define SCE-MI
>  > 2.0 compliance in the domain of only one language (SystemVerilog for
>  > example).
> 
> I think you misunderstood my question.  I agree that the standard should
> define support for all three HDLs and continue to have C and C++
> bindings on the software side.  But I was wondering if the standard
> requires an implementation to implement the support for all the
> languages described in the standard or whether an implementation that
> only has support for SystemVerilog and C++ for instance could still
> be considered a compliant implementation (assuming it was compliant
> in all other respects, of course).  It doesn't really matter since it
> is really up to the customer to decide.  As Russ indicated, a customer
> that is only interested in SystemVerilog/C++ would not care if VHDL
> is not supported by the implementation.
> 
> Down the road there is another possibility where subsetting could be
> performed: an implementation could choose to only implement the
> function based interface, for example.  Again, I can see a market for
> such a subset implementation.
> 
> Note, I am not advocating anything here, and I am not suggesting anyone
> should do this.  I am simply trying to understand what compliance means.
> 
> Per
> 
> 

-- 

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
________________________________________________________________
Received on Fri Sep 16 12:53:58 2005

This archive was generated by hypermail 2.1.8 : Fri Sep 16 2005 - 12:54:22 PDT