Attendees:

• 000000000000000100001 Qamar Alam
• 111111111111111111101 Himyanshu Anand
• 011111111001111110111 Kenneth Bakalar
• 111110101011011011101 Prabal Bhattacharya
• 000000000000001100001 Sri Chandra
• 011110111111111111011 Eduard Cerny
• 111011100001011010111 Scott Cranston
• 000000000000000100000 Dave Cronauer
• 000000000000110000000 Dejan Nickovic
• 110111011110010000000 Mike Demler
• 000000000000000000000 Surrendra Dudani
• 111000000011111111111 John Havlicek
• 111000110010000000000 Kevin Jones (RGG Leader)
• 000000011111111110111 Jim Lear
• 000000000000111011100 Top Lertpanyavit
• 111111011011111111111 Scott Little
• 000000000000010000000 Erik Seligman
• 101000000000000000000 David Sharrit
• 000000010000000000000 Murtaza
• 000000010000000000010 Martin O'Leary

Decisions:

---

Action Items:

---

1. Update your assigned section of the requirements document on the twiki to be consistent with our current discussions. - All
2. Provide examples to show the type of data marshaling that may be expected. - John Havlicek

Details:

---

SC: There are two different types of arrays. For variables and regs things are packed except for the real cases. For the nets because of the fact that you can't do things with entire arrays or multiple element parts it doesn't make sense to pack them. While the individual elements are packed the entire array is not.

KB: In V-2005 can you have multiple packed dimensions?

SC: No

KB: In V-2005 can you have multiple unpacked dimensions?

SC: Yes.

KB: In SV you can have multiple packed dimensions. They are interconvertible for assignment. In SV the ideas of packed/unpacked and net/var are orthogonal. Are you saying that you can't index the packed dimension?

SC: The packed or unpacked you can reference single elements. What you can't do is reference the entire unpacked dimension in V-2005.

KB: We may need to import some ideas from SV in order to make this mechanism work w/out it exploding to include everything.

SC: Those ideas are packing of what V-2005 only allowed as unpacked?

KB: I guess the extension would be multiple packed dimensions, so it would ease the passing of information.

JH: In 7.4.3 in p1800-2009 draft 8 the term slice is mentioned. It seems that multiple packed dimensions would be nice.

KB: We don't want to introduce things will nilly b/c they would be nice.

JH: Multiple packed dimensions don't exist in V-2005 and therefore VAMS. They do exist in SV and therefore are a possibility of something that would need to be added.

KB: Okay, so SV does use the word slice.

SC: In V-2005 in mentions that you can't do slicing.

KB: Oh, I see. Yes, it mentions that you can't slice. You can concatenate though.

SC: That concatenation creates a packed thing?

KB: It isn't concatenation though. It is a curly braces operator.

SC: Part select is the classic vector thing.

JL: Why are we talking about this again? What is the reason?

KB: We are trying to understand what sorts of capabilities VAMS has to allow us to bind xmr SV types.

SC: Yes, part select is the way to access a contiguous part of a vector or an SV packed array.

KB: Apparently part select and slice have the same syntax.

SC: Unfortunately, yes they do. There are some precedence rules to help solve conflicts.

KB: 7.4.3 in SV standard defines slice and part select.

SC: 11.5.1 gives the precedence rules.

KB: Integral types are packed, so they are all equivalent to the left dimension of V-2005 except you can have multiple of them. The only thing that is an integral type in V-2005 is an element w/ a left hand dimension. You can make the array as big as you need. That is painful to reference, but maybe we don't need to reference it.

SC: You can convert a packed array to an unpacked array.

KB: We get the capability we need by passing data through VAMS without adding anything.

SC: You can use generate blocks to quickly write continuous assigns of an unpacked array to a packed array.

KB: If the array is unpacked array to start with then we are okay. There is no reason you couldn't pass unpacked arrays as well as packed arrays of integral types.

SC: You can't pass unpacked arrays through a port. V-2005 section 4.9 state this. The port connection rule doesn't allow array nets in V-2005. I would say this is not legal. You can pass packed arrays but not unpacked arrays.

SriC: It looks like you might have to split it up and pass it individually. You will have to create some temps and concatenate them.

KB: This is difficult to believe. You can pass an array that represents memory.

SC: That is a variable.

KB: The rule that the port is a continuous assignment still remains.

SC: It appears that you can't pass net arrays, but maybe you can pass reg arrays.

KB: This might be an area that we need to make an extension. It might be useful to pass entire unpacked arrays through ports. Maybe not. Maybe we should just stick w/ minimal extensions.

SC: What is the context?

KB: We are trying to pass items through an SV instantiation w/in VAMS.

JH: Right and my point is that we would like to avoid the rearrangement of data as much as possible. Some of this is unavoidable. If you have an unpacked vector you would need to repackage it.

KB: For the main requirement, a xmr to an SV object that is being used in an SV instance in a VAMS context. What I was insisting is that the type is something that is know to VAMS. B/c of the interconvertibility of integral types the VAMS compiler can treat any packed integral type as a packed integral type regardless of the SV types. We are making one hideous long extension to VAMS and that is instantiating SV. The narrower we can keep that interface the more likely it is that someone will implement it. We also want to keep things open for the larger SV-VAMS integration. I have a secondary motive to keep it as simple as possible to keep it quickly implementable.

SL: What is the consensus?

SC: I would like some examples before making a decision.

JH: We could do something.

KB: We could have a 2-dim unpacked array or can it be n?

SC: I think it can. The curly braces are 0 or more in the BNF, right? I don't think there is a constraint in the text on this.

KB: Okay, let's assume it is n dimension. The example is to take an n-dimensional array in V-2005 and pack it into a vector in V-2005.

SC: I would rather see some examples of the general thing we are trying to do.

HA: Are we happy w/ the requirements? Are we done w/ the requirements? We seem to be talking about implementation.

KB: I don't think that the instantiation of SV in VAMS aren't in the requirements.

JH: I thought they were in the section I added. I think that I was asking for more and need to revise them to be more restrictive.

HA: The reason I am asking is that should we solidify on requirement and then look at implementation and see what falls away?

KB: Well, sometimes you have to look into the consequences of the requirements. I think that the requirements document should be there and we can hold to it.

JH: I think that we should review our twiki page and get that to align w/ what we are talking about in the meeting.

KB: That is a good idea to advertise the existence of the requirements. Unfortunately I am going to have to write the langague requirements section. It is almost easier to draft it and see the reaction. I want to make sure that the insantiation and what is allowed is clear. I also want to ensure that bind is allowed. Those are the ideas that are missing from my discussion. I am going to be gone most of July (only here in 2 weeks).

HA: Can I propose that the owners take a look at their sections and try to refine it based on the requirements. Is this an acceptable solution to everyone else? That way we can be more focused.

KB: There is a rising interest out there among the customers for some sort of mechanism for formalizing the analog assertions.

HA: That is good news.

KB: If we announce a set of requirements there will be plenty of interest.

HA: If we can merge the requirements on the language from Jim, John, and Ken that would be nice. Some work may be necessary to combine them.

JL: Why don't we at least talk about what I have posted. I don't think we can merge them until people understand what I am saying.

KB: I think that Jim is talking about a fundamentally different approach. I am not sure that a merger is in the cards. It make be a choice.

JL: We have covered the first 3 bullets. Any questions?

KB: This can be thought of as just a control of precision between bullets 2 and 3. Tight precision gets you 2 and lower precision gives you 3.

JL: I don't object to that. The 4th bullet is the ability to procedurally create an analog event. We could have a procedure that indicates to the analog engine when it should have timepoints. All we are doing is informing the analog engine to detect certain crossings.

KB: That is what we do w/ VAMS today.

JL: That is w/in VAMS. The checker should be able to specify these things in VAMS.

KB: You want to move the crossing operator of VAMS up into SV? However you might want to disguise it.

JL: That is accurate. I'd like to disguise it in someway as a procedure that won't require a language change. The important thing isn't the events, but you are just informing the analog engine what crossings need to trigger analog events.

KB: What you are talking about is interfering w/ the analog solver and telling to stop at a specific point. I think that these interesting points can be specified as crossings.

JL: You may randomize your power supply, so the threshold may change depending on what your power supply is. Those parameters would be driven out of the digital side. It just seems logical to put those constraints on the SV side.

KB: The paper by Pallab's group was published in JACM in March. It is improved and he described an extension to OVL that seems to do this. I would like to know the comparison between his stuff and your ideas.

JL: I am not sure how OVL controls the timesteps. You still need the ability to specify the precision.

KB: They use the crossing operators and it is embedded in the library.

JL: Can those change dynamically?

KB: Yes.

JL: Are those on the SV side?

KB: He is working in a system that doesn't differentiate between SV and VAMS. If you are working in a world that doesn't differentiate which is what we are talking about then his work is directly applicable.

JL: The important thing is that there is some mechanism of forcing the time engine. The parameters to the cross operator need to be controlled from SV.

KB: That sounds like a requirement. You want the ability to control the parameters to cross from the SV side. If we give the ability to relax the tolerance indefinitely then we get the non-interference version.

JL: You also need the ability to sample at a precise point for things like FFT.

KB: In the case of the FFT you can't interpolate and need to actually calculate the point. If you want something that is expensive then that is it.

JL: Some simulators already support this.

KB: You can do that, but you can't turn it off or vary it.

JL: That is true and is a bit of a handicap. I think it is important that SV can control this.

KB: Just in VAMS module suppose you have an always digital block. This should give you what you want based on the synchronization algorithm.

SL: Doesn't the LRM allow for interpolation here?

KB: The value should still be accurate.

JL: I have had problems with those values giving a clean FFT.

HA: We are running out of time. What are the action items?

KB: Everyone needs to clean-up their sections of the requirements twiki based on the current discussions.

-- ScottLittle - 01 Jul 2009