• 11111111111111 Himyanshu Anand
• 01111111100111 Kenneth Bakalar
• 11111010101101 Prabal Bhattacharya
• 01111011111111 Eduard Cerny
• 11101110000101 Scott Cranston
• 00000000000011 Dejan Nickovic
• 11011101111001 Mike Demler
• 00000000000000 Surrendra Dudani
• 11100000001111 John Havlicek
• 11100011001000 Kevin Jones (RGG Leader)
• 00000001111111 Jim Lear
• 00000000000011 Top Lertpanyavit
• 11111101101111 Scott Little
• 00000000000001 Erik Seligman
• 10100000000000 David Sharrit
• 00000001000000 Murtaza

Decisions:

1. None

Action Items:

1. None

Details:

KB: What is an AMS-SVA module?

SL: It allows all of SV plus the dense time assertions.

KB: The intent is that the actual is on the lhs and the formal is on the rhs.

KB: I think that we need to define a discrete domain. If you have an analog variable that is constantly changing you will end up with an unending stream of update events.

JH: Why is that a problem? Suppose it is not observed? When is it observed?

KB: Right now in this case you will get an unending stream of events.

JH: I think that simulator implementers can work around these issues.

KB: I think that this would be extraordinarily expensive especially in the case of assertions. If we have events that are changing on every analog solution point then we have to test.

KB: An analog variable assigned under the control of an analog event has a digital quality to it and doesn't change at every analog solution point. An analog variable which is free will often change for every solution point. I don't think that we want to reevaluate the assertion in SV on each analog simulation point which puts us in a lockstep at every point.

JH: Why would be evaluating the assertion at every point? That depends on the assertion.

DN: The question is if we interact w/ the analog via events or if we pass every value and do the comparison of every value.

KB: The question arises why are we passing real values up to SV.

DN: I think that we should only pass events to the digital engine.

JH: Those events may not exist in the analog engine. I don't want to have to create the observables in the AMS model. I want the observables to be created within the assertions module. Then within the assertions module we can create the events in the assertions.

KB: Your point is that the actuals contain the crossing functions. By the time it gets into SV it is values and events. The important issues are the passing of events and logic levels. The passing real numbers and integers would not be used in a relational type crossing. You couldn't say a > 0.5 and expect it to sync. You would have to use the cross operator in the actual to do this. What happens when there are real variables changing all of the time. We don't allow it in our implementation.

JL: Are you talking about dense time real variables?

KB: Yes. Any variable that has not been sampled by an analog event produces a stream of events and dominates the simulation time.

JH: There was a similar air of fear around digital assertions. There were people saying we can't do this or should restrict that. In practical cases this should be solvable.

KB: I won't implement it that way b/c it is too expensive.

JL: One alternative is that the analog engine could be treated as a separate entity. The expressions in SV are powerful enough, but we don't have access to the analog events. If we can get access to analog events and values we can bypass the language extensions. You have file buffers, so why can't you have analog buffers. Why can't you sample and analog value triggered by an analog event? Is there an alternative to this language stuff?

JH: We want the language stuff.

JL: I don't agree with that. The assertions that exist today are powerful enough to handle the analog needs.

KB: We want to access real time in assertions. We need that.

JL: I don't agree w/ that. If you have access to the analog values you should have access to the analog time.

HA: The idea of assertions is to formalize all of this information into one language. You can do all of this right now but it is very ad hoc. It is the same reason that SVA came into the digital world. It formalized these things. If you are writing ad hoc you can do everything an assertion does, but you have to rewrite it in an ad hoc.

JL: I think that we are going to come up w/ a set of assertions that will solve the problem. We need function calls to do this. Analog stuff doesn't map into the analog world.

DN: I disagree. Even if you can access time in the assertions world this won't be enough. Reading time stamps from step to step might not be enough. You may miss the value that you want to compare because of different sampling rates.

JL: Those same problems exist in the waveform viewers today. You can still make the measurements even if you don't have all the points. If SV has access to the time points you can do the same measurements.

DN: The real time operators abstract away all of these details so that you can get access to the items you need. This extension would not change the syntax much.

JL: What real time operators are you talking about?

DN: I think we are talking about the same things, but you are talking about it from the monitors point of view.

SL: We are going to allow user defined functions.

JL: I would like to see us allow events like the cross event.

JH: I want to rearticulate the big vision. When we get a rendering in English we would like to be able to write a rendering of that in assertions where the items we need are first class citizens in the assertions language.

JL: When you access the analog values we need to come up with a construct we shouldn't try to look at instantaneous value.

KB: I fundamentally disagree w/ that. The assertions need to affect the evaluation of the engine.

JL: The assertions may need certain types of samples or sample on certain types of events.

JH: I have had vision that we need both modes and they will give different results.

KB: Nothing that we are saying precludes this.

HA: We have agreed previously that both online and offline modes are needed.

JL: Having events is a good idea. Accessing the values we should treat it like our file systems. We should access them through buffers.

KB: I don't like the metaphor of the fs and the buffer. The point is to desynchronize. The idea is to run things and not wait for the result.

JL: I don't agree that we are going to desychnronize. For example if we see an event then we want to look at the last 3 ms. We could look through the buffer for that.

KB: That is the point of the LTL.

JH: A lot of this strikes me as implementation specific stuff. We need to come up w/ an ideal real time semantics and then see how this works in reality.

JL: I think we can do this through a library system.

JH: The library sytem won't give me the assertions I want. I want first class access to all of those items. In an integrated SV-VAMS I can have this. Right now we are trying to take a first step in this direction.

JL: I think you can make this fairly clear using functions.

HA: All these points are valid points. However they been discussed in the prior meetings, let us not to revisit the decisions. The requirements documents reflects the scope what was decided upon and the needed extensions relating to time domain properties.

-- AnandHimyanshu - 07 May 2009