• 1111111111111 Himyanshu Anand
• 0111111110011 Kenneth Bakalar
• 1111101010110 Prabal Bhattacharya
• 0111101111111 Eduard Cerny
• 1110111000010 Scott Cranston
• 0000000000001 Dejan Nickovic
• 1101110111100 Mike Demler
• 0000000000000 Surrendra Dudani
• 1110000000111 John Havlicek
• 1110001100100 Kevin Jones (RGG Leader)
• 0000000111111 Jim Lear
• 0000000000001 Top Lertpanyavit
• 1111110110111 Scott Little
• 1010000000000 David Sharrit
• 0000000100000 Murtaza

Decisions:

1. None

Action Items:

1. None

Details:

JL: Scott Little's proposal does not make the language any simpler. Having expressions is required. Do we need to talk about analog expressions rather than analog assertions. The expressions were introduced to bind in order to limit the complexity. If you have the analog expression capability than you do not have to worry about the analog assertions, since they are built-in already.

JH: We do not have all the constructs that we want in System Verilog Assertions to express the analog assertions.

JL: What would be an example of an assertion from analog domain.

JH: We have envionsed a real time regular sub expression and also a real time version of temporal operators.

JL: So on the temporal side, regular expression matching type.

JH: Yes, that is one kind. The time advances are real time or dense time.

JL: Another thing that we can think of is the idea of classes. For example a probe class, that would take the netlist and then a cross class would have create events. Then it could have a sample class (really a sample buffer) and the constructor would take a probe and some parameter that would describe the kind of probes that would occur. There would be no forcing of the time steps from the SV. Another sample buffer could take digital time steps.

DN: I do not agree that this would be sufficient. If you have to relate them to some absolute time then you cannot use the cycle time to map to real time.

JL: If you want to specify the timing, then you would use the cross class or cross events.

KB: We are trying to agree on the overall approach and what you are saying is too much of detail.

JL: I agree, we need to introduce analog operators and analog expressions into the system verilog.

JH: That is consistent with our vision, that initially there will be a subset available till the SV-VAMS is integrated.

SL: The key to our proposal that in SV we want access to certain analog properties. The division of those into either SV or VAMS is not a sticking point. The other operators like ddt, idt etc. need to be considered.

DN: The two questions are orthogonal. The addition of operators and the time are orthogonal and can be dealt independently.

KB: I agree, you can use these expressions that are available in the instantiating enviornment.

DN: It would be important to reuse as much of SVA and one direction to go would be to extend the semantics. These dense time operators would be similar to what we already have. And this is something that I am working on right now.

KB: I don't think that there is any choice to go beyond that and do a delayed computation or delayed evaluation depending upon the context. Those things - "evaluating strings" is alien to SV.

JL: What do you think of my proposal of having classes.

KB: What we need is real value extracted from analog world, events and use them in assertions. So that the assertion language itself will use these. So, the question is how to name them and access them in each possible context. I am not comfortable with any solution which depends on the context of the expression. The bind mechanism is confusing because when you write the bind statement you are doing a remote module instantiation.

JH: I also have some concern, they are leading away from our vision of nicely integrated language which enables to write first class analog assertions.

KB: Which is what I said that we do not create any barriers to creating a nicely integrated language.

KB: If you look at my requirements, then people have looked at it and have said that there are pain points. So, people should focus on that rather than giving solutions. So what am I missing. People are hoping for a unified language.

HA: The whole idea of "bind"

SL: Let me more precise, the values on analog nodes and branch (currents and voltages). If we just focus on SV then we could have dense time and that is nice, but not having access to analog nodes and branch values is restrictive. So, this is a like a small step towards the full integration of SV-VAMS.

KB: But, as soon as open that can of worms, access functions referenced by hierarchichal names.

JL: The intent is there will be a set of re-written template classes to provide access to analog values and events.

HA: How do you propose we access these functions (values from nodes and branches) into SV from VAMS?

JL: Don't know, maybe through classes and some other way.

JH: Trying to express compound expressions in a bind is a bad idea and you (Ken) convinced me about that in the last meeting. The actuals in those instantiations (existing SV or VAMS) need to make sense in the actual scope of the instantiation context.

KB: The reals are in both SV and VAMS, they should not be restricted, meaning they can be accessed from either side. The events have to be added to VAMS (They are not allowed on ports). After the discussion of bind, it is an appealing extension to VAMS. Maybe it is out of scope, we need to focus on underlying mechanism - module instantiation.

JH: What connections are allowed as you instantiate or use bind. Is there a real port already?

KB: No, there is wreal but that is a big mess.

JL: If and when SV is allowed to be instantiated within VAMS, is the question of discretization still not there?

KB: No, the cross events are sampled.

DN: These will be the basic requirements - time stamped events, annotated with real numbers. Or the boolean value. The basic communication between SV and VAMS that VAMS would be able to give events with time stamps.

JL: When you talk about having these events in VAMS, then your expressions for events are in VAMS. But, then that divides the logic of assertions into SV and VAMS.

KB: Not necessarily, we would extend to reference the analog SVA.

JL: So you are extending VAMS to include analog SVA.

KB: Yes, that is the proposal.

DN: Could we not have the analog events are uninterpreted events that VAMS interprets and is not known to SV. Would you rather have one specification or you would split the specification into digital and analog parts?

KB: If you were to write assertions in SV, then it would refer to only SV and its extensions and you access the events from the ports from VAMS.

-- AnandHimyanshu - 28 Apr 2009