• 0000000000000001000010111 Qamar Alam
  • 1111111111111111111010111 Himyanshu Anand
  • 0111111110011111101110100 Kenneth Bakalar
  • 1111101010110110111011000 Prabal Bhattacharya
  • 0000000000000011000010100 Sri Chandra
  • 0111101111111111110110101 Eduard Cerny
  • 1110111000010110101110111 Scott Cranston
  • 0000000000000001000000000 Dave Cronauer
  • 0000000000001100000000011 Dejan Nickovic
  • 1101110111100100000000000 Mike Demler
  • 0000000000000000000000000 Surrendra Dudani
  • 1110000000111111111111001 John Havlicek
  • 1110001100100000000000000 Kevin Jones (RGG Leader)
  • 0000000111111111101110111 Jim Lear
  • 0000000000001110111000000 Top Lertpanyavit
  • 1111110110111111111111111 Scott Little
  • 0000000000000100000000000 Erik Seligman
  • 1010000000000000000000000 David Sharrit
  • 0000000100000000000000000 Murtaza
  • 0000000100000000000101100 Martin O'Leary


  1. Separate the accuracy information from the assertion language. The accuracy control should be outside - either static or dynamic. The method to control the accuracy is to be discussed later.

Action Items:

  1. Research multiple clocked assertion evaluation. [John Havlicek, Scott Cranston]


SL: Synchronization Vs Interpolation discussion.

JL: For safe operating area assertions you would need to detect crossings. For this you would need crossings and SV puts out the crossing threshold dynamically. This type might be missed based on the four data types that I have discussed.

DN: The document (Assertion Based Control of Simulation) is a continuation of the Jim's discussion. This document states why you would want the simulation control separate from the assertion. So that the assertion just observes the signals but then there are directives in another layer, which gives information to the simulator how to generate the data.

DN: Another way is to say the simulator should be predicate-aware. So, only the predicate (V(a) <= 1.8), then if you have this kind of synchronization then we can enforce the simulator to do finer sampling around the crossing of 1.8 volt.

HA: Is that not similar to @cross.

DN: Yes, but that is not being done explicitly here, that information is being analyzed implicitly. So, your objection was that these types of directives are static.

DN: So, that leads to 3rd evalauation structure - Full assertion aware directive. If you know the right hand side of the predicate is not active, then you do not do the accurate sampling.

HA: So the analog simulator is interacting with the assertion evaluator?

DN: Yes, this is a high level point on assertion language and how the data generated out of simulator. Don't know how this would be implemented.

DN: For discrete assertions also there are efficient algorithms for doing just what is required.

SC: Is figure (c) predicate aware?

DN: Yes, the predicate is V(a) < 1.8 volts.

SC: So, in figure (d) the accurate sampling is not disabled after 5.3 ns

DN: Yes, my example does not reflect that.

SC: Don't you want the predicate to be rise(b), that will define when you want to accurately sample accurately.

DN: Yes.

SC: What does figure (c) do that figure (d) cannot do?

DN: It is going step by step.

JL: For me it looks like this is an implementation issue.

DN: Yes, this is an implementation issue. What I am trying to show here is that how you can do accurate sampling without directly putting them in the assertions. I think, ideally assertions should remain general enough, and not reflect how they are generated.

DN: If you turn off or on the accuracy level the assertions results will be different. This is normal since, the two waveforms are not same. The closer the wavaeform is to the ideal waveform the higher the confidence in the results.

JL: In a certain sense this is kind of like the interfaces implemented in the System Verilog.

DN: The assertion just evaluates the data it recieves. But, the simulator needs to be aware of the assertion.

JL: That is a fairly sophisticated requirement and the assertion writer may have to do that manually through some package initially, as this looks like this is a research area to dynamically control the time points.

JL: What Dejan and I am are agreeing on is that we need a class to access the values of V(a), that will then control how the values are supplied to the assertion.

HA: I disagree, what Dejan has mentioned is that the accuracy control mechanism needs to be outside of the assertion. The value itself may directly come from the simulator without going through this external class.

JL: Fair enough, but if you have the class you can control the accuracy of the V(a) going into the assertion from the class by creating a buffer of the values that you might want to supply to the assertion.

HA: Why would you want to do that. The class cannot increase the accuracy if it is just buffering the values of the simulator for V(a). In that case, I would want to work the more accurate values that are available. The burden is to calculate the values and not to access those values. If the value is already calculated, then why would I not want to just access it directly and go through the class which may reduce the accuracy by not buffering some values.

JL: That is not correct, I can control the values of the buffer by forcing the time points from the analog simulator and increase/decrease the accuracy the buffered time points.

HA: Also, it seems that you are just moving the accuracy control mechanism from assertions to classes. Why not have them in assertions itself?

JH: I agree with Dejan that accuracy should be separate from the assertion language. That way it makes the IP reusable.

JL: That is my point too, by using the classes you can separate the two.

JH: However, I also agree with Himyanshu that writing classes, which might happen in the near to mid term is an ugly solution.

HA: To write these classes to control the accuracy is going to be error-prone, burdensome and maybe you are better off just using the accuracy level that is provided by the analog simulator directly. Ideally I would want the accuracy level to be determined automatically, if not then just use the values that are provided by the simulator.

DN: That is something which could be done too, where you have schemes that allow you to specify which accuracy level you want, just the simulator provided with no control, with automatic control, or something else.

JH: It might be worth thinking of what the digital evaluators do for multiply clocked assertions because they change dynamically.

SC: Can you write up something and share it with me and I can do some more research on what you are thinking.

HA: Ok, so we all agreed that the accuracy should be outside of the assertion language. However, how that accuracy will be achieved is still up for discussion.

-- AnandHimyanshu - 29 Jul 2009

Topic revision: r1 - 2009-07-29 - 15:25:07 - AnandHimyanshu
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback