• 11111 Himyanshu Anand
• 01111 Kenneth Bakalar
• 11111 Prabal Bhattacharya
• 01111 Eduard Cerny
• 11101 Scott Cranston
• 11011 Mike Demler
• 00000 Surrendra Dudani
• 11100 John Havlicek
• 11100 Kevin Jones (RGG Leader)
• 11111 Scott Little
• 10100 David Sharrit

Decisions:

1. Discussion on static/physical properties led to the conclusion that is something which needs to be dealt with in Verilog-AMS committee. If the name/value can be accessed in VAMS then they can be used in assertions.

Action Items:

1. Update the Twiki site [Himyanshu]
2. Update document to reflect discussion on static/dynamic electrical properties [Mike]

Details:

HA: Have not done the update mechanisms.

SC: Why don't we have a single page.

HA: Sure, we could to that. Will it not clobber the simultaneous

HA: Time domain properties in SVA was agreed upon.

PB: What was decided about SVA?

HA: Mostly, as extension of SVA and focus on time domain properties.

PB: Was anything discussed about Spice properties?

HA: Spice properties were probably not brought up. But, given where we are in languages and given the technology, it was decided to extend SVA and focus on timed domain properties for now.

PB: What if we want to use device parameters in assertions? Something like what's there in .model card.

KB: Why would you want that?

PB: Want to say something about the .model paramenters.

KB: Particular model card or a particular model instance.

PB: Users refer to instances but can't imagine why not want to do that to the master. How do you refer to these properties heirarchically.

MD: .model card has parameters which do not change at all.

PB: A user had the following request - wants to build a condition "when a VGS of a specific transistor reaches a certain value, it wants it to remain for a particular time".

HA: Why is it any different from accessing any other voltage/current on a node. This seems to be more like an issue of VAMS and not assertion.

PB: Does Verilog-AMS allows access to static transistor voltages.

HA: Don't know, whether that is allowed in VAMS or not.

MD: Anything that is a terminal electrical property is accessible within Verilog-AMS.

PB: We internally differentiate between input parameters and output parameters.

SC: Can VGS change?

MD: The voltages can change.

SL: Accessing the static properties like Voltage Threshold is problematic in VAMS? Those are the features that will help us move to the next stage.

MD: Anything that is not in VAMS now is making it more complicated.

HA: Static properties are difficult, dynamic properties can be written as assertions.

PB: Many of these will be deferred to VAMS and then maybe come back to us.

KB: If you can name it you can refer to it, and if you can't name it you cannot refer to it.

SL: If these parameters show up, we want to access them in assertions.

KB: What are the type of variables - bool, int, real?

SC: What about the full gamut of unpacked structures in assertions.

SL: What structures are there for analog? Maybe that is something for the SVA committee.

SC: Something like complex wires, unpacked structs of real.

KB: I agree with SL that probably that is something for the larger committee. The expressions in the end are going to be in bits, integers and reals.

SL: We can revisit this in future. But I have not seen a real compelling reason for that.

HA: Maybe we should start focussing on requirements of the language, now that the scope has been more or less concretized.

SL: Does everyone agree to the scope being solid.

MD: Static physical properties, static properties, I am all for making that fully fleshed.

HA: From what has been discussed today, it looks like if you can access the name/value from Verilog-AMS you can access them in assertions.

MD: Yes, that something more acceptable as a definition.

HA: Ok, then lets focus on requirements on language.

KB: A strong statement that SVA will be a subset of AL.

HA: I agree that needs to be there.

KB: We might add additional operators, refering to dense time, real numbers, but not adding new objects.

HA: Can you define object?

KB: Object is anything with a value.

HA: So operators are not allowed?

KB: No, operators are not objects.

HA: So, you are saying that no new types will be introduced.

KB: Yes, only types of native language are allowed.

PB: Does that mean, in this definition, a SV test-bench. If I introduce Analog assertion in there, as long I use objects of the host language.

KB: Probably, yes.

PB: Operators, etc are derived from the host language. So, something like @cross can't be accessed in SV test bench.

KB: Yes, you can't refer to them in SV, so you can't refer to them. But in future, we could refer to them.

HA: If I am in Verilog-AMS can I use @cross in there?

SC: That was my next question.

KB: Yes, in VAMS you can but not in SV. But, does that over-constrain ourselves?

PB: You are prohibiting access functions in System Verilog.

KB: Yes, there are no such things as access functions in SV.

SL: How is it possible to pass voltages, etc to SV module?

KB: Detect the @cross in Verilog-AMS and then pass asynchronous boolean signal to digital.

SL: I want to think about this a little bit.

KB: Everyone needs to think hard about this, as I am proposing some very strong points. Either you accept them or you reject them.

HA: Lets discuss that in the next meeting.

-- AnandHimyanshu - 03 Mar 2009