• 1111 Himyanshu Anand
• 0111 Kenneth Bakalar
• 1111 Prabal Bhattacharya
• 0111 Eduard Cerny
• 1110 Scott Cranston
• 1101 Mike Demler
• 0000 Surrendra Dudani
• 1110 John Havlicek
• 1110 Kevin Jones (RGG Leader)
• 1111 Scott Little
• 1010 David Sharrit

Decisions:

• RGG will meet with the larger group meeting on Tuesday at 10:00 AM CST (8:00 AM PST, 12:00 PM EST) instead of the usual time.

Action Items:

• Mike Demler to refine the Scope of the document and include material that is already reflected on his blog but not here.
• Scott/Himyanshu to talk to John about the concerns with user-defined function calls from within assertions.

Details:

SL: It is on Twiki under the section Scope. Some assumptions are placed and are like use cases. Not too much thought into future requirements. Extend this as SVA, keep that syntax and since we are in Verilog-AMS committee we would like to leverage some constructs from them. Main use Mixed mode simulations.

KB: Time domain?

SL: I don't say that yes, mostly time domain. Mixed mode simulations are mixed mode time domain. Verification engineers will be primary users for FSL. In supporting AMS verification engineers.Tolerance, waveform properties and some from Mike's taxonomy.

SL: Nice to have some limited measurement like properties. Not the full capabilities, but some basic measurements. Some static electrical properties and basic frequency properties. If you are measureing gain, access the value of gain and compare it to which frequency.

SL: Low interest on connectivity properties and complex frequency domain properties like FFT.

MD: It is pretty good. Are we assuming that these assertions would be checked only simulation or are we allowing post-processing?

SL: I think ideally we would like it to be checked during simulation, but some of the properties can only be checked post processing.

KB: Some can be checked periodically.

EC: They can be checked at the end of the simulation.

KB: Another important matter is simultaneous of checker and simulator, to provide the resolution that is necessary. It controls the simulator time step to provide accuracy.

SL: You can use event (affects time step), if statement (does not affect time step)

KB: I would say that is bad modeling practise. The result of the signal may change during the iteration.

EC: What about event based?

KB: Inequality operators on analog signals are bad.

EC: What about something like digital assertions, using values from the end of last time step? If the events from analog come before the active region, they will be from the previous time step.

EC: If Verilog-AMS talks about Verilog event queue then it misses quite a bit from the System Verilog event queue.

SL: What about the performance of @cross statements in assertions?

KB: In Dejan's thesis, at the very end, they are concerned the boolean equality with time step. Tune up and down the accuracy.

PB: There is a cost associated with the @cross and the time step. In Analog-Digital simulation, the major part is analog.

PB: If you are evaluating the models, due to assertions it could lead to expensive checks.

KB: Relational checks are not expensive.

PB: How can you make such an assumption. If you calculate current, if current is not part of your store then you have to calculate it. The point you are interested may not be specified up-front.

KB: It will be specified up-front.

SL: The assertions will affect the time step of the simulator, in the similar way that @cross does today.

EC: How is tolerance taken into account in assertions?

KB: There is no absolute standard for these tolerances. They are relative.

HA: Ed is talking about how the time is handled in assertions in relation to tolerances.

EC: Yes. The question I have is the assertion's have tolerances and the model has tolerances, are they in anyway related?

SL: They may pick the tightest tolerance.

KB: There is no way you can say one is greater than the other. You can make them tighter and tighter.

MD: The assertion controlling the time accuracy and also the voltage accuracy.

KB: Voltage tolerance on the crossing is not the same thing as the tolerance on the convergence of the solution.

MD: What ED is saying is that you can't measure something which is more accurate then what is coming out of the simulator.

KB: How is measurement like properties different from Requirement 6.

SL: Instead of having the user to write the explicitly everytime something like $freq, it is already built-in.

KB: I would rather have the ability to build such functions rather than define them in the language.

SL: Will take an action item to talk to John to get his concerns regarding the ability to let users define functions.

KB: Digital dominated mixed signal. Kevin Cameron had a document on checker board verification. We also be able to do block level verification and system level verification and use the same assertions and the same language.

PB: Are we going to be able to access some device properties (Like through the colon, etc for accessing transistor level properties)

MD: Some of the things were mentioned in my taxonomy. Will change the scope Twiki.

PB: If the vds is greater than a particular value then do this.

MD: Yes, people do that stuff, the question is whether it belongs here or not?

KB: The ability to reference parameters. You cannot access them through Verilog-AMS.

MD: There are important properties in analog side which are represented in the waveform properties.

SL: Maybe that would be nice to have, but maybe they will end up in the next cut. For this first cut, we need to focus on things that will not involve a lot of language changes.

EC: I agree.

KB: Digital verificaiton is very different from analog verification. I cannot articulate that, but that is troubling me.

SL: The assertions language could be used as a communication tool between the analog designer and the verificaiton engineer. Something like documenting the intention.

KB: I agree.

PB: We are talking about SV as the vehicle, related to that is an existing use model like .measure in use with analog verification. You are talking about migration of assertions from block level to system level. Its not clear to me how to do that. Its possible we submit this as a future enhancement.

MD: We just allow any arbitrary analog property to be passed along. This is what I saw people dealing. And we just leave what those properties are.

KB: Are these properties or just parameters.

SL: PLI call and that returns a value.

MD: Yes, what that value represents could be different from simulator to simulator. And that property could be static or dynamic.

-- AnandHimyanshu - 19 Feb 2009