Attendees listed at the end of the summary: Twiki Site: The documents released to the committee (for AMS Assertions) can be found at http://www.eda.org/twiki/bin/view.cgi/VerilogAMS/AmsAssertions <http://www.eda.org/twiki/bin/view.cgi/VerilogAMS/AmsAssertions> Summary: The requirements gathering group was formed to solidify the requirements for analog assertions and investigate the key questions (possible answers too) that need to be answered before the analog assertion language can be defined and integrated keeping in mind the future integration of System Verilog with VAMS. The group will meet independently and get/provide feedback to the larger group. It was decided to continue meeting with the larger group for next two months. At the end of two months, the question of frequency of larger group meetings will be revisited. Requirements Gathering Group: Others are welcome to join this group. Kevin Jones (Green Plug), Scott Cranston (Cadence), Prabal Bhattacharya (Cadence), Scott Little (Freescale), Himyanshu Anand (Freescale) Detailed Minutes: HA: Call for formation of the requirements gathering committee which will look into what types of problems should analog assertions address, their interaction inside the simulator with digital and analog engines. These requirements will help focus the committee on the problems that will need to be solved in order to propose the analog assertion language. KB: There are two problems. One is to extend the SVA to analog world and second is block level assertions. Are these for the mixed signal designs? What has FSL looked at? HA: We have looked at the high level in the mixed signal designs. KJ: Block level and mixed signal. They are not separate. The problem is essentially the same. KB: Verification strategies are different at the block level than system level. Block level, hundreds of thousands of runs with small variations. KJ: Individual blocks have simple assertions and at system level these become complex assertions. KB: Block level guys are not unhappy with what they have. Do they have any pains? KJ: Definitely yes there is pain. Individual analog designers are happy. Integration guys are unhappy. SL: During integration bugs are caught, which should have been caught by the analog designers. If the assertions are used, that gives more visibility into the analog. HA: In FSL too, the integration guys integrating digital and analog blocks are not happy. KB: Verification problem divided into two. Hundreds of runs are done at block level. Higher level system verification. PB: Were the problems that were provided by FSL from system level or block level? SL: Both, a mix from both domains. PB: When you talk about block level, what kind of language do you have today? SL: There is no language. Analog designers look at waveforms. KB: Waveform calculators and extractions. PB: .measure. PB: Will the System Verilog extension be the one to be extended? HA: That was the original plan. The requirements gathering committee should look at that aspect and once the requirements are solidified a decision can be made on the extension. DM: Don't you have customers coming to you who say this is what we want to do? PB: These requirements will mostly come from the users. KB: Yes they do. PB: What you mean a block could be a combination of lots of smaller blocks. They are asking for more complex checks and exploration. PB: One thing is worried about is whether we are creating a language or we are creating a solution. KB: Vendors could go on and provide own proprietary solutions. However, standards are beneficial to customers, increases competition and also increases the market for the vendors. We are engaged in standardization. HA: We want a solution which is a standard based on the extended language that this committee will work on. A solution that will be pragmatic and useful to all. For this we need to form a committee which will gather the requirements both from the users and the vendors. JOHN: Has anyone volunteered for the requirements group. KJ: I can be part of the group as a user. SC: What is the expectation from the requirements group? Is it defining the proposal or coming up with questions that need to be addressed. HA: The group will gather and solidify the questions that need to be answered in order to define the unified analog assertion language. It will deal with questions like how digital/analog interact with respect to assertions, what types of assertions should be addressed, etc. The questions are not all clear, and that will be part of the requirements gathering committee to handle. SC: I will be part of the group from Cadence. (Digital side) SL: I will participate in the group as a user. PB: I will also join the group. (Analog side from Cadence) Need more interaction from other vendors in order to ensure that everyone is represented and the standard does not end up as an extension of the existing solution of one vendor. KB: Other vendors to get involved and provide opportunities. Who else from VAMS is engaged from the committee in this. Is Sri involved with this activity? HA: Sri knows about this and the effort to form the requirements gathering committee. Dave Miller is also on the VAMS committee. Who else wants to be in the committee? Ed: Will be able to respond about the participation after looking at my commitments. DM: VAMS does not have the expertise to do the requirement gathering for assertions. We are happy for the requirements gathering committee to do this for us. I talk to Sri often about this. KB: Will review the requirements group recommendation but cannot commit to participate currently. DM: Are these minutes sent to the verilog-ams reflector? HA: Yes, they are. Attendees: Mike Demler Individual Contributor Ed Cerny Synopsys Surrendra Dudani Synopsys Dave Cronauer Synopsys Prabal Bhattacharya Cadence Scott Cranston Cadence Kenneth Bakalar Mentor Graphics Kevin Jones Green Plug Dejan Nickovic EPF Lausanne Dave Miller Freescale John Havlicek Freescale Scott Little Freescale Himyanshu Anand Freescale Total: 13 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 13 13:15:45 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 13:16:05 PST