• 111111111111 Himyanshu Anand
• 011111111001 Kenneth Bakalar
• 111110101011 Prabal Bhattacharya
• 011110111111 Eduard Cerny
• 111011100001 Scott Cranston
• 110111011110 Mike Demler
• 000000000000 Surrendra Dudani
• 111000000011 John Havlicek
• 111000110010 Kevin Jones (RGG Leader)
• 000000011111 Jim Lear
• 111111011011 Scott Little
• 101000000000 David Sharrit
• 000000010000 Murtaza

Decisions:

1. None

Action Items:

1. None

Details:

??: Why are the VAMS access functions restricted to just to bind statement? Why are these not generally allowed elsewhere in SV?

SL: To restrict without dealing with the full SV-VAMS integration. A lot of this also came from the requirements Ken has posted, that it would be a while before SV-VAMS were combined together.

ED: In the module 'bar', all the ports must be an input. Is it an error then if you have some output ports. If this is only restricted to input why not use a checker module which is already in SV. Then the ports are in the current state of the standard. (Checker)

JH: That could be reasonable, ED. I don't see a problem with that.

ED: The ports on the checker are much more flexible than the ports on module. Like you can pass sequences, properties.

KB: But, those are not there in VAMS, so why should we pass that to SV.

ED: So, what you are saying is that I cannot pass a sequence because there is no sequence in VAMS.

JH: Bind can be used more flexibly, it can have hierarchical references.

KB: It is 100% equivalent to instantiating in another module. Thinking like an instantiating will simplify the things.

SL: Top is assumed to be SV, and the SV ports are considered to be real.

ED: Maybe Top is an analog module. So, the questions is are they known in SV world or are they known only in VAMS world.

KB: Right now they are only known in VAMS world.

ED: So, we cannot access them if they are not known in SV world.

JH: We are not claiming that these bind that are shown are legal in SV. They represent the vision of how the VAMS references can be accessed from SV. The rules of how to access something from VAMS needs to be generalized.

ED: Why do we need to then bind, I can say V(foo.x) in SV directly.

JH: Finally, there will not be a need. This is an intermediate step to go there

KB: V(foo.x) are then defined in the context of actual SV. The restriction on specifying them only in bind is no different then using it directly in SV. That restriction is not going to help in the implementation really.

JH: Some syntax like this bind can serve the connection between SV and VAMS.

KB: So the interface will have real and events as formal ports.

JH: Yes, but we are not thinking of excluding the other SV syntax in the target module where the bind module is instantiated.

KB: Ok, I see the motivation.

JH: The other displeasing thing about this is that you can create an event variable that captures the @cross and then you reference that event variable is accessed in the bind statement.

KB: Lets take a simpler example. Top was a VAMS module, then you would instantiate bar at the end of VAMS module. Then you could instantiate a SV checker module in VAMS.

SL: What about other complex SV constructs that we want to use in assertions.

KB: The simplified proposal should be able to access those constructs though function calls or other mechanism from inside the checker with the only restriction being on the type of ports.

JH: I don't think I am happy with the trade off between this restriction all the time Vs the restriction when I use the bind. Your model of instantiating in VAMS the SV checker module is going to be good for certain kinds of assertions. But think about the trade offs.

KB: You want to bind always at the top, and use hierarchical references.

JH: The idea is to use bind where most of the

KB: Too much damage to bind if we follow your proposal. @cross, V(x) needs to be defined in SV.

JL: The question is do we instantiate these in VAMS or in SV. So, there are two opposing camps and both of them have to query values from other domains.

KB: I am not advocating anything at this point.

JL: It is an alternative.

PB: The actual V(x) will be evaluated by analog. So, is it possible to come up with a way to just access the final value. What is the role of module bar?

KB: bar is being instantiated in SV and contains assertions. My concern about the generalization is tempting because it is flexible. But it amounts to changing a large amount of System Verilog. Its sort a a union between SV and VAMS, except we are removing analog statements, so you cannot write any equations.

JH: It might be worth noting that you can take the perspective of binding to an AMS target, where these expressions binding to the actuals make more sense. There were some initial thoughts which had syntactic cues that now you are moving to analog domain and the references will have to be resolved in the analog domain.

HA: The expression will be evaluated by VAMS/analog simulator.

KB: So how is V(x) resolved?

ED: Can we rewrite foo.V(x) instead of V(foo.x)? Because, that would be resolve the problem that V is not defined in SV.

KB: But the problem is that V is still not defined.

ED: No, V(x) is defined in foo scope. The only problem is the argument x, but I guess that would also be have to resolved using the scope of foo.

KB: So, if x is not defined in foo?

ED: Then if x is not defined in foo, it should be an error.

SL: One option is foo.cross(V(x) - 2.5,+1) where everything following foo in interpreted in the Verilog-AMS module.

JL: You could also do something like foo.cross(V(foo.x) - 2.5,+1) which provides a reference to each module.

KB: If we go this route then it makes sense to allow this for general instantiation. Creating too many exceptions can really explored the complexity. The other issues is that we need to satisfy the SV experts with a proposal of this nature.

JH: Ken's simple hypothesis might be a nice way to go if we allow hierarchical references to SV types. The challenge is to make sure that the processor knows the difference between the SV types and the VAMS types. I am not suggesting additional SV types.

KB: So we are extending VAMS to instantiate a checker that may have types it doesn't understand.

JL: There are two options. VAMS has to understand SV types or SV has to understand VAMS expressions. Doing it in VAMS you could do it w/ restrictions on the port types. In either case you have to bring one language into the other.

KB: I think that restricting to the VAMS type isn't that bad.

JH: I can see the restriction. You could assemble the types in the SV assertions code.

JL: How does that tie in w/ OVM and VMM? That seems to be the biggest restriction.

KB: You use bind to insert assertions into golden code.

JH: You might use bind to connect VIP with different parameters to different instances in the design hierarchy.

-- AnandHimyanshu - 27 Apr 2009