Attendees:

• 00000000000000010000 Qamar Alam
• 11111111111111111110 Himyanshu Anand
• 01111111100111111011 Kenneth Bakalar
• 11111010101101101110 Prabal Bhattacharya
• 00000000000000110000 Sri Chandra
• 01111011111111111101 Eduard Cerny
• 11101110000101101011 Scott Cranston
• 00000000000000010000 Dave Cronauer
• 00000000000011000000 Dejan Nickovic
• 11011101111001000000 Mike Demler
• 00000000000000000000 Surrendra Dudani
• 11100000001111111111 John Havlicek
• 11100011001000000000 Kevin Jones (RGG Leader)
• 00000001111111111011 Jim Lear
• 00000000000011101110 Top Lertpanyavit
• 11111101101111111111 Scott Little
• 00000000000001000000 Erik Seligman
• 10100000000000000000 David Sharrit
• 00000001000000000000 Murtaza
• 00000001000000000001 Martin O'Leary

Decisions:

---

Action Items:

---

1. Determine how the various types of V-2005 arrays are stored. The main question is can we assume that they are all represented like SV packed types? - Scott Cranston
2. Verify that VAMS does indeed inherit all of V-2005. - Martin O'Leary
3. Create a proposal for referencing SV package items in VAMS and/or creating VAMS packages. - Martin O'Leary/Prabal Bhattacharya

Details:

---

KB: We are instantiating SV from VAMS either directly or indirectly by use of a bind. My proposed requirement was that the only types allowed as actuals are types allowed in VAMS. The question is can the formals be arbitrary packed structures? What I have done is extracted the relevant definitions in the e-mail with the exception of the integral types definition. An integral type is a bunch of bits strung together w/out any space between them. There are 2 state and 4 state types, but we are really interested in 4 state types here. The notion of type compatibility in SV is elaborate. The level of compatibility that we are concerned with is equivalent. We want to know if things are equivalent b/c if two types are equivalent we can associate them w/ each other w/out any special treatment. Section 6.22.2 (P1800-2009) states that equivalent integral types of the same length are compatible. We are also concerned with assignment compatibility b/c we are interested in port connections. In this case they don't even have to be the same length as there are number of rules about truncation or rounding. We conclude from this argument that what we are proposing makes sense. Something that VAMS knows about, a wire array, is equivalent to an arbitrary packed 4-bit structure in SV. Therefore the equivalent type of the creature is known.

SC: In VAMS are referring to dimensions on the left side or the right side?

KB: On the left side. In VAMS, I think that everything is packed.

JH: That would allow one abiding by the restriction you proposed to make SV packed types that are at least assignment compatible with VAMS types?

KB: Yes, the formal could be an arbitrary packed SV type b/c there is no need for VAMS to understand the type and SV can interpret as a packed structure b/c VAMS wired array is assignment compatible w/ an arbitrary packed structure. The formal can be one of these objects in SV and the actual can be what VAMS knows.

JH: If we are trying to access some aggregate quantity in the SV external module reference (xmr) can we access a member?

KB: The name better name something that is a packed structure array or union.

JH: As an example, you have a couple of different packed structures in the SV part of the model and you wanted to assemble something by selecting different members from different structs. Would you be able to write something in the instantiation to assemble those various components w/out using bit select.

KB: In general, we are going to want to be able to use an xmr name in SV. What sorts of things can we refer to? The answer is that we can refer to packed array, structures, or unions. They are known to VAMS and VAMS operators will work on them.

MO: When was packed/unpacked introduced into Verilog?

SC: Early in SV.

MO: VAMS is aligned w/ Verilog-2005 (V-2005). Are we sure that these distinctions are distinctions between V-2005 and SV?

KB & JH: Yes.

MO: We should check that.

JH: The unpacked parts enable the type checking. They remove the fast and loose rules of assignment w/ packed types. The unpacked dimensions are not allowed to follow those loose rules.

MO: My recollection is that in V-2005 I think for wires and integers you can have RHS ranges. Would that not suggest that there are unpacked arrays in V-2005?

KB: Either that would suggest unpacked types or that the semantics have changed.

JH: I don't have a clear recollection of what is in V-2005. I think that multi-dimensional arrays was added in V-2005.

SC: I am looking at the V-2005 LRM and you can have arrays of nets w/ range specifications on the RHS.

KB: You can only have one dimension on the LHS, right?

SC: Yeah.

KB: In SV you can have multiple dimensions. There is an open issue there w/ regard to the RHS of Verilog-2005. Is it defined what effect that has on storage representation. Does it have any effect at all? I am not sure.

MO: So, if it is undefined then what are the consequences? If it was defined it seems strange that SV would have defined it differently.

KB: When you have an unpacked dimension it doesn't say anything about the storage representation. Packed means something about the storage representation. If in fact V-2005 do pack the unpacked dimensions that is fine and legal.

JH: What you are saying makes sense. I would tend to say that we should try to align to the latest SV draft. We could say that if in preceding standards things were defined hopefully they are compatible w/ the current definition.

KB: If needed we could update the definition in VAMS.

MO: That seems like a reasonable approach.

KB: An SV expert would be able to answer this.

JH: Maybe, I am not sure how deeply the V-2005 standard sank in.

SC: V-2005 doesn't talk about packed/unpacked.

JH: KB, by and large I think that what you have presented in very encouraging. If we are talking about trying to get packed data from the SV part of the model into the checker then we have a lot of flexibility w/ the rules described. Did you take a look to see if SV function calls could be supported in the actuals?

KB: There is not any way to define the scope so you could access an SV function call in VAMS as an actual. The expression is evaluated in the context of the instantiation. There is no way to give the function name a meaning. You certainly can't use an xmr for a function in VAMS. What can VAMS functions return? Only scalars, no?

MO: Whatever V-2005 allows.

KB: The arguments could be xmr to SV, but the function definition would have to be in the VAMS world.

JH: You could use a function to arrange the pieces in a VAMS understandable way and return that as a VAMS understandable type.

KB: Yeah.

JH: Those limitations may be reasonable for this phase. You have to reconcile the data w/ the VAMS types at some point. There isn't a chute to push SV organized data in an organized way through VAMS to SV. You have to reduce it to a VAMS type that is compatible. We have talked about this a long time and we need to live w/ that sort of limitation. It may require a bit of data marshalling, etc. It will not be a significant impediment.

KB: It has the advantage of not making implementers have problems.

MO: It wouldn't be too hard to allow package references. We have pulled in certain SV features when it wouldn't cause too much trouble. Package reference to my recollection might be one of these things.

KB: There are a lot of stuff in packages that aren't allowed in VAMS.

MO: I was just talking about a reference. You could reference it but not include it.

KB: If you make the package visible then all of the items in the package are visible. That is dangerous.

SC: You could make them visible but not allow them to be used.

KB: Can I use a variable declared in the package as an analog variable?

MO: That would be defined as owned by digital.

KB: VAMS defines ownership by first use.

MO: A package reference would be an xmr.

KB: xmr's to analog variables are illegal so that would be ok. I don't think that we can require this that AMS verification is impossible w/out it.

MO: This would be pretty useful. We could live w/out it, but it would be appreciated by many people.

JH: That is consistent w/ my vision of what will be going on. The digital parts of the code will use these things and it will be useful to support that. That way the designers don't have to translate them.

KB: The objective is to be able to define a function whose arguments are of packed types and whose return value is a packed type and call that function from VAMS.

JH: That would be a reasonable compromise. You have to live w/ the packed types. Just craft your package so that you use the packed types in that sort of package. Make that available when you hookup your assertions. I would be happy to have limitations to what goes into that package.

KB: Can it have shared electrical terminals in it?

MO: That would not be necessary. It would be more about sharing information already available to the digital blocks w/ VAMS.

KB: It isn't about sharing electricals then?

MO: No.

JH: Function definitions and constants would be helpful to me.

KB: I think that VAMS only has scalar return values. Unless we extend VAMS to allow functions w/ composite types.

MO: I think that we inherit from V-2005 and you can return packed objects. We need to verify that for sure. Analog functions are different.

SC: In V-2005 you can return packed arrays.

MO: In VAMS you can't call a digital function from an analog context, but it might be a reasonable thing to do.

SL: What are the open questions and who would be willing to get answers?

JH: Verify that the arrays created in V-2005 are stored as packed types. Verify that VAMS does indeed inherit all of V-2005. What could be in a package that is acceptable references from VAMS? What limitations would we have?

SC: I will take the V-2005 storage question.

MO: I will take the stuff about VAMS inheriting from V-2005.

KB: What is allowed in a package in SV?

MO: In VAMS it would be referencing items from the package, so we are more concerned w/ what is referenced and not what is allowed.

KB: It is problem. How do you do error checking?

MO: If someone does the reference and it isn't a legal type then error out in elaboration.

JH: I think it is an elaboration time check.

MO: Simulation time check isn't good.

KB: I think that package references are checked at compilation time. I think that the package already has to exist when you compile it. In a package you can put parameters, data, etc. (see section 26.1 in P1800-2009).

MO: I can do some research on that.

KB: The question is whether we should restrict what is contained in the package or whether it is whether we restrict what is referenced. It requires that someone inform VAMS about objects it may not know about.

MO: If it uses a xmr it should be outside the namespace.

KB: You can import the package and make everything visible

JH: We need to review the name referencing rules for importing a package.

KB: What we are talking about is a package extension to VAMS.

JH: Eventually this will happen and we need to look at what restrictions are reasonable and needed now. We need to figure out what won't cause backward compatibility issues.

KB: This should be discussed w/ the main committee.

MO: I can mention it, but I think that this committee is like the compact modeling committee which recommended a set of changes and then the main committee accepted/rejected their recommendations. What are the key points of impact right now? It seems that allowing packages is the biggest one at this point.

KB: It seems like a VAMS package is a cleaner way to do this.

JH: That may be fine once we know what a VAMS package is.

MO: I am worried if we define a VAMS package that might not be helpful to the users. They are SV users and happy w/ that. They need to add some AMS and wouldn't really want to create a new package for the VAMS that is a subset of what they have already. That is why I think allowing legal references is better from a user point of view.

JH: That is a good point. If the types are of integral types and the typedefs are of packed types then that should be okay.

KB: Then maybe we would need to introduce structs into VAMS? If something can be imported and used in VAMS then it should be allowed to be declared in VAMS. We should try to maintain this type of regularity at every stage.

JH: I disagree.

MO: I think that it will be very hard to be too regular until we have the unified language. We are trying to solve problems for the user community and that is the higher priority. Regular but not useful is not a good result. We do need to be careful with nonregular features.

KB: We do have functions and built-in functions in VAMS that can be used as well.

-- ScottLittle - 24 Jun 2009