• 1111111111 Himyanshu Anand
• 0111111110 Kenneth Bakalar
• 1111101010 Prabal Bhattacharya
• 0111101111 Eduard Cerny
• 1110111000 Scott Cranston
• 1101110111 Mike Demler
• 0000000000 Surrendra Dudani
• 1110000000 John Havlicek
• 1110001100 Kevin Jones (RGG Leader)
• 0000000111 Jim Lear
• 1111110110 Scott Little
• 1010000000 David Sharrit
• 0000000100 Murtaza

Decisions:

1. None

Action Items:

1. None

Details:

HA: Please go ahead and outline your thoughts on the presentation that you sent us.

JL: The coverage for AMS chips is far from sufficient. A transaction that goes over from the simulation to the lab environment and maybe even testers.

HA: The test benches and assertions are not fighting for the same space, they belong to different domains of solutions and are probably complimentary.

JL: Yes, you are right in that sense. They probably do lie in two different phases.

ED: These are two different animals, OVM, monitors and test-benches and SVA are complimentary. There is no question of displacing each other.

JL: I don't disagree with that but my concerns are whether we are going to define semantics for assertions which cannot be translated to work with lab.

ED: You have an object oriented or OVM like style.

JL: I would like to know how we can compliment these two. As long as there is a capability to do this at a higher level, and the assertions do not displace higher level constructs, this should be fine. In the analog world we will have to take the assertions and convert them into lab.

ED: Why do you say they will not translate?

JL: I think they might not translate. The assertions are very sensitive to the lab and that is different from simulation environment.

ED: Why are the two different?

JL: Whatever we do we should keep in mind that this is something we should be able to replicate/reuse in post-silicon enviornment.

HA: Why can't I take the assertions and plug it with the lab equipment. The assertions are source agnostic, so as long as there is a trace, the assertion evaluator works. Whether the source of the data is coming from the simulator or from the lab equipment, it should work.

ED: Or you can take the assertions and convert them into RTL code and put them in an emulator.

JL: That could be possible.

HA: How do you do the translation right now? I would think that even now you would be doing some tweaking of the assertions to make it work with the lab.

JL: We have not made it to work fully with the lab right now. But, yes, we would need small tweaks to make it work.

ED: Once you have the assertions, nothing prevents you to put those in OVM or object oriented testbenches. The assertions will be sitting on the interface between the digital/analog. Then if the assertions use some constructs, then your objec oriented testbench can also see those.

JL: The semantics of the assertions should be consistent with the semantics of the lab. Like the trigger the transaction.

HA: The assertions need events to trigger and then the ones that we are talking about will have real time delays. There is nothing in those constructs that you will not be able to handle or generate data for the assertions that does not work with lab equipment. Have you looked at the examples that have been posted on Twiki and analyzed whether they have inherent problems that will prevent those from getting reused with lab?

JL: I did look at them couple of weeks back, I will again take a look. I have read the papers that have been mentioned on Twiki.

HA: I believe assertions can be used as building blocks of your transactions.

JL: Its possible, I will have to take a look at that and it may turn out that my concerns regarding the lab semantics is unfounded. However, I think that we might first look at the higher level constructs - transaction level, before going into language details. I would want transactions to be independent of the language, and if the assertions prevent me from doing transactions then that is not good.

-- AnandHimyanshu - 10 Apr 2009