• 111 Himyanshu Anand
• 011 Kenneth Bakalar
• 111 Prabal Bhattacharya
• 011 Eduard Cerny
• 111 Scott Cranston
• 110 Mike Demler
• 000 Surrendra Dudani
• 111 John Havlicek
• 111 Kevin Jones (RGG Leader)
• 111 Scott Little
• 101 David Sharrit

Decisions:

• None

Action Items:

• FSL to define the scope and share it with group in next meeting [FSL]

Details:

PB: I will load the content sometime today.

KJ: Discuss Sec 5 a little bit that will help in other sections.

SL: I tried to explain where we are headed. Simulation based mixed signal verification. Not an eye on formal. Chang and Kundert paper is a good reference. There might be some disagreement on performance verification Vs functional verification. Performance verification might be more complicated and complex and may not be the area which we should focus on. Assertion constructs needed for all use cases, some of the use cases are not the primary focus, but maybe will help other use cases.

SL: Primary focus area - Three main use cases.

KJ: There are some assumptions. One is verification engineer, second is Chang-Kundert verification method, third is that we are not talking about spice circuits. This should be first explored?

KB: Is everybody using Chang-Kundert methodology?

KJ: No, not everyone is using that methodology. There might be groups which do not use this model. So, if this model is pursued it should be justified. They may not be interested in AMS languages. PB: There is actually small set of users who subscribe to Chang-Kundert models. There is a large community which is doing it the old way. Variety of methods, measurements and waveforms etc.

KJ: Disagree with only time-domain assertion language.

KB: What kind of language will be for frequency domain.

KJ: Assertions express property, and frequency properties can be expressed in the assertion language. Frequency domain is a secondary question. Later we might restrict the scope of language.

KB: Use model is where will I use these assertions, other than time domain.

KJ: Do we want to state what domain is this assertion language targeting?

PB: Why are we trying to make the distinction at this stage?

KJ: Fundamentally the properties are going to be time domain - that is a strong statement and defines the way language may be developed.

KB: That specifies the scope, in a clear and unambigous way.

SL: These talk about time domain, but earlier FSL has given frequency domain properties too.

PB: The checks that you are performing at each time step or each frequency. The checks themselves may not change. The quantity that you are checking is changing and when you are checking is also changing. But, if you define time domain based scope, then what parts of frequency domain parts fit into the scope. I don't think frequency domain properties should be taken out this early.

DS: Starting from a frequency domain simulation and totally ignoring the time domain. But, if we are focusing on AMS verification engineer, you are almost automatically limiting yourself to time domain simulation, but you can still talk about frequency attributes. We need to be clear on underlying frequency simulation or frequency attributes.

KB: When you move to frequency domain, the underlying free signal is frequency and not time, which is what current assertions have.

JH: I don't understand the fundamental sense of difference. Are you talking about the difference in regularity? or mathematical sense of notion?

KB: SVA's independent variable is time and not frequency. It seems it is a different universe. That probably requires a separate language and not a unified language.

DS: Verilog-AMS is also not fundamentally frequency domain.

PB: Don't agree with that, may be not strongly but it has frequency domain characteristics. But, when we come to SVA, things are different.

KB: This language should be a super set of SVA. and when SVA is purely digital and it should behave just as digital SVA does.

JH: Its a good goal to have the same semantics where the syntax is same. We have some questions on pre-poned conflicts. The synchronization between digital/analog engines is an interesting question.

KJ: Does everyone agree that those are the primary areas for use cases of assertions?

PB: Where is our constraint coming from? Is it to limit ourselves to SVA or to use cases?

KJ: I would think it is uses cases. We should define the use cases and then see whether SVA is a good vehicle.

PB: I agree with that.

KB: I don't agree with that, we have to limit ourselves from the beginning.

DS: I agree with Ken.

PB: If you came up with a different assertion language. Like Spectre has this measurement capability. If we are limiting ourselves to SVA or to use case scenarios then the challenges are different.

KB: Start with the scope.

KJ: Some would like to extend an existing solution, some would like to define the use cases. What is the best way to address these.

JH: I had hoped we would not throw out the frequency domain properties. But for progress I am ready to compromise by throwing frequency out. My intuition is we may be able to use some of the frequency properties using the same constructs.

KJ: Most of the properties are not in the time domain when I talk to the analog designers. Biggest open question is the what is the scope for which we are specifying the requirements. We would like to define a mechanism to define the scope. Can FSL define the scope, since they started this discussion?

HA: Sure, we had hoped there would be some kind of frequency domain properties. We will discuss internally and define the scope as we see it and share it with the group in the next meeting.

-- AnandHimyanshu - 13 Feb 2009