• 000000000000000100001011 Qamar Alam
• 111111111111111111101011 Himyanshu Anand
• 011111111001111110111010 Kenneth Bakalar
• 111110101011011011101100 Prabal Bhattacharya
• 000000000000001100001010 Sri Chandra
• 011110111111111111011010 Eduard Cerny
• 111011100001011010111011 Scott Cranston
• 000000000000000100000000 Dave Cronauer
• 000000000000110000000001 Dejan Nickovic
• 110111011110010000000000 Mike Demler
• 000000000000000000000000 Surrendra Dudani
• 111000000011111111111100 John Havlicek
• 111000110010000000000000 Kevin Jones (RGG Leader)
• 000000011111111110111011 Jim Lear
• 000000000000111011100000 Top Lertpanyavit
• 111111011011111111111111 Scott Little
• 000000000000010000000000 Erik Seligman
• 101000000000000000000000 David Sharrit
• 000000010000000000000000 Murtaza
• 000000010000000000010110 Martin O'Leary

Decisions:

Action Items:

Details:

HA: Lets continue the discussion where we left off last time. I believe we are almost done reviewing Jim's requirements.

JL: Real valued ports are not going to be satisfactory for assertions inside the SVA. Scott Little and I looked at it and he did some FFTs and concluded the synchronization is required and interpolation is not good enough.

SL: It shows reasonable need for synchronization over interpolation.

JL: The time/value pairs are stored in the buffer so that analysis of the assertion can go through and check that the waveform behaved properly. The second types of buffer is that those values are available when they are needed by the assertions. One thing is that when we observe a value it forces the digital time point.

SC: Doesn't that violate that the assertions should not change the behavior of the circuit.

DN: Will you need the first kind of buffer, since you will get the value of the time point.

JL: You want to ensure that the transient time step is resolved. Also for FFT, regular time points are required. Whether the buffers or not is debatable.

HA: If you have access to all the time/value pairs, you can create the buffers the way you want create. I may want to create a buffer of not all time points but only some, and given access to time/value pairs I can decide which ones I want to keep.

JL: You can build your own buffer if you have access to when those time points. And there is the debate whether the digital time clock is accurate.

HA: That's another point, lets say your digital time scale is 1 ns, but the analog simulator has produced more than one time values for the variables, will the digital assertion see only a single point? Which point?

JL: That's an excellent point and I don't the answer to that one as to how that will be resolved.

SC: Are we talking about post-processing data on the waveform trace?

JL: Sort of. At the end of the pattern you did some checks, up until the present the time.

SC: It doesn't fit in the HDL assertions.

JL: If you want to check for some high powered assertions.

SC: You can run the whole simulation and run these assertions. Or the other is, during the simulation these assertions are triggering and you use buffer. Why is the later preferable over the former (post-processing).

JL: The advantage is that you can change the simulation/stop during the simulation.

DN: The assertion language should be kept separate from these issues. In the SVA too, you can do offline or online. The language should be abstract and not take into account these implementations.

JL: That's fair, I don't want to argue with it.

DN: The assertions should be what you want to check not how you want to check.

SL: If the assertion affects the time steps then the language needs to say something about the it is evalauated.

DN: The assertion will be checked against the data that is produced by the simulator. It will be correct/incorrect according to the data that is provided. And it is natural that the assertion will give different results because the data is different. The language, should be separate from this, if you have some capability to control the accuracy.

JL: The simulators have options to force time points at regular intervals. But, some test cases may require (out of band) higher frequencies and some may not require that higher frequencies.

DN: I agree with you but in my opinion there should be a separation. But, then it is very important how this data is generated but this is an issue which is orthogonal to the assertion itself. It is very related, but it should be separated from the semantics from the language.

JL: I completed agree with you on this aspect. Files are not part of the language, and they are implemented in packages. I don't think this is language necessity.

HA: I think of @cross as purely an event, how it is implemented by the simulator, is not my concern. I want an event and the analog simulator may force a time point, or it may have already calculated the time point which it can use to generate the @cross event. So, it is abstract in that sense.

DN: Ok, then I agree that its an abstract event. And it boils down to the problem of syntactic definition.

JL: I don't think the cross should affect the simulator. The analog engine is doing its job, it will not affect the outcome.

DN: One more reason it should be kept abstract, in future you want to use the language not for VAMS, but in some other language.

JL: Ken mentioned it and I have mentioned it today is the global analog event. We specify the crosses through procedural kind of constructs. Also, I want affect the threshold of the cross.

HA: @cross is already in VAMS and allows you to choose the threshold.

JL: SV can control that variable in the cross statement.

HA: But that assumes, VAMS-SV is already unified, since you are going communicating both ways and we don't have that right now.

SL: But, this is another communication and needs to be documented as a requirement.

JL: This is the same as forcing of the dynamic time points.

DN: Isn't it the same as the earlier possibility of forcing the time points through the assertions.

JL: Probably, do you envision we have some kind of procedural interface for this then instead of the assertions?

DN: It would be desirable to have the possibility from the user to just use the time points from the simulator and have the ability to force the time points. But, it should be a possibility and should be hidden from the assertion itself and not be a part of the language.

SL: So in some case you want to affect the simulation and in some case not, but not be a part of the language.

DN: It will be an external choice.

HA: That seems to be a static choice and not a dynamic choice.

DN: Yes, that is static choice but the effect should be dynamic.

JL: We had an example (a simulation of 10 hrs, FFT, etc) when we switch modes to another type of tests, we need to have a dynamic choice rather than a static choice.

SL: What you are saying Jim, could work in the mode Dejan is talking about, by disabling the assertions in the time steps you don't want to evaluate. There may be some extra modeling code outside of the assertions. Why it would not be useful to have the ability to check the assertion more accurately.

DN: You may want to have a single assertion that can be checked at different levels of accuracy.

HA: I think there is need for both types of assertions. It is not clear to me how the global static setting of the accuracy will lead to a dynamic controlled accuracy for the analog assertions. There may be two assertions, one of which requires a higher accuracy and the other requires lower accuracy. If the accuracy control is outside the assertion with no feedback, then I don't think it can be done. You will need some kind of feedback from the assertion, whether explicit of implicit.

DN: Yes, it would be something similar to what SVA and checkers do, if the left hand side is false, you do not evaluate the right hand side.

JL: The threshold on the @cross could be set to infinity in either direction to control that.

HA: What if you are inside the assertion and have already seen the @cross event?Dejan, would it be possible to out something that you are thinking down and share it with the committee. I will set you up for Twiki access. Jim do we need to discuss something else?

JL: No, we are done, I would like to access and fill the buffers and I believe the real variable ports are not sufficient for that. VHDL has some kind of synchronization attached to the ports which is missing in VAMS. So, that along with the dynamic control of the accuracy are my main concerns.

SL: Jim, will you be willing to refine the requirements based on the discussions we have had, as Himyanshu is trying to go for the vote on the requirements.

JL: Sure, I will give it a shot.

-- AnandHimyanshu - 22 Jul 2009