Attendees:

• 0000000000000001000010 Qamar Alam
• 1111111111111111111010 Himyanshu Anand
• 0111111110011111101110 Kenneth Bakalar
• 1111101010110110111011 Prabal Bhattacharya
• 0000000000000011000010 Sri Chandra
• 0111101111111111110110 Eduard Cerny
• 1110111000010110101110 Scott Cranston
• 0000000000000001000000 Dave Cronauer
• 0000000000001100000000 Dejan Nickovic
• 1101110111100100000000 Mike Demler
• 0000000000000000000000 Surrendra Dudani
• 1110000000111111111111 John Havlicek
• 1110001100100000000000 Kevin Jones (RGG Leader)
• 0000000111111111101110 Jim Lear
• 0000000000001110111000 Top Lertpanyavit
• 1111110110111111111111 Scott Little
• 0000000000000100000000 Erik Seligman
• 1010000000000000000000 David Sharrit
• 0000000100000000000000 Murtaza
• 0000000100000000000101 Martin O'Leary

Decisions:

---

Action Items:

---

Details:

---

PB: I did look into the package referencing a bit. I believe that making a package reference within a module may not be the best thing to do until we achieve a VAMS-SV integration. Package references can be made in two different ways that would both require extensions. That is doable though. The problem is that the types of the objects that can be referenced are advanced SV types. There are also some issues with scoping. A more useful way would be to pass SV package items through xmrs or structural instantiation. The actual import package would happen in SV and VAMS would then reference the object as a standard xmr or via structural instantiation. This is a good short term resolution. Short term meaning before we have a full SV-VAMS integration. This is attractive b/c it fits into the current framework of the VAMS language. Actually allowing a package reference in VAMS may actually create more trouble.

MO: I agree with those conclusions.

PB: I will send out an e-mail to the group collecting these thoughts.

SL: We have been working w/ Accellera to get a mailing list setup for this group. This should hopefully happen soon. We are working on some examples of the data marshaling and have updated the Twiki page under the section Requirements from JH. JH will you talk about the updated requirements.

JH: We revised the subsection "Requirements from JH" under the "Requirements on language". We were to update the page based on the technical points we have been converging on. With respect to the first item, we are still thinking that we will instantiate SV within VAMS. This seems like the best way forward.

The second item's revisions came out of thinking a bit more about what types of port connections are possible and will be needed. We originally thought that requiring inputs would be best. There have been concerned raised about the implicit continuous assignments with reals and the number of A2D events that might be generated. We thought a bit more about checkers. Checkers don't follow port bindings like a module, but they follow the semantics of property instantiations. It may be that by enhancing properties to support the kinds of data types that would receive analog quantities we will probably get some enhancement of the checker argument binding capabilities at the same time. We may need to handle checkers specifically, but it will likely be in the same spirit as the property modifications.

The third item was also modified. We removed some restrictions that based on previous discussion seem unnecessary. We had a requirement to make expressions entirely VAMS or SV. The first subrule under 3 is just to ensure that we can have richer types in the formal arguments even if we have to have less rich data types in the actuals. Subrules 2 and 3 didn't change we believe.

Rule 4 changed a bit. The idea is that name resolution may be mixed which previously was not allowed by these requirements.

PB: Is there a separate section on the data type conversion rules or is that something that Ken is working on? If we are allowing all SV types in the formals then there must be type conversion rules to determine which actuals may be allowed?

JH: Anything that deals with that question would be in this section. I don't think that there is anything more specific in what we have provided.

PB: It sounds like that is a requirement created by your 3.1.

JH: Yes, but 3.1 is intended to treat the case when the actual is in the intersection. It must be valid SV and VAMS.

PB: We have one of two possibilities. 1. We only allow formals that can be converted to an actual expression that is in VAMS today. 2. We create new rules. What about the example of typedef. What if I have a typedef of a parameter as a formal. What are the rules on the actual there? What conversion rules need to be in place?

JH: My hope is that we can rely on what is defined in SV. I don't know how that will work for analog quantities. I have this distinction in my mind between expressions that are really digital expressed in VAMS constructs as opposed to expressions involving quantities that come from VAMS and don't exist in SV.

PB: When you say quantities what do you mean? Potentials, flows, data types?

JH: I could mean both. We have also talked about real and wreal types. My guess is that yes, we will probably have to say something about what the connections mean and the type conversion more in the cases where the actual expression is a potential or an expression involving a potential or a VAMS event expression. If for example, the actual argument is a bit vector then SV should already say how that bit vector can be connected to packed structs or unions.

PB: Okay there are types in SV that simply do not have the potential to be converted from a VAMS data type. Are you going to allow those types in the formal?

JH: At this point we would have to disallow them. If we are going to live w/ the requirement that all of the actuals have to be VAMS expressions then that is the case.

PB: So this section of the requirements will eventually deal w/ that?

JH: Well, it may be a part of the technical sketch on the way to defining a language that meets those requirements.

-- ScottLittle - 08 Jul 2009