Attendees:
  • 111111111111111 Himyanshu Anand
  • 011111111001111 Kenneth Bakalar
  • 111110101011011 Prabal Bhattacharya
  • 000000000000001 Sri Chandra
  • 011110111111111 Eduard Cerny
  • 111011100001011 Scott Cranston
  • 000000000000110 Dejan Nickovic
  • 110111011110010 Mike Demler
  • 000000000000000 Surrendra Dudani
  • 111000000011111 John Havlicek
  • 111000110010000 Kevin Jones (RGG Leader)
  • 000000011111111 Jim Lear
  • 000000000000111 Top Lertpanyavit
  • 111111011011111 Scott Little
  • 000000000000010 Erik Seligman
  • 101000000000000 David Sharrit
  • 000000010000000 Murtaza

Decisions:


  1. None

Action Items:


  1. None

Details:


HA: Lets continue with Scott's bind proposal and take it to completion.

KB: You are proposing a mix of V-AMS and SV grammar in actuals. What piece of analog expressions are you going to extend this with.

SL: It will contain all the expressions that you find in the analog blocks, like V(a), I(a), event expressions.

KB: Are you proposing a unification of SV and V-AMS expression grammar?

JH: That depends on how you implement that grammar.

KB: So, only a subset of expressions will be allowed in ports.

JH: There are going to be rules that will enforce conditions and rules of port connections. So we will follow that.

KB: My initial reaction is you are proposing a slew of special cases. Can you allow hierarchical expressions in actuals?

SL: Yes.

Sri: In this proposal we are not merging SV and VAMS?

SL: Yes.

JH: The SV expressions has to be a heirarchical reference, not a compound expression.

KB: So you will disallow bit selects referenced hierarchically?

Sri: A variable port which is declared on SV module. If you are referencing a whole variable it is just an identifier.

SL: We would just allow identifiers and you would take a slice in SV.

JH: What port actuals have to be resolved using the scope rule in instantiation.

KB: It depends on how the reference is resolved. What happens if the expression includes references to both SV and VAMS expressions.

HA: You would have to merge the expressions anyway with SV and VAMS.

Sri: But at this point we would like to avoid that issue for the extension of assertions.

SL: Yes, we are hoping to avoid that.

JL: Why would you want to have a out of scope reference in VAMS instantiation?

SL: Its is cleaner way to do so.

KB: So, the train of thought is to base it on SV bind construct.

HA: It also allows you to reuse the assertions without changing the internals of the assertions by just changing the actuals.

KB: I understand the motivation, but this change needs a higher level of integration that we should be attempting here. Can the formals be of any type?

SL: The formals can be any type that are assignment compatible with SV.

JL: Instead of VAMS having hooks into SV, could you have two layer of instantiation, something like Scott's instantiation and inside it next layer would have hierarchical references to SV and inside that would be the real assertion module.

SL: That is certainly a possibility but would like avoid the wrapper.

JH: What would be the types of the actuals on ports on wrapper.

HA: That would allow just the VAMS types on the actuals on the top layer without the hierarchical references. The middle layer will reference the hierarchical SV types in actuals. The final assertion module will be instantiated inside the middle layer.

KB: My objection still stands, so now you cannot reuse the wrapper.

JL: Correct, the wrapper will be a custom for each instantiation but the actual assertion module will not change.

KB: So, that is exactly Scott was trying to avoid from the initial discussion.

Sri: What are the issues here? Is it just that we cannot access hierarchical refernces? So, when we are parsing this is there a way to know the scope of the reference being SV or VAMS?

SL: We have envisioned that on the command line the names of the SV modules would be passed.

KB: The information the hierarchical reference is in a foreign language (SV) will be available at elaboration time so there is no need to specify that on command line. My fear is that we have to extend the grammar (not merge) but that is going to be complicated.

SL: We don't want to merge the grammars.

Sri: But there will be some extension to VAMS grammar to handle this extension. And the question is it hard to keep it restricted.

KB: That's an exercise that needs to be done.

Sri: Certain extensions are required like events and variables.

KB: There are certain extensions that are needed to make the interface robust.

PB: One concern I have is that (on pg 4) for implementing here what we are talking about, we will be relying on real variable. The var real has very limited capabilities as it is defined in SV. Should we take this opportunity to extend SV to introduce something like wreal instead of real var. Because, wreal is more versatile than var real.

JL: I think wreal are a disaster but that's just my opinion. Maybe var reals have some problems but that is something you might have to live with.

KB: What limitations are you talking about.

JL: Current summation or voltage multiplexing (from analog modeling) we had to develop our own models. wreals have caused us nothing but headaches. For frequency analysis, complex numbers are used.

KB: Does Cadence plan to donate the wreal capability to VAMS?

PB: Yes, we plan on doing it. So, we would be running into wreal issue sooner or later. It will be a very good opportunity to get what is needed/required for wreals for the two committees to work together.

KB: The issue with Cadence wreal is that there is no global resolution but a single resolution.

SL: Is that something we want to propose to the larger committee look at to aid assertions

-- AnandHimyanshu - 27 May 2009

Topic revision: r1 - 2009-05-27 - 16:33:45 - 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