2010-05-05
Attendees:

11111 Himyanshu Anand
11111 Kenneth Bakalar
00000 Prabal Bhattacharya
00010 Achim Bauer
10000 Sri Chandra
11101 Eduard Cerny
00011 Scott Cranston
00011 Dave Cronauer
01001 Dejan Nickovic
00000 Mike Demler
00000 Surrendra Dudani
11111 John Havlicek
00000 Kevin Jones
11111 Jim Lear
10110 Top Lertpanyavit
00010 Marq Kole
11111 Scott Little
00000 Martin O'Leary
00000 Erik Seligman
00000 David Sharrit

SUMMARY:

-Assertions subgroup has converged on the idea that restricting local variable assignments to clocked booleans is the right approach.

-Ken Bakalar began discussing his recent e-mail regarding the embedding problem. There seemed to be some convergence of thought regarding which names and objects would be allowed to be referenced in ASVAs. Ken agreed to more concisely state the ideas floated during the discussion.

-The assertions subcommittee and the embedding subcommittee will interleave meetings. The assertions subgroup will meet next on 05/12 and the embedding subgroup will meet next on 05/17.

ACTION ITEMS:

-Dejan will send his thesis to Scott so it can be posted to the web. [Done]

-Ken will come up with a summary of the convergence points around which names and objects will be allowed to be referenced in ASVAs.

-Jim will create a written explanation of his ideas for a higher level interface.

DETAILS:

JL: Dejan, Ken referenced your thesis in his e-mail Can we get a copy of your thesis?

DN: Sure. I will send a link.

SL: John, can you summarize the assertions subcommittee meeting?

JH: We have been thinking about local variables. We have been considering three policies where the second and third policies are essentially equivalent. In the last meeting we discussed some problematic examples. We are thinking that only allowing local variable on clocked booleans is the way to go.

DN: I have a question about local variables. In SVA they are defined over a finite domain. In the last meeting we discussed what can be on the RHS of a local variable expression. This can be an analog expression which moves the problem into the continuous domain. Is this your intention?

JH: Yes.

DN: I think this is a problem because you can end up with uncountably many copies.

JH: If we restrict to the first policy and assume that we don't have an accumulation point of events then I think we are okay.

DN: Okay, yes, I agree those restrictions would help.

JH: I think right now we should restrict to the conservative policy. If there is a need in the future we can investigate the issue further.

DN: I doubt it will be feasible even moving forward.

KB: I am concerned about what time these local variable samples are taken. The sample is being taken at the time the antecedent becomes true?

JH: We are talking about attaching them to a digital subsequence. They must occur at an event though. We went back through our examples to see how big of a problem this policy would be. Not all of our examples were coded in compliance with this restriction, but we determined that they could be easily recoded. Dejan, do any of your examples have local variables?

DN: No at this time. I think that local variables add expressive power. I would like to go back and recode the DDR slew rate property using local variables.

SL: Ken, can you lead us through your e-mail.

KB: The objects referred to in an ASVA context must be legal in that context. The possibility is that there might be hierarchical references that aren't legal in the embedding context.

EC: Didn't the requirements allow VAMS to reference an SV object?

KB: Yes, as long as the object is an object VAMS knows about.

EC: You mean the type?

KB: Type is a confusing word. I mean its kind and type.

SC: It seems to me that there is a confusion between the name and the object. Saying that the name and object must be legal are different concepts.

KB: Yes, the name doesn't have to be legal, but the object does. The name identifies and object. The object has a type. My claim is that legal objects must produce a set of values that the embedding context understands. If the embedding language is VAMS then the values need to be understandable in VAMS. We are all in agreement here?

JH: No, but go ahead.

KB: There may be instances where an SV object is being instantiated in VAMS.

JL: If you instantiate a SV checker in a VAMS module and that checker needs to connect to some other SV object and the reference to that object may not make sense in the VAMS context.

KB: Yes, I am suggesting that ought to be allowed now.

JL: I think about this from a SignalSpy perspective. Can't we just attach strings to reference those?

SC: You then need to define the string meanings.

KB: I am not sure people want to work around the existing port idea and syntax.

JL: If you are just doing heirarchical references why does it really matter? Ports don't have a ton of meaning in that context.

JH: I think people want ports to be able to look forward to a merged language.

JL: You can pass strings through a port.

JH: What problem is this solving?

JL: If the name and/or object would be illegal in VAMS this can work around those issues.

JH: I was thinking that the name must be something that is parsable by VAMS, but the type may not be parseable in the VAMS context.

KB: What about a hierarchical reference in the ASVA container?

JH: If this is written directly in VAMS then the name and type would have to both be legal in VAMS.

JL: I thought that we were only writing assertions in SV.

KB: No both.

JL: Maybe that is too much.

KB: Okay, tentatively let's say that the name must be parseable, but it can be of any type/kind that is assignment compatible within the SV port where it is compatible.

JL: I have proposed in the past that the connection from the analog world to SV be more like file streams.

JH: Do you have a vision for that in SV-AMS? Does your paradigm work there?

JL: Yes.

SL: Infrastructure there? Just write a file and read it?

JL: No. I want to think about VAMS as an peripheral device and just give it an interface.

KB: I think that interface is instantiation. That is why I want to reuse it.

JL: I am think that on the SV side you could create a dense real class and then connect an electrical directly to that. There would have to be some connection.

SL: How do you connect a dense real to an electrical?

JL: That is a bit absurd, but I think the idea for a high level interface is very powerful. If we have a high level interface then we can access objects using strings and following the file metaphors. Why can't we do that?

KB: There are languages that do that, but SV doesn't. It is sort of a big jump.

JH: You are talking about a paradigm shift to the connection infrastructure. It seems like it should go to the SV-BC committee. This idea may be a good one, but it needs to fly on the bigger SV scale first.

JL: I understand that. Being able to connect in a traditional way doesn't preclude using strings. Strings is just another method. Are there not VPI methods that allow strings?

KB: Yes, you can do it with VPI but not with the language itself. No one in the SV community has promoted this...even Mentor. You are getting a lot of resistance from us here. The way to get over that is to show what this language will look like on the SV side. If you can make a case that it is a clean coherent method then you will get a better audience.

JL: I have proposed and described some of these objects in the past. I am not sure whether it went to the list or web site. There are some problems. The higher level interface gives us the capability to deal with some of the time problems.

SL: I want to stop here and discuss how to move forward. I think this discussion is good, but I would like to see it continue. Does Ken still want to lead the group?

KB: I can continue to lead. Why don't we just continue this discussion next week.

SL: I think that would be great.

JH: That collides with the assertions subgroup.

JL: What about multiplexing?

JH: I think we should interleave. Assertions can meet next week and embedding the week after.

SL: Ken, can you summarize the convergence we had around allowable names and objects?

KB: Yes.

-- ScottLittle - 2010-05-05