Per, I support the idea that an implementation can address a subset of the standard as long the owner of the implementation states that the implementation is partially compliant (with a language or feature subset). This is my understanding of Brian's position (which I agree with). Shabtay >-----Original Message----- >From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per Bojsen >Sent: Thursday, September 15, 2005 5:57 PM >To: itc@eda.org >Subject: RE: HDL Support (was RE: Meeting minutes 050825) > >[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 > >Received on Fri Sep 16 10:29:12 2005
This archive was generated by hypermail 2.1.8 : Fri Sep 16 2005 - 10:30:35 PDT