0000000000000001000010111100000 Qamar Alam
1111111111111111111010111111101 Himyanshu Anand
0111111110011111101110100011111 Kenneth Bakalar
1111101010110110111011000011100 Prabal Bhattacharya
0000000000000011000010100100001 Sri Chandra
0111101111111111110110101111101 Eduard Cerny
1110111000010110101110111110111 Scott Cranston
0000000000000001000000000000000 Dave Cronauer
0000000000001100000000011111100 Dejan Nickovic
1101110111100100000000000000000 Mike Demler
0000000000000000000000000000000 Surrendra Dudani
1110000000111111111111001101111 John Havlicek
1110001100100000000000000000000 Kevin Jones (RGG Leader)
0000000111111111101110111111111 Jim Lear
0000000000001110111000000000000 Top Lertpanyavit
1111110110111111111111111011111 Scott Little
0000000000000100000000000000000 Erik Seligman
1010000000000000000000000000000 David Sharrit
0000000100000000000000000000000 Murtaza
0000000100000000000101100110000 Martin O'Leary

Decisions:

Action Items:

Details:

HA:

Sri: In Verilog-AMS the voting is informal as the language is mature and votes are on mantis. Voting per requirement is better than voting on the full document. One company one vote as per Accellera. At technical sub-committee voting is not restricted to just members but to all active participants. The guidelines are a simple majority. Worthwhile to note any concerns of people who voted "no". In terms of tie, look at the attendance and accept the feedback of those who have participated most. Also, the person chairing the meetings can vote on tie or refer it to Accellera committee chair. Whenever there is a proposal, we vote on it, on a per requirement basis. The way it is implemented or how it is implemented is different, from the requirements.

JH: Are you recommending we vote as individuals or we vote as companies?

Sri: One company one vote.

HA: Even if they are not Accellera, they can vote?

Sri: Yes.

HA: How do we go forward after the vote on the requirements.

Sri: The requirements

Sri: Is it separate document or appendix to VAMS. In terms of presentation how will it look like?

KB: Very economical changes to SV apart from just SVA. The main committee is going to ask questions for the changes. The IEEE rules are all very formal.

KB: Portions will be changes to VAMS and SV. What is the schedule of the merger of VAMS and SV.

Sri: From next week, we will assign people to multiple power domains, some (Shalom, Graham and I) will be looking at the merger thread. I don't think something will happen in two-three years. But, whatever enhancements happen to VAMS we can roll that in informal releases of VAMS.

KB: So, there will be some releases before Accellera released VAMS?

Sri: Yes, we will have that.

KB: What is the integration strategy for VAMS and SV, rather than just BNF?

Sri: It will be more fundamental than just BNF and will depend on how many people we have.

KB: There are two tracks, one is SV-AMS track and then there is VAMS-SV track.

HA: What about the merged language.

KB: One is to keep separate and the other is to merge everything with one BNF. All we can do is conservatively keep them separate. Sri have you looked at the requirements.

Sri: Yes, I have been following. There are some concerns about what is allowed in port connections. We can deal with those changes through bind, and also the idea behind the "square brackets".

KB: I was thinking of the requirements and not about the implementations. Do you think this approach is compatible.

Sri: My biggest concern is with changes to SV. For VAMS we can do any changes to VAMS and deal with it, as it is the same committee. Second is importing any SV syntax into VAMS. If we can separate the SVA and VAMS cleanly then that is the best.

-- AnandHimyanshu - 2009-11-03