• 00000000000000010000101 Qamar Alam
• 11111111111111111110101 Himyanshu Anand
• 01111111100111111011101 Kenneth Bakalar
• 11111010101101101110110 Prabal Bhattacharya
• 00000000000000110000101 Sri Chandra
• 01111011111111111101101 Eduard Cerny
• 11101110000101101011101 Scott Cranston
• 00000000000000010000000 Dave Cronauer
• 00000000000011000000000 Dejan Nickovic
• 11011101111001000000000 Mike Demler
• 00000000000000000000000 Surrendra Dudani
• 11100000001111111111110 John Havlicek
• 11100011001000000000000 Kevin Jones (RGG Leader)
• 00000001111111111011101 Jim Lear
• 00000000000011101110000 Top Lertpanyavit
• 11111101101111111111111 Scott Little
• 00000000000001000000000 Erik Seligman
• 10100000000000000000000 David Sharrit
• 00000001000000000000000 Murtaza
• 00000001000000000001011 Martin O'Leary

Decisions:

Action Items:

Details:

HA: Scott, can you summarize what transpired in the last meeting as most of us were absent in that meeting.

SL: PB talked about the packages and he did send out an email. The efforts and the benefits did not make sense. So, packages would make sense in the SV-VAMS merger. Also, JH updated his section under requirements on Twiki.

HA: Would you like to continue where we left off on your requirements JL.

JL: The fourth bullet item is to dynamically create points. When an event in analog happens you can trigger an event in SV. Where SV can do an @analog_event and it would trigger the event in digital when that happens in analog.

KB: Need to have SV to define precisely when the event happens and also that when analog event SV gets notified at that time.

KB: VAMS has the forcing of time point intrinsically.

JL: You don't always want that, as it is a costly operation. You don't need to do FFT when you are powering up or your transients are being solved. There is a significant startup period where you do not want to forcing the time stamps.

KB: The digital initial condition. They allow access to propogate the things, while they settle down. We provide an option to turn on the analog machine under program control. The second issue is that during the course of simulation, when you want to stop generating @cross events since they are not interesting. SV already has that capability to disable the crossing events.

JL: You need the ability to change your crossing threshold. If your power supply changes, you may need to change your crossing dynamically.

KB: Is this particular to verification or SV. And you do have that control in VAMS.

SL: You can do it and I have done it. I believe manual allows it and many implementations support it.

JL: The checker has to be able to specify that the crossings need to be protected.

KB: The way to do is to instantiate the SV checker module and that imports the information from digital engine.

JL: It would be best to control that from SV to adjust the VAMS simulation depending upon the assertions.

KB: You can always force the time stamp by simply sampling the VAMS variable. The very accurate sampling of analog engine allows simulators to synchronize.

JL: Is it true even if you have no timers or crosses.

Sri: When there is no analog time then interpolation will be used.

KB: Exactly what algorithm is to be used is not defined by the LRM.

Sri: Looking at 2.2.3 section 7.3, it says interpolation is used unless the analog value is assigned in that time step. And there is a ticket in Mantis db to integrate both interpolation and synchronize. We don't synchronize per LRM today. And we discussed this in last VAMS meeting, as it came from ASVA.

KB: There is no way a modeler can tell what kind of interpolation is going to be used. 1st order or 5th order.

JL: The type of interpolation should not be specified, as it depends on the type of problem.

SL: LRM gives the simulator options, 1) do what you are doing and use interpolation or 2) solve and synchronize.

KB: I think this an over-specification in LRM. LRM should tell me what results needs to be achieved not how to reach that result.

JL: Boundary models have sensitivity and they force a time point if the value changes by delta and then the value changes depending upon the threshold.

HA: Lets not talk about the vendor implementations and focus on requirements.

JL: Can you access V(a) from digital side.

SC: Sure, you can.

JL: Why do you need connect modules?

KB: To digitize and convert analog value into a step function.

JL: What you are saying is that you force a time stamp whenver we observe it.

KB: Yes.

JL: Sometimes for speed and accuracy you don't always want to force a time point.

KB: The justification goes like this, the analog results/value we are getting is fairly accurate and I am satisfied by the accuracy I get and I want to use the digital engine as a waveform viewer + processing with digital solver.

KB: One is to define a new way to access the analog variables.

JL: Every time a solution time calculated then the digital can capture that new value that has been calculated. Let me capture that.

SL: That time does not come with it, and it gets mapped to digital time. Does the digital just know that the event happenned or it gets the accurate time.

KB: That happens with @cross too. Analog time is fine grained and digital time is not that finely grained. In VHDL-AMS, you can't use time too large.

HA: What kind of events are we talking about here. Is this going to increase the communication overhead?

JL: The event will be a single event for all solve points.

HA: So, the event is generated once for all variables and not different events for different variables.

JL: Yes, that is how VAMS solves. When it solves, all values (mostly all) change values.

KB: We got 2 different timescales, analog is floating point precision, digital is fixed precision. How do you go about synchronizing between the two engines. The time at which the always digital block executes is not going to be the same. There may be more than one analog solve point. My argument is that such small differences don't matter, and if they do matter then lower the digital timescale.

JL: Can we do the buffering in analog engine today?

SL: If you want the analog commit point, then that is not provided today.

JL: If you want to fill the buffer from this, it is ugly but you can do it, check for the value change.

KB: To implement this in current VAMS, of how to do it.

JL: Something like @always(V(a)), but that is not legal.

KB: It is also not executed at increasing time.

ML: You sample a new value store it in the array.

KB: You do not want to store the whole waveform forever, you just want a window.

SL: How do you know the abs time the value changes.

JL: Like to have access to waveform datapoints in SV and that is the following point for the buffer. It does not have to be synchronized all the time.

HA: This seems like if you want a waveform based offline checking if you had the analog time points and digital value/time pairs. I can see why you may want to end the simulation if you failed early in the simulation.

JL: To do checks while in simulation. I see where you are getting at with the offline mode. But, having the ability to do while in simulation will help detect early failures and terminating the simulation.

HA: Ok, can you summarize this and whether there are any other requirements that we need to discuss in the next meeting?

JL: A global analog time point event for all analog values is going to be an acceptable requirement. Is that correct or someone has an objection?

ML: I would like to see why is it required and whether it can be accomplished with the existing language constructs.

JL: I will send out an email explaining why that is needed.

SL: The mail-list is almost setup and I will send out an email when it is finalized.

-- AnandHimyanshu - 15 Jul 2009