• 111111111 Himyanshu Anand
• 011111111 Kenneth Bakalar
• 111110101 Prabal Bhattacharya
• 011110111 Eduard Cerny
• 111011100 Scott Cranston
• 110111011 Mike Demler
• 000000000 Surrendra Dudani
• 111000000 John Havlicek
• 111000110 Kevin Jones (RGG Leader)
• 111111011 Scott Little
• 101000000 David Sharrit
• 000000011 Jim Lear
• 000000010 Murtaza

Decisions:

1. None

Action Items:

1. Himyanshu to post the document by Jim Lear after it is cleared by Sri Chandra. The document does not have any copyright material and has not been patented by Jim or his company. [Himyanshu Anand]
2. Examples and use cases [All]

Details:

KB: Concerned about frequency domain properties like jitter measurement. Concerned about measurements that need to happen over a time interval. Some of these things can be continuously calculated (ex: a rolling average). My customers ask for these things first and these things need to be a part of the language. It is not completely clear to me if they are a separate class of items.

JL: These are similar to the measurement statements. I don't think that these use discrete time sampling.

HA: Jim shared his document but it had copyright. He has since provided a non-copyright document. I will run it through Sri again and then share it with the committee.

KB: What is the content?

JL: Its about what I shared with everyone last time and object oriented transactions. A lot of measurements we take depends on the specific stimulus we apply - like linearity, or a corner frequency.

KB: Its definitely an interesting subject but a difficult one. We have a tool which allows you to run directed tests, one after the another.

JL: When we say the linearity test, in a directed enviornment, we are not playing with the channels. We can integrate this with the OVM enviornment. We run these tests at full transistor level. The temporal aspects of what I have provided is very crude at this point and would like your feedback. Can this be translated to the lab tests? In a directed test case, this does not map well to the lab equipment so that these transactions can be issued in time.

JL: Each a command to check the rise time at the output of the DUT.

KB: The functions which describe the lab equipment should be a very high level component of verification enviornment. These things strike me that these are derived from the level of assertions we are talking about, and other transactions based, sequence based.

JL: Our verification does not end with the Silicon. In digital there is limited usefulness in carrying the simulation. In analog the coverage is not anywhere you would like it to be.

KB: Analog verificaiton assertions should move into the lab and this is going to be expensive.

JL: Yes, this is expensive but we can do a lot more because of the speed we get.There is a great deal of effort to get the lab up and runnig when a new architecture comes. A lot of time to debug, especially when there are parasitics.

HA: Is it not similar to emulation/FPGA for digital designs. You want to synthesize your analog assertions to work with your lab.

JL: Yes, that is exactly what we would like.

KB: Why are there not any lab equipment providers on this call.

JL: I have been talking to NI and Agilient and see if they will be interested.

SL: This is certainly an interesting idea and can provide higher level visibility to analog designers at SoC level.

JL: I have a couple of analog engineers who have taken this up and basically can lead to just drag and drop.

KB: Those are higher level models and they are not at the level we are talking about.

JL: What do you need at the low level in order to build this at the high level. That will help us where we want to go at the low level.

KB: I have been thinking about mostly time domain and the inter-relationships. This will open the scope discussion again.

JL: The translation between the lab and the simulation is a universal need. But I think there is a good demand out there.

MD: The idea is definitely a good one but you are talking about two totally different worlds. I worked on something similar 20 years back.

KB: We can extend digital clock to analog clock as it has 64 bits of extension. But that's an implementation issue rather than a language issue.

HA: Lets move on till Jim's document is online and everyone has taken a look at it. Scott has posted some user examples on the Twiki.

SL: This is from our AMS user community and business groups and has been sanitized but still reflect the intent. I will be going through the examples on Twiki under use case examples.

KB: What is stable?

SL: Depending upon what 'a' is, it stays within a bounded region for 90% of the time. The second example is detecting a threshold crossing but it just blips below then it does not detect the crossing.

KB: Can this glitch be a primitive?

SL: It could be. In this example, value of 'a' is instantenous rather than a time average.

PB: Whenever you are talking about the voltage expressions these are all reads, so they have no bearing on the simulation, as these are read operations. Do they have a bearing on simulation synchronization.

KB: I would say that they do have a bearing and that would depend on how close the timing is.

PB: Is that the intent then Scott.

SL: The simulator should adjust the precision based upon the assertions/threshold crossings. The important thing is the accuracy of the threshold crossing.

KB: What does consecutive mean in the example?

SL: To me consecutive is two measurements one after the another.

KB: That is period not frequency.

SL: The property might need to be rewritten, the concern is about slewing of the frequency.

JL: If you just measure the period that the period is within a specific boundary.

-- AnandHimyanshu - 31 Mar 2009