• 0000000000000001 Qamar Alam
• 1111111111111111 Himyanshu Anand
• 0111111110011111 Kenneth Bakalar
• 1111101010110110 Prabal Bhattacharya
• 0000000000000011 Sri Chandra
• 0111101111111111 Eduard Cerny
• 1110111000010110 Scott Cranston
• 0000000000000001 Dave Cronauer
• 0000000000001100 Dejan Nickovic
• 1101110111100100 Mike Demler
• 0000000000000000 Surrendra Dudani
• 1110000000111111 John Havlicek
• 1110001100100000 Kevin Jones (RGG Leader)
• 0000000111111111 Jim Lear
• 0000000000001110 Top Lertpanyavit
• 1111110110111111 Scott Little
• 0000000000000100 Erik Seligman
• 1010000000000000 David Sharrit
• 0000000100000000 Murtaza

Decisions:

1. None

Action Items:

1. Ken Bakalar to provide description of how to connect to SystemVerilog integral types with his requirement that all actual expressions in port connections of VAMS-SV instances parse under Verilog-AMS.
2. Jim Lear to provide his requirements on dense time, detailing why plain reals are not enough for assertions.

Details:

HA: We would have liked to get through Prabal's example, but since he is not here we will do it later when he comes. John please go ahead with the requirements that you posted on Twiki under the language requirements of RGG document, section 9.

JH: The requirements extend upon Ken's requirements. These came about from our desire to access V-AMS quantities inside assertions.

JH: Second requirement: For now we do not want to worry about the generalities of inputs/outputs. We want to enable things that watch.

JH: Third requirement: How can we allow both SV and VAMS connections?

ED: If the instances inside VAMS, how will they access SV expressions, will it involve hierarchical references?

JH: Yes, that is the most probable mechanism.

JH: 3.2 - is for events.

ED: That is only for checkers?

JH: Are they not allowed in modules?

ED: I think so.

JH: If they are not allowed then that will be a fact.

JH: 3.3 - Many of the non-analog, non-real types most of them fall in the SV integral types. the flavors of integers, vectors of bits.

JH: 3.4 - I don't understand wreal, but I did not want to exclude it, so there might be some negotitation on this. In large majority of the cases, it might be plain reals that we will care about.

JL: What is an integral type?

JH: They are defined in SV LRM and are integers, bits, bit vectors, and structs, etc.

Sri: What about constant parameter types?

JH: I don't know about but they should probably resolve to integral types.

Sri: Because V-AMS does not have integral types.

JH: So, they need to be defined by SV.

JH: 4 - Resolution of names in the expression, that is typically going to occur at elaboration. So, there is going to be upwards and hierarchical resolution of VAMS names and SV names. It is not our intent at this point to have any mixed expressions that will come from VAMS and SV elaboration models. I am not saying anything to what happens if some expression resolves to both VAMS and SV.

HA: Are we assigning a priority on expressions to be resolved in a particular language if it resolves to both VAMS and SV type?

JH: We have not specified this, but this could be lived with.

Sri: Is there a hierarchy which is shared by both?

JH: No, there could be a combined heierarchy for name resolution. If there are names which causes ambiguity then it should be illegal.

Sri: Are these paths required to be full path?

JH: No, I would like this to be from SV, and there it does not need to be a full path.

ED: If the SV needs to be accessed from inside VAMS, it would need to be a full path.

JH: 4.2-4.3: Some tool specific requirements. The idea here is that we are not trying to support the mixing of entities from two languages. We do not want tools to start mixing how they resolve the references.

HA: This places a restriction on what can be accessed from a SV module inside VAMS. It cannot access another SV which is inside another VAMS module as it will cross language boundaries for name resolution.

JL: Is this not already enabled when you access SV inside VAMS.

JH: The fundamental connection is VAMS expression to SV. Yes maybe it has been crossed, but this restriction might help the implementations.

JL: I don't think reals, and wreals are sufficient for assertions. We need some other types which is more compatible with the dense time.

HA: Why would you say that?

JL: You do not want to export a lot of your functionality to your assertions. If you want to access the differential and integrals you want access to values at that time and not at the last simulation point.

JH: That may be the case.

JL: We need the ability to deal with electricals.

KB: Do you mean access functions?

HA: Can we get the requirements on this capability that you are refering to in a written document on Twiki and then we can discuss that point by point.

ED: The cross reference has to be within a SV.

JL: 4.2 and 4.3 have to be in entirely within SV or VAMS. I don't think that placing such a requirement on the tools is a good idea.

HA: This is something which is more of a guidance rather than a requirement. It can be dropped if the tools can support mixed hierarchical reference paths.

KB: The process of following a path name that is in a region in another language is a lot simpler than accessing an object in another language.

KB: So from the requirement that expressions should be purely in one language, I can not concatenate two bits, one from VAMS and one from SV?

JH: Yes, that is correct.

KB: The path names need to traverse the hierarchy of both languages and I know my customers are pissed about that. The phrase says "It may ..." This is not optional. But the hard part is the ability to reference an expression in a foreign language.

KB: Rule 3 is too loose and the rule that only allows only references is too severe.

HA: Why is that, expressions are allowed by the grammar today and when the actuals are evaluated then the final result is either a value or a reference.

KB: We could allow shared objects which parses in both SV and VAMS. Then you could have an expression which references a real from VAMS and another real from SV.

JH: Suppose the ports are of struct type.

KB: I am disallowing that.

JH: I am unwilling to give up that. Think of it as assignment compatible.

KB: Are you allowing packed and unpacked structs?

JH: Probably both.

KB: Unpacked structs are not integral types.

JH: Ok then packed structs only.

KB: The expressions from foreign language have to be parsed as V-AMS. If you allow arbitrary SV expressions, then they cannot be parsed and resolution of names cannot take place.

HA: Ok, how does the VAMS currently interface between the digital and analog boundaries? It knows about the interface and inserts connect modules at the interface. So, why can't it do similar interface like separation for the expressions.

Sri: The connect modules are part of the VAMS and the interface is also part of the V-AMS grammar/language. So, it is all parsed together and the connect modules are inserted later on when the nets are analyzed.

JH: Ken, can we have a proposal from you showing us how to connect and access values across the instantiation?

KB: Yes, I will work something up and share it.

-- AnandHimyanshu - 28 May 2009