• 000000000000000100 Qamar Alam
• 111111111111111111 Himyanshu Anand
• 011111111001111110 Kenneth Bakalar
• 111110101011011011 Prabal Bhattacharya
• 000000000000001100 Sri Chandra
• 011110111111111111 Eduard Cerny
• 111011100001011010 Scott Cranston
• 000000000000000100 Dave Cronauer
• 000000000000110000 Dejan Nickovic
• 110111011110010000 Mike Demler
• 000000000000000000 Surrendra Dudani
• 111000000011111111 John Havlicek
• 111000110010000000 Kevin Jones (RGG Leader)
• 000000011111111110 Jim Lear
• 000000000000111011 Top Lertpanyavit
• 111111011011111111 Scott Little
• 000000000000010000 Erik Seligman
• 101000000000000000 David Sharrit
• 000000010000000000 Murtaza

Decisions:

1. Not to push for event ports in SV, but rather live with explicit event variable defined in VAMS and referenced through references in SV modules or use event ports in SV checkers.
2. Request for "assignment concatenation" to be added to VAMS port. (To be refined/expanded later on before proposing to VAMS committee)
3. Move RGG meeting to 9:00 - 10:00 CST,Wednesday from next to next week (Week of June 22nd).

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.

Details:

HA: Lets move the weekly meeting to Wednesday from next to next week. Prabal do you want to continue your discussion on wreal.

PB: I don't think I have anything new to add to that. My intent was to avoid something that we would require in ASVA from getting excluded to it.

SL: What exactly would it entail that you would like to propose, related to resolution on nets?

PB: I wanted to get feedback for the need for a real valued net in SV. What would it mean to say there is a wreal net in SV. What kind of constructs do we need to support for wreal in SV. I am proposing talking to SV committee for adding something like wreal to the language.

PB: In the last meeting, someone suggested that the top level would not be SV but be VAMS.

SL: Yes, it depends on your design and verification model and how it interacts with the existing language constructs. Right now we are asking for what you have showed would not be allowed.

PB: Let the top level be VAMS and it instantiates two SV blocks. The checker input port is going to be var real, and it is in top level VAMS, then the input net can be declared as wreal. So, the question of resolution still stays.

HA: Is it not the case that wreal cannot have multiple drivers in current VAMS LRM.

PB: That may be the case, but the question will remain for resolution.

JH: It is not upto the checker to resolve the value its what the checker reads.

PB: For someone who has to choose it has only one choice to declare two wires and do a custom resolution oneself and then pass the resolved value. Does it create some useability issues? Is it the question that we need to address or not?

JH: I think we need to capture the convincing and motivating example. Right now we do not have it.

SL: After talking to Dave Miller, VAMS was created to complex models and now it is being used to write more abstract models. But, I would like to see some more compelling examples of this.

JH: Unless we really see a connection with ASVA that argument is going to be made in the Verilog AMS committee.

SL: The assertions that are being modeled are somewhat tied. And the recommendation may come from us that we need these enhancements to VAMS.

PB: It could be a valid request from us to model this in VAMS. Another question I have is that the top level could very well be SV. Then the wire 'w' cannot be declared wreal, in which case it will be var real. If that's the case then we go to the other problem, that var reals cannot have multiple driver.

SL: Yes, if we need multiple drivers then we will need some kind of real net.

Top: My biggest concern is the multiple drivers, that it needs to be resolved. So, you will be duplicating the resolution that is being done in mixed signal block. How, do you resolve of wreal which have different drive strengths. So, how do you do it. I would like to see more thoughts on how this resolution is done.

HA: Is there any problem in connecting wreal to var real port?

PB: There is not problem in connecting it today. The issue is in the area of multiple drivers.

SL: Maybe you are thinking about the events, there is a problem with that.

JH: If we restrict our focus to SV events or even Verilog events to a port that is not allowed and was pointed out by ED.

ED: The event would go as a var or a ref, it cannot simply go as an input.

SL: The net type can only be an integral type. But ED, pointed that SV does not allow continous assignment, so that disallows an event being assigned to a var port. So, that would only mean it is assigned to a ref port, but the checker do allow the event expressions.

JH: So, it seems that it is a pretty big blow to hook VAMS events to SV events.

SL: That would mean you would have to auxiliary event variable being triggered by a cross statement and is connected to a ref port of SV. But it could be hooked a checker.

JH: And checker is a good place. Right now may not be a good time to open that with SV committee.

SL: But, I would like to know the reason why is it disallowed in modules and allowed in checkers.

HA: Has it something to do with that the modules need to be synthesizeable?

JH: I don't think so.

PB: Is it something that we can live until we have the merged VAMS-SV?

JH: I think so, we have to create an event variable and pass a reference to the event in the port of the module or the checker.

HA: So, are we deciding that we will keep to checkers and references to events in module.

All: Yes.

HA: Ok so do we have anything else to discuss today?

JH: I was hoping that Ken would give us an example of how to hook up SV types with VAMS. I have my view of how it should work.

JH: One should certainly be able to write/assemble expressions which are bit vectors and that might be enough.

PB: It would be interesting to know while Ken is looking into this, how many of these types can be real data types? And does SV has any restrictions on it.

SL: real is not an integral data type so it would have to be passed as unpacked structure and not as a packed structure.

PB: Where are these data type coming from?

SL: My understanding is that they are coming from the SV inside the VAMS model from other SV block through references.

JH: We are going to have a mixed model, and there is going to be digital data. In SV, it is likely that there is going to be data of this type. I am trying to avoid to disassemble that data to just get the data into SV checker or SV module. I want to be able to use the same type inside the assertions. The resistance has come that the we are opening too much for the project if we allow that. That has to be understood as against how badly is that going to pinch the user.

JH: Can someone say what kind of concatenation expressions are supported in VAMS. In SV we have assignment compatible expressions in concatenation.

SL: My understanding is curly braces and comma separated concatenation.

JH: Does it use the tick and double brace?

SL: Let me double check.

JH: Another thing I had asked Ken in my email, whether there would be a problem in calling a SV function as an expression in this port connection. For me, it is common to see some helper functions which do create user created types, out of their more primitive expressions. We won't be able to write cast expressions, but maybe VAMS would understand some of the SV function returning SV type.

HA: Do you see any issues with it?

PB: Not sure.

JH: Suppose there is constructor function in the port. Then what I am asking is that can I put the constructor function in the port expression and whether it will cause any problems with the parsing?

PB: The process would need to know what is the type of the expression.

JH: ED, do you have an opinion?

ED: Will that be an automatic variable?

JH: Yes.

ED: So, that will be a problem, you cannot pass it to the checker.

JH: I am using constructor as some function not fully OO incantations.

ED: Ok, so I misunderstood. So, you have to somehow assemble it to form the actual argument.

JH: Exactly.

ED: So, the type of the function is the same as that of the struct.

JH: Yes, then what I am asking is it feasible to attach it the port.

ED: I don't why it should not be allowed. It is following the semantics. The body of the checker is expanded in the place of instantiation. So, if you do it in the VAMS I am not sure what it would do.

PB: Does this expression anywhere else except on the instantiation.

ED: That would appear where the instantiation is done.

JH: Ok, but that is the reference algorithm.

ED: Yes, it could be done differently.

JH: Ok, so my question is still open.

ED: In SV this is feasible, but if you move this to VAMS I don't know what will happen.

JH: It is possible that just living with the concatenation will be enough. It will be slightly painful but it should be enough.

SL: The concatenation in VAMS is strictly curly braces. So, it seems that there might be a syntax collision.

JH: No, that is allowed in SV. So, it should be ok. And that might be a request to VAMS committee as to add "assignment concatenation". Himyanshu, did you get that.

HA: Yes, I will keep it as request to add "assignment concatenation" and expand upon it later.

HA: So, to summarize we decided not to push for event ports in SV modules but to use references to explicitly defined event variable in VAMS models in SV modules or use SV checkers. The other is the request above and third is to move the time of the RGG meeting to Wednesday.

-- AnandHimyanshu - 11 Jun 2009