• 000000000000000100001011110000 Qamar Alam
• 111111111111111111101011111110 Himyanshu Anand
• 011111111001111110111010001111 Kenneth Bakalar
• 111110101011011011101100001110 Prabal Bhattacharya
• 000000000000001100001010010000 Sri Chandra
• 011110111111111111011010111110 Eduard Cerny
• 111011100001011010111011111011 Scott Cranston
• 000000000000000100000000000000 Dave Cronauer
• 000000000000110000000001111110 Dejan Nickovic
• 110111011110010000000000000000 Mike Demler
• 000000000000000000000000000000 Surrendra Dudani
• 111000000011111111111100110111 John Havlicek
• 111000110010000000000000000000 Kevin Jones (RGG Leader)
• 000000011111111110111011111111 Jim Lear
• 000000000000111011100000000000 Top Lertpanyavit
• 111111011011111111111111101111 Scott Little
• 000000000000010000000000000000 Erik Seligman
• 101000000000000000000000000000 David Sharrit
• 000000010000000000000000000000 Murtaza
• 000000010000000000010110011000 Martin O'Leary

Decisions:

Action Items:

Details:

SL: Himyanshu is on vacation. Ken, it looked like you made some small changes to the Twiki after last meeting. Is there anything you wish to highlight?

KB: I just reformatted to make list numbers.

KB: If Cadence wants to move forward with wreal why don't they propose what they have implemented?

SC: Proposing exactly what?

KB: What you have already implemented.

SC: I know that there has been some thought about proposing that in the Verilog-AMS committee, but I don't know where that is. Martin O'Leary is the guy to talk about that.

KB: Then why is Prabal bringing it up here?

SC: I am not sure. I would like to talk to him about that.

KB: Actually Prabal does suggest something more than is publicly known about what Cadence has been implemented.

KB: Item 1 in Requirements from JH. Without restrictions that just says that the languages are merged.

SC: I think that things should be added when we have a good reason to add them.

KB: I think that we want to do the least harm.

SC: What do you define as damage?

KB: Any change is damage. Changes make the integration harder. Every little thing we add has to have a big blossoming of power with it. We still disagree on what it means for something to have meaning in a context. If some piece of SV has meaning in a VAMS context then VAMS has to be extended to understand that. You can't claim that it isn't being understood by VAMS and something else is understanding it. What you are really doing is extending VAMS.

SC: Depending on the thing you are talking about that extension may be minimal.

KB: Sure, we might add variable ports to VAMS.

SC: Let's talk about a member select. If it is just a normal 4-state wire then you aren't extending too much.

KB: The issue is that the scope is that the instatiation is in the VAMS module.

SC: There is a difference between using items in the language and connecting to them. It may not take too much effort to connect to things.

KB: What you are saying is that the formals in a module declaration are uninterpretted in a module declaration?

SC: Yes.

KB: The formal is just an uninterpretted set of specifications as far as VAMS is concerned. Let me think about that. That may be possible. Let's look at the actual. I don't think that a trick like that works on the actual side.

SC: Why would you need to do SV stuff if you are instantiating in the VAMS context?

SL: We would like complex SV types to be passed through the ports b/c we foresee a need to write properties about AMS quantities that require knowledge of the digital state of the design. We don't want to have to disassemble user created types back to bit and then reassemble to use these types on our checks.

KB: My last e-mail talks about this. We can sort of divide the instatiation and have some expressions evaluated in VAMS context and others evaluated in the SV context. Then it becomes a question of what syntax we use.

JL: Why wouldn't we be able to do this in a two layered approach?

KB: You came to the same conclusion I did.

SC: The wrapper translates from the SV world to the VAMS world.

KB: The first note I had about these proposed the wrapper, but the second note is doing the same thing except it proposes a bracket syntax.

JL: Is it possible to do something with the preprocessor here?

KB: One way to make changes is to use the preprocessor to convert the new language into the old language.

JL: Hmm, okay, I was just hoping to prevent users from actually having to create the wrapper.

KB: At some point the user has to determine which expressions should be interpretted by VAMS and SV. There needs to be a syntax somewhere. The wrappers I described in the first mail and the brackets I proposed in the second mail really accomplish the same thing.

SL: Where is the mail describing the bracket notation? I remember the idea, but I don't recall the notation.

KB: After I sent that message I thought that some folks might want to see some concrete syntax, so I devised a syntax. I thought I sent that out.

JL: Let me see if I understand what you are proposing. What you are proposing is some marker to say this SV and needs to be interpretted in the context of SV.

KB: In particular within the context of the bind statment.

JL: Can you elaborate.

KB: I am imagining the case where the bind statement is within a SV context. The target of the bind in VAMS. That is the case we have been considering.

JL: I don't see how you can do that. Wouldn't you need to compile VAMS references in the SV compiler?

KB: In this proposal there are things that are destined for evaluation in the target context and the bind context. I was focusing on those things that are evaluated in the context of the bind.

SC: Don't they still need to be parsed in the SV context?

KB: I suppose that they need to be lexed by SV, but I don't think that is a problem because there isn't anything in VAMS that makes it look lexically unlike a SV expression.

SC: I don't know if I agree with that.

KB: Do you have an example?

SC: How about the scale factors?

KB: Good point. We would have to outlaw them or extend SV. The idea would be to allow as much SV as possible and extend SV as little as possible.

KB: As far as the expressions in the bind that would be interpretted in the target context they would need to have a form that is legal in SV. Those items could then be interpretted in the target context. In SV today V(a)*V(b) has no meaning in the bind context. It only has meaning in the target context.

JL: SV wouldn't do any typechecking on that?

KB: No. SV has to move it into the target context for that.

JL: How does that work in practice?

KB: I am not sure.

SC: I can look into this and find out.

KB: There are many things that can't be type checked until elaboration time like port connections.

-- ScottLittle - 2009-09-09