• 0000000000000001000010111100 Qamar Alam
• 1111111111111111111010111111 Himyanshu Anand
• 0111111110011111101110100011 Kenneth Bakalar
• 1111101010110110111011000011 Prabal Bhattacharya
• 0000000000000011000010100100 Sri Chandra
• 0111101111111111110110101111 Eduard Cerny
• 1110111000010110101110111110 Scott Cranston
• 0000000000000001000000000000 Dave Cronauer
• 0000000000001100000000011111 Dejan Nickovic
• 1101110111100100000000000000 Mike Demler
• 0000000000000000000000000000 Surrendra Dudani
• 1110000000111111111111001101 John Havlicek
• 1110001100100000000000000000 Kevin Jones (RGG Leader)
• 0000000111111111101110111111 Jim Lear
• 0000000000001110111000000000 Top Lertpanyavit
• 1111110110111111111111111011 Scott Little
• 0000000000000100000000000000 Erik Seligman
• 1010000000000000000000000000 David Sharrit
• 0000000100000000000000000000 Murtaza
• 0000000100000000000101100110 Martin O'Leary

Decisions:

Action Items:

Details:

KB: We were confusing the design activity with the requirements activity. So I wanted to take out all the design activity and leave only the requirements. So, I split it into two sections - Assumptions and Requirements. In doing so, we will have to extend VAMS as well as SV. The coverage is not right, let me delete it.

HA: So you are deleting the assumption on coverage?

KB: Yes. Are there any questions on this.

SL: I am fine with it.

KB: The restriction is on the time domain simulation. Does everyone agree with it?

JL: I think that is fine.

KB: Requirements discussion. Do as little damage as possible.

HA: The question on minimal changes is subject to individual interpretation. How to decide if a change constitutes minimal changes?

KB: Yes it is a bit subjective, so let me clarify that if there is a change it will be a huge change and is powerful. An example of an inappropriate change is to introduce classes in VAMS. That is a huge change but does not serve any purpose in this context.

KB: We are not talking about doing FFT with this language. The SV should be a proper subset of ASVA. Everything should be inside host language. We may have to extend the host language to support this requirement. And if we extend the host language that should conform to "as less a change" requirement.

KB: This does not put a restriction on extensions that John is talking about. But, we have to look carefully as to whether that is really required.

SL: In the past, we have wanted the assertions to work both online and offline. KB: This does not prevent either form of evaluation.

KB: The requirements and assumptions will come back to haunt us. These requirements are not laid out in stone but will want to look at those in context of voted requirements.

HA: I agree. We want everyone to think carefully before voting on the requirements. Ideally, we would not want to come back and change them. If there is enough force behind it, requirements could be changed, but we want to avoid that as much as possible and keep the changes to requirements bare minimal after the vote.

JH: I can play out the chess game and see where the debates are going to come up. The port expressions, bind statements will have discussions and we have to debate the power and limitations.

KB: Those are within the requirements.

JH: If the long term vision is sound and the balance is reasonable, I am very positive about proceeding in that fashion and making compromises.

ED: Are these the requirements that were on Twiki?

HA: Yes. Ken has modified them. You can do a diff and see the differences from the original requirements.

PB: There is going to be a lot of discussion on Ken's first requirement - "minimal changes". John's requirements are about making the changes. At this point we just have to accept/reject the changes and move forward.

KB: I agree with you on the requirements and that John's requirements are more of language features than requirements. And he has justification for each one of them.

JH: I am not sure if I see a fine distinction between features and requirements. In PSL there were some requirements to express certain kinds of operators (reset, abort). Things which were very feature like stood as requirements in the language committee. I am not sure, if in the language committees there has been a distinction.

ED: Would it be useful to add a statement why you need these features. In my mind, I have you want this because of this reason.

KB: Some of them are copied into my requirements, which I think were requirements.

PB: Like "offline/online". John's 1,2,3 are more language features.

KB: "1" is in my assumption section.

JH: Ed, I can add a statement like that, but it looks to me that my section will get dissected.

KB: I think everything will get dissected.

PB: Where is Dejan's requirement that we discussed about in the previous meetings?

HA: Prabal is referring to Dejan's requirement which wanted to separate the precision and affect on simulation by the assertion. I don't think it is there in any of the requirements.

KB: It seems more like an assumption than a requirement.

DN: I would like to separate the two issues, the basic blocks that will be needed for the two languages to communicate with each other. The first thing need to be defined are the primitives. Types so that being able to access reals in SV and brige the two. So, that look at the values in VAMS from SV.

KB: Synchronized or de-synchronized way?

DN: Synchronized way.

PB: What two ways are you talking about?

KB: What else do you need from the already synchronized VAMS-SV? As an approach to problem solving, I will prefer to define ASVA which works in VAMS and from that define what we need to do on the SVA side to interface. I would define the language first and then the interface.

PB: You are talking about some protocol between VAMS and SV to exchange values. Are you saying there are no primitive to do so?

DN: I believe SV will provide most of the capabilities.

PB: So you talking about structural interfaces?

DN: Yes, I mean structural interfaces.

KB: In the Verilog family of languages, there are several ways to access data in another module. Hierarchical names in VAMS, virtual interfaces and classes in SV.

HA: Did you mean ports when you said structural interfaces or you had something else in mind?

DN: I don't know how it is done, except a way to handle that communication.

KB: Would like to define ASVA in VAMS first, and then move it to SVA.

PB: And why is that a better approach?

KB: The requirements don't specify that all available forms be available in VAMS. But, when ASVA goes into SVA, the entire subset of SV is available there. There are other objects available in SV which we do not want to add to VAMS.

PB: The data part is restricted to VAMS.

KB: There will be some digital types in ASVA, as it will work in future with SV.

HA: Are you restricting the data types or the types of assertions themselves?

KB: Mostly on built-in functions, classes, expressions that can be used assertions.

JH: There could be a nice effect to that approach. I am thinking about differentiating the different sets of data types in the two languages from the core of what should the temporal assertions should look like when dealing with Analog Mixed Signal properties. A lot of that can be looked at by abstracting the data type away and you don't have to worry about other data types. You can talk about temporal expressions, regular expressions and just deal with those data types.

PB: And then you address synchronization and that is orthogonal to data types.

KB: You mean @cross?

PB: @cross is already there in language.

KB: I am also trying to provoke Dejan into working this.

DN: I don't have a Mixed Signal simulator that I can experiment with.

KB: I can fix that.

JH: I have something to throw out. We have been thinking along the lines of what I just spelt out and spent a considerable time on it. We have sent out some initial thoughts to some people, once we have it pdf format and have had some sanity checks we intend to share it with everyone.

HA: Thanks for sharing that John, I believe it will be about two or three weeks before it is sent out?

JH: Scott can speak to that.

SL: I should have the pdf ready in a couple of days. Based on the initial feedback it seems the document is in good shape. But, we still want to make sure some more checks are made before sharing it with everyone.

HA: The reason I am saying about two or three weeks is that by that time we would have reviewed it and also have taken a stand on the requirements. So, by the time requirements are voted upon, we will be ready to send the document to everyone on the committee and see how it conforms to the requirements.

HA: Thanks Ken for putting the requirements together. I think we can continue the discussions on requirements for the next couple of weeks. I believe most agree with most of the requirements if not all and by the time we take a vote we will have a good understanding of these.

DN: I was one of the lucky ones to have previewed the document that Freescale has prepared. I think it is a very nice document that brings together continuous and digital semantics together.

-- AnandHimyanshu - 26 Aug 2009