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