Hi Kevin, Thanks for the clarification. I realize that there are two important parts here. a) Defining the language interoperability (similar to the questions we have framed as a committee) b) Defining the implementation/tool interoperability (the topics that you are raising). Although both are equally important we should clearly separate the two goals. As a committee we can come up with standards on how we make the languages interoperable. This is within our charter. On the other hand any questions on tool interoperability is beyond the scope of the committee. Tools may choose to implement part of the proposed standard. Moreover the survey is already quite big as we are dealing with 4 different languages. Adding more questions that encompass tool interoperability may reduce the number of responses and may defeat the purpose of the survey What do others feel? Thanks Logie. -----Original Message----- From: Kevin Cameron [mailto:kevin@sonicsinc.com] Sent: Wednesday, February 14, 2007 9:38 AM To: Logie Ramachandran Cc: sv-xc@eda.org Subject: Re: Survey - Version 0.2 Logie Ramachandran wrote: > Hi Kevin, > > Thanks for quick response. My comments below. > > Logie. > > -----Original Message----- > From: Kevin Cameron [mailto:kevin@sonicsinc.com] > Sent: Tuesday, February 13, 2007 3:54 PM > To: Logie Ramachandran > Cc: sv-xc@eda.org > Subject: Re: Survey - Version 0.2 > > Logie Ramachandran wrote: > >> Hi Team, >> >> I have incorporated the feedback and created Version 0.2 of >> survey. Please give it a last minute read, and we can send it out >> if there is no major changes proposed in the next 2 days. >> >> > I still don't think it's clear whether you talking about a single > simulator/vendor environment or multiple tools from different vendors > talking to each other. > > LOGIE>> I assume that you are talking about 1.4. This was the wording > LOGIE>> we agreed to in the meeting. Can you propose changes to > LOGIE>> the current wording > > LOGIE>> 1.4 In the context of interoperability, is it important to > > LOGIE>> have the capability to cosimulate multiple simulators > LOGIE>> (supporting different languages) from different vendors? > Not so much that question specifically, just the general impression is that the questions refer to a co-simulation environment rather than a more academic exercise in making the language semantics compatible. > Also, we have the issue that we currently have to generate models for > multiple SystemC environments (different headers/compilers), and would > much rather be able to ship a single object file that was usable with > multiple SystemC environments (as well as SV). So maybe a question or > two about interoperability of versions for compiled IP would be useful. > > LOGIE>> I am concerned that we are expanding the scope of the survey > LOGIE>> beyond what was original discussed. This question mainly > LOGIE>> addresses the compatibility of SystemC versions as it pertains > LOGIE>> to a compiler (gcc version x). > I'm just raising issues we have. If the result of the survey is that no-one else cares about that particular issue (or co-simulation in general) then we can go tackle the issue somewhere else. If most people do care then we may need to reassess the goals of the committee. Since we are moving into an era of increasing reuse, we need methodologies that support black-box IP from multiple vendors, defining the inter-language semantics is only half the solution. I think the language issues and the mechanics of co-simulation can be tackled by separate subcommittees if we need to do both, so it probably won't impact schedule that much, although I'm sure looking at the implementation issues will help prioritize the language issues. Kev. > >> Somdipta, do you want to attempt changing the format to >> Excel? >> >> Thanks >> >> Logie. >> >> >> -------------------------------- >> Loganath Ramachandran >> Director, R&D >> Verification Group, >> Synopsys >> Mountain View, CA 94043 >> >> Ph: 650-584-4891 >> Em: logie@synopsys.com >> >> >> > >snip< > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 15 16:28:51 2007
This archive was generated by hypermail 2.1.8 : Thu Feb 15 2007 - 16:28:53 PST