• 00000000000000010 Qamar Alam
• 11111111111111111 Himyanshu Anand
• 01111111100111111 Kenneth Bakalar
• 11111010101101101 Prabal Bhattacharya
• 00000000000000110 Sri Chandra
• 01111011111111111 Eduard Cerny
• 11101110000101101 Scott Cranston
• 00000000000000010 Dave Cronauer
• 00000000000011000 Dejan Nickovic
• 11011101111001000 Mike Demler
• 00000000000000000 Surrendra Dudani
• 11100000001111111 John Havlicek
• 11100011001000000 Kevin Jones (RGG Leader)
• 00000001111111111 Jim Lear
• 00000000000011101 Top Lertpanyavit
• 11111101101111111 Scott Little
• 00000000000001000 Erik Seligman
• 10100000000000000 David Sharrit
• 00000001000000000 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: Discussion about time.

HA: Do you have any updates from the action item from the last meeting.

KB: No, I have failed to keep my promise. The idea would be to use array of packed types and automatically include packed structure (integral types).

HA: So, can we get that document in the next meeting.

KB: Yes.

JH: Did you think about the function call as a SV funciton.

KB: My immediate reaction is functions are a whole lot of mess.

JH: I had in mind a garden variety of function of integral types of functions.

KB: Here we are having references to SV types in SV functions.

JH: But how much about them need to be understood.

KB: Generated verilog code needs to understand those types and marshall the data.

JH: I don't know who has to worry about that.

KB: I don't think its different from the earlier problem. If you can access reference objects and variables which are not in System Verilog or Verilog-AMS.

SL: Were you asking for the arguments to the function call which are of non-integral types.

JH: No, my initial thought was to have them as packed structures which are integral types. So, you would not need any elaborate types, those types are already in the SV-VAMS shared type space. Some of the rules of assignment compatibility without casts.

KB: SV has two type models. One is strongly typed, and another is implicit loosely typed.

JH: I am trying to find a compromise here, which does not require knowledge of strongly typed.

KB: This, is importing SV leaks. How much is SV going to end up in VAMS for our limited purpose.

JH: We can find some user friendly mechanism for integral types and they are still feasible from your concern.

PB: Having a var real the only way of communicating between SV and VAMS is going to be severely limited. I proposed that we add something like wreal to SV. This is a very simple but contrived example, each having a wreal port and trying to assign different values. In the current SV this is not allowed.

KB: What is the general case of this special case.

PB: This is not a special case. The problem is that multiple drivers are not allowed. So, this would be a good opportunity to get those extensions into wreals and into SV.

KB: So, the proposal is to extend SV with wreal not from VAMS but a better wreal than VAMS in SV.

PB: I don't have an opinion on that. Resolutions apart today you can't even have wreals.

KB: You can specify your resolution.

PB: There are ways around it but there is a severly limiting.

KB: So, SV has no way to specify resolution. Any fixed subset that we choose for resolution is going to be broken and cause our customers to be upset.

PB: So, should we think about resolution like VHDL?

KB: According to SV expert we would not be able to get through the P1800 with a resolution. They tried to find a solution to P1800 but found it to be too complex.

JL: If you are a schematic driven flow, wreal allows you to connect modules and you can do summation, etc.

JH: Where is the resolution defined in this example.

PB: There is not. And this example is a non-working example. And if this is a resolved wire, how does that happen.

KB: It will need to be a wreal net type rather than a wreal var type.

JH: I am worried how wild is the resolution function and what are its mathematical effects.

KB: In the present form from Cadence, there is a fixed subset of resolution functions.

PB: In the checker you are reading the value, so what value do you read.

JL: That is the limitation of the wreal that it is not defined in the language and you are at the mercy of the switch.

JH: Why can't the resolution function be defined by the user.

KB: It is not defined in SV.

PB: It is very hard.

JH: I think if something is useful then we should push for it and bring the technical points in front.

SL: Saying you wanted SV in VAMS but going down the road they will be integrated.

KB: The generalization that is appropriate in SV is not just a real wire but a wire of an arbitrary type. And that was the project that was postponed by SV committee.

JL: Is there not a real net port.

SL: No, there is a real var port.

KB: First thing is to make the "fantasy wreal" work properly in VAMS "wreal", before taking it to SV.

PB: What we are presenting here because we presenting a situation which needs something like wreal port/net in SV. And the solution is to investigate whether this already exists in SV, if not then does it make sense to introduce such a capability.

JL: Why do you need wreal?

PB: How will you pass values from VAMS to SV for ASVA?

JL: That was Scott's proposal with the bind proposal.

KB: This example does not justify the introduction of wreal, since there is a workaround using "if" statement to drive the real port. So, maybe we need to be modest here.

PB: One issue is resolution and the var real not able to handle wreal. If top was VAMS, then the question of resolution still remains. This is a contrived example from one of our users.

JH: What seems to be desired is some check on the functional combination of a1 and a2 and what is done today is that the relationship is made explicit.

SL: And my experience is also that I tend to make it explicit.

JH: If it is not explicit then that leads to trouble. Think about the debug flow when the assertions fails. There can be many possible cases. And if it is not in the debug flow then it makes it harder to debug.

JL: But it will be in the debug flow.

SL: This is contrived, but when I write things it looks like these. But, my argument is that as an assertion writer I would do the resolution explicitly.

JL: When you are dealing with wreals in VAMS this is useful in schematics.

HA: This will be useful if the netlist is dumped directly from schematic and the user does not have to do any manual editing before he can write the assertion on the combined net.

-- AnandHimyanshu - 11 Jun 2009