• 11111111111 Himyanshu Anand
  • 01111111100 Kenneth Bakalar
  • 11111010101 Prabal Bhattacharya
  • 01111011111 Eduard Cerny
  • 11101110000 Scott Cranston
  • 11011101111 Mike Demler
  • 00000000000 Surrendra Dudani
  • 11100000001 John Havlicek
  • 11100011001 Kevin Jones (RGG Leader)
  • 00000001111 Jim Lear
  • 11111101101 Scott Little
  • 10100000000 David Sharrit
  • 00000001000 Murtaza


  1. None

Action Items:

  1. None


HA: The bind proposal was sent out yesterday by Scott. Lets go through it.

SL: The SV-VAMS is away a little bit, so we decided to have this bind proposal to SV since the restriction of not being able to use any VAMS constructs in assertions is something we are not familiar.

HA: Can you give a brief introduction of what bind does for the benefit of those who may not have used it.

SL: The bind construct allows to connect/insert modules from different files into the scope of a module. This way, you do not have to modify the source files for inserting assertions.

SL: The new construct is the bind to VAMS functions - V(a), I(a), into SV assertion.

PB: So, the bind puts the module in SV scope.

SL: Yes. So, the new construct will mean, SV-AMS simulator will now have to recognize these new constructs and parse them.

PB: You are talking about the .analog event and overiding it. The one which talks about cross event.

SL: I am talking about signal access function right now, like the voltage or the current across the branch. The infrastructure is probably already there. The ability to have read access is already there.

JH: In VAMS, could you have rewritten, foo.V(X), instead of V(foo.X)?


PB: V and I are exposing VAMS functions to SV. People could ask more and more analog complex expressions in the argument. So, that SV is not going to care about and that it just passes it to VAMS.

SL: We had not considered that, but that is probably a good idea.

MD: I agree. Any calculation of the design will pass over.

SL: The intent of this was to provide access to assertion to a handful of analog properties. In VAMS there are other functions, so Prabal was saying maybe other functions like derivatives would also be exposed.

PB: Yes, so instead of opening those functions one by one, why not open them all at the same time.

KJ: If you allow that, then does that not mean all analog expressions would be exposed to SV.

JH: The idea was you have to have reciever or port on the SV side to bind the expressions. The only thing that needs to come over is what needs to be assigned.

PB: That is what is expressed here, through V_x, the real port gets value of the expression V(foo.X). The SV needs to understands what V(foo.X) is. And this could be a long list.

JH: I think we did have that discussion. We decided not to be so ambitious. So, instead of the cue (syntactically) we decided we will focus on the small subset.

PB: So, it could be any Verilog-AMS expressions, it will be evaluated by VAMS and passed to SV throught the bind.

JH: That will include extensions to bind, I don't know how the compounds are handled currently.

HA: Expressions which accumulate or stop time may be problematic in the port assignments. Expressions which are instantenous should be fine. So, for example, something like mean over a time range cannot be allowed in the port, however V(x) or an event is instantenous and will be allowed.

SL: I agree, accumulations will need to happen on the SV side. The ports will allow read only behavior.

PB: Is getting the value of V(x) a fetch mechanism?

HA: Yes.

PB: Is it the case that the analog simulator can decide when to evaluate or not evaluate at other times, as an optimization. Also, do all the changes to V(x) create analog events or not?

JH: That depends on how V(x) is used.

SL: Getting the information when V(x) is passed could be optimized.

MD: You can only strobe it at every digital clock. Analog is more finer than digital.

JH: In the explicit example, the assertion evaluator needs to be told when the analog event happens.

PB: If I write always@cross, then the digital is sensitive to that event. Its the @cross that digital is sensitive on. And the digital is not sensitive on V(foo.x). At the time the simulator has to determine, in which the digital is sensitive and in which case it is not and just uses fetch model.

KJ: What is the meaning of an analog event triggering at time, when there is no a-d tick.

PB: It is how it is done now. The digital will get the event at the closest digital tick.

HA: What if, we take V(x) > 2.5 and put that in the bind port. Will it be a pull or push.

PB: That will be a pull, because, the value is used whenever the SV asks for it.

JH: I would agree with that, since it is used only when SV requests it.

ED: I would agree with it too.

JH: However, we do not know what will happen if you bind V(x) > 2.5 to an event port. That may be not legal.

PB: Why did you decide to use the bind instead of the structural interface?

SL: We thought it would be least intrusive.

PB: It is like VUnit concept in PSL, but other than that isn't it the same thing as structural interface?

JH: I don't know, if its the same thing. It denotes a virtual instance.

SL: The bind does inherit all the structural interfaces. So, for the bind to work, we may need to enhance the other interfaces.

PB: Does VAMS 2.3 allows events to be put in the ports?

SL: I don't know about that.

PB: So, is this an intermediate step before we go to the full blown SV-VAMS?

SL: Yes.

PB: Can the real port take an VAMS event/timer?

HA: Should not, it should be illegal. That was what John mentioned earlier. So, non-event port should be allowed to have event/timer expressions. And similarly, non-event ports should not be allowed to get event/timer values.

PB: The event port and the real port on SV needs to be clear on what it can take. It will also have a bearing on the a-d interface. The bind is good, and is a much cleaner way to import values from VAMS into SV.

SL: Are there any concerns from the tools people as to what is there in the bind statement.

PB: No, I think this is fine, because it it either a a-d model, which is already there, or it is a pull model which is also there. I think we can allow general VAMS expressions as long as SV is just reading it and the evaluation is being done in the analog simulator.

HA: Any other comments from others?

ED: I am fine. I would have liked more direct access but in its absence this is fine too.

MD: I don't have any other comments.

-- AnandHimyanshu - 16 Apr 2009

Topic revision: r1 - 2009-04-16 - 15:22:51 - 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