• 0000000000000001000 Qamar Alam
• 1111111111111111111 Himyanshu Anand
• 0111111110011111101 Kenneth Bakalar
• 1111101010110110111 Prabal Bhattacharya
• 0000000000000011000 Sri Chandra
• 0111101111111111110 Eduard Cerny
• 1110111000010110101 Scott Cranston
• 0000000000000001000 Dave Cronauer
• 0000000000001100000 Dejan Nickovic
• 1101110111100100000 Mike Demler
• 0000000000000000000 Surrendra Dudani
• 1110000000111111111 John Havlicek
• 1110001100100000000 Kevin Jones (RGG Leader)
• 0000000111111111101 Jim Lear
• 0000000000001110111 Top Lertpanyavit
• 1111110110111111111 Scott Little
• 0000000000000100000 Erik Seligman
• 1010000000000000000 David Sharrit
• 0000000100000000000 Murtaza

Decisions:

Action Items:

1. Ken Bakalar to provide description of how to connect to SystemVerilog integral types with his requirement that all actual expressions in port connections of VAMS-SV instances parse under Verilog-AMS.

Details:

HA: Ken, do you have the requirements ready?

KB: No, I should have it ready soon.

HA: So, maybe next-to-next week it will be ready?

KB: Yes, I need to talk to compiler experts.

HA: Ok, lets go over the requirements from Jim. They are listed on the requirements draft webpage.

JL: I am advocating that we minimize the language changes and suggesting that the analog engine can be forced to a time point by a digital engine.

SL: Is VAMS @timer adequate for this?

JL: It is a periodic thing, what I am suggesting is that when ever I think the transients are complete, I am going to go ahead and take an accurate measurement. It may not be periodic.

SL: @cross does not have to be periodic.

JL: @cross is in VAMS, I do not want to define the event in VAMS. What I want is that I do not want an event, I want the forcing of a sample point. This is just a way to say that I want a precise value at this time.

KB: The problem is that the synchronization between digital and analog engine is intrisic to the solver. So, the synchronization is implicit in the definition, it does not require explicit calling.

JL: This is not what I have seen with the simulators that I have used. As an efficieny measurement, the user specifies/probes into the analog and get an accurate value rather than waiting for the connect rule to update the value.

KB: You are not using the connect boundary at all, and you are using digital to look at some number in the analog engine. You are asynchronously sampling at your own.

JL: What happens in SV or VHDL, you have a real port and you are dependent on the boundary model for the value of the analog variable.

KB: You want to extend the interface so that it includes not only the digital stuff but also the analog variables. What you need is a quantity port like in VHDL-AMS.

JL: The connect rules have the tolerances and you get a time point pollution.

KB: If you occasionally want to view the analog values, you do not want go through connect module. Have an always block that references the analog value.

PB: The value that the SV demands from the analog solver is not dependent upon the time step.

KB: No, it does, it changes the time step of the analog solver.

KB: The ref port exists in SV. What we want is the ability to look into the analog simulation from SV. And if you reference the analog variable from SV into VAMS.

SL: Are we just not asking for analog expressions to be passed into SV?

JL: No, the analog value has time points, and between those two points there is significant amount of transients and there can be errors. We want to avoid that.

SL: Passing analog expressions throught ports, doesn't that give you the same thing. The raw value.

KB: What we need is the ability to sample the raw signal value without the connect modules. So, with VAMS on top we are going to instantiate a SV module with 'ref var' port which will reference the analog value.

SL: Isn't this what we were discussing in John's proposal. My understanding is that what you are asking is what John just stated.

KB: That is my understanding. That means we understand the ref var port in SV and VAMS context.

SL: If there is a var input port that implies a continuous assignment.

KB: We want to avoid that, and Jim is probably trying to avoid that.

SL: What in this case, is that the digital engine needs to query in this case.

KB: It is not a continuous assignment, it is just a reference.

HA: Is this not something of a cross between an event and continuous assignment? That the digital pulls these values as and when required, something like an interrupt to analog engine?

KB: No, in Verilog-AMS this is already allowed, if you reference an analog variable inside an always block, you get the current value. What we are proposing is that this needs to work across the VAMS and SV interfaces too.

PB: What in the always block you reference the analog value through a hierarchical reference rather than through the port.

KB: I don't like the idea of hierarchical reference, as you need to know the structure of the design.

PB: Right now, VAMS 7.3.3, it talks about access to continuous values from digital context, interpolation is to be used if the current time in the continuous and discrete corners differs, then interpolation is used to get the value in the digital context.

JL: If the digital side is probing frequently then it can lead to overhead, so just a sample of the time point without forcing a new time point.

SL: If the analog is running ahead, it does not officialy say it has reached that point, until the digital has reached that point.

KB: Whenever the event occurs, it can wake up the digital at the new time point.

SL: Is it not the same as continuous assignment.

KB: Yeah, yeah that is right.

SL: For accurate time points you need a @cross or @timer. And the second one is the continuous assignment. This is what I understand from the LRM.

HA: Do you want every latest time point, or there can be some time points between two points that you are interested in?

JL: There can be points in between which you maybe don't care about, so it could be periodic and not every time point as long as it does not force a time point on the analog.

KB: This is something like what people do in post processing. The unpredictable accuracy.

JL: Yeah, sometimes you want efficiency and sometimes you want accuracy.

JL: We are almost out of time, so we need to finish, I will just finish by stating that we need ability to procedurally create analog events.

KB: You just want an event. So, you justwant the crossing function of VAMS in procedure.

JL: Fair enough, you got me on that.

KB: My first reaction is do that on analog side and generate an event.

JL: And you end up splitting the checker.

SL: That will be true till we have a combined language.

HA: Ok, I believe this is good. Jim, your requirements, I believe, overlap with John's and Scott's requirements. Some are a bit different, but most are similar if not same. And this is a good sign, we just need to converge a little bit more. Next meeting we will continue with your other requirements.

-- AnandHimyanshu - 23 Jun 2009