Attendees:
- 00000000000000010000101111000 Qamar Alam
- 11111111111111111110101111111 Himyanshu Anand
- 01111111100111111011101000111 Kenneth Bakalar
- 11111010101101101110110000111 Prabal Bhattacharya
- 00000000000000110000101001000 Sri Chandra
- 01111011111111111101101011111 Eduard Cerny
- 11101110000101101011101111101 Scott Cranston
- 00000000000000010000000000000 Dave Cronauer
- 00000000000011000000000111111 Dejan Nickovic
- 11011101111001000000000000000 Mike Demler
- 00000000000000000000000000000 Surrendra Dudani
- 11100000001111111111110011011 John Havlicek
- 11100011001000000000000000000 Kevin Jones (RGG Leader)
- 00000001111111111011101111111 Jim Lear
- 00000000000011101110000000000 Top Lertpanyavit
- 11111101101111111111111110111 Scott Little
- 00000000000001000000000000000 Erik Seligman
- 10100000000000000000000000000 David Sharrit
- 00000001000000000000000000000 Murtaza
- 00000001000000000001011001100 Martin O'Leary
Decisions:
Action Items:
Details:
HA: We have been trying to get the requirements in shape. It might be good to number the requirements so that when we take a vote either by mail or phone. Also, we need to talk to Sri and get the voting requirements sorted out. That is what we are thinking about to focus on this meeting. I believe that most of the requirements there. Once we get them into a bulletted list we might see a need to further break down the requirements. That is easier for people to vote if things are numbered and broken down. Any discussion?
KB: Each section has numbers, but they aren't numbered.
HA: Yeah, I was talking about the requirements in your section.
KB: Those numbers aren't permanent though. If you add something else things get renumbered.
HA: I agree that for the requirements voting we need to number them and make it permanent.
KB: Is there an archive of the mail reflector.
SL: Yes. It is only available to Accellera members. Go to the Workspace tab and then click on your account name and select "My Participation" then click on the "asva" mailing list and then select the "Archives" link.
KB: That seems hard. Can we get a button.
SL: I will look into that.
HA: One thing that we had discussed in the past that is not reflected in the requirements. Prabal, do you want that in the requirements?
PB: It has been a while back. If I see a need I will post it on the requirements page.
KB: I think that something like wreal is a language feature and not a requirement.
PB: I think that what we talked about was requirements on wreal.
KB: Right, but it has to start w/ the language justification and not with the feature. Wreal is weak as defined b/c there is not wreal boundary element or resolution. There are two ways to justify adding it. One way is that it is common practice and the other way is to say that we need it for assertions and there is no other use model to do this.
JL: One comment from a modeling perspective. Wreals are really inadequate for that.
KB: Commercially it is hopeless. The Verilog family of languages grow by accretion. This is one of those things.
PB: I think it actually went back to the use model of assertions. It depends on the use model. Do we actually need SV reals to communicate with VAMS or are there other ways. That is what I am trying to gather my thoughts about.
JL: I am not sure that wreal or SV real are satisfactory. I would like to see something with a more satisfactory interface.
PB: Why don't I go back and I will send out an e-mail. If there is agreement then I will add a requirement.
SC: Is the belief that the concept of wreal is inadequate?
KB: They are a bit crippled.
JL: A generalized resolution function is more powerful than a wreal.
KB: There is pressure from several directions to extend SV to use one of several methods of analog events. People are using very elaborate methods to achieve this today. Wreal is not a general enough facility.
SC: All of those could be solved with wreal extensions?
KB: I don't believe so. THe heart of the problem in SV is that the definition of net is too limited. Wreal is a wart on the SV type system though. Why only builtin resolution functions? Why not a generalized method? That isn't our job though.
KB: Where did we leave off? We were talking about the overlap between John's list and my list. Item 1 and 5 are already on my list. I don't know whether others agree. Looking at the other three...item 4 is certainly true. We can't break the name resolution system of SV or VAMS with our changes. Then we go back to 2 and 3. Item 2 seems to be a language feature and requires justification as a language feature.
SL: We can rewrite this as more of a language feature.
KB: Moving on to 3. This overlaps with mine as well. Then he adds some details and we part ways.
PB: Should we have John come and explain this. I am now more confused.
EC: I think the purpose it to allow connections between SV, VAMS, and ASVA checker modules.
KB: This is much to expansive if that is what he wants to do.
EC: You could restrict them to packed data types.
SL: We will fix this and explain the use model more fully.
KB: When you write stuff down it clarifies your own thoughts. In the e-mail I sent out yesterday I tried to clarify my thinking about how to look at changes from the perspective of the requirements. Whenever we look at a language change we need to measure it against the requirements. Is it economical and does it meet the requirements? I know these are judgements but still you can make the judgement against the framework of the requirements. It also makes it easier to discuss language features. If this feature for a more robust communication channel than SV provides leads us to believe that we need integral types in VAMS then we can frame it in that way. I am sorry. I am dominating this conversation and I am not sure it is helpful.
JH: 2 we can throw out.
KB: Are you thinking about instantiating only checkers?
JH: No, I wasn't going to do that, but there are problems with events. I was looking at how I was going to get events into a SV container. There were several options. One option is to pass primitive types and assemble them, but that won't get you things like cross events. Checkers do accept cross events.
KB: Can you pass events through ports in SV?
EC: You can pass events as a ref.
JH: The checkers follow property instantiation semantics, so you can pass an event expression to checkers.
KB: You can't pass events to other things?
JH: It has to be a legal binding to a ref port.
EC: In a checker it is an event port.
JH: It was specifically created to be connected to an expression. For instance, posedge clock could be passed.
SL: A.1.8 in the SV 2009 describes the grammar.
JH: Back to item 2. What I mean is the module is an SV module and the instance is in a VAMS context. I don't care if this requirement is met. This was supposed to make our lives easier.
KB: I agree that we should make our lives easier by importing less of SV.
PB: Why do you say nonref ports?
JH: The intention was to be able to hook-up events. If you want to craft an event declaration in the VAMS and then hook that up to a ref port you would be able to do it.
PB: You are going to throw away requirement 2?
JH: Yes, I won't prejudge how we are going to do it. We can still do this, but I am not imposing the limitation any longer.
KB: The checker has extra possibilities. You can pass in extra items as if they were types. The interface to a checker is more broad with types, but the modes are all in.
JH: Yes, that is correct. The checker can generate outputs, but not through a port list.
KB: Right.
JH: Item 3 was intended to try and make sure there is capability to do reasonable connections without additional data marshalling code.
KB: I am very sympathetic.
JH: I can see as not having it as a requirement but trying to achieve these things in other ways. In these I was pushing at some of the host language requirements. Those requirement impose some limitations and I was trying to ensure that we can hook things up in a reasonable way.
KB: The way that I propose is that we have to judiciously extend VAMS until VAMS understands what we need in expressions for bound instantiations. If the channel is too narrow then we need to extend it, but we need to do this judiciously. I think that we are agreeing.
JH: It could be useful to get feedback on the specifics of what is in my requirement 3. Some may want to approve this and some may want to wait.
KB: Here is how I interpret your item 3. If we define a language and write an expression then the actual has to have an interpretation in its context. If we need to drag parts of SV into VAMS then we should do it carefully. The first sub-bullet I object to. What is an SV expression? How do I know?
SC: Given that this thing is instantiated w/in the VAMS scope. What could you put in that is legal to the SV language in the VAMS scope?
JH: An OOMR. One usage that I had envisioned was bringing the VAMS variables and quantities via local or upward resolution. Maybe you would have to do some variable creation in this scope. Other quantities that had been written in the SV part of the mixed model one would access heirarchically. That is one way I had envisioned to get both types of quantities inside the assertions container.
SC: The reason for allowing them is so that you can pull things from different parts of the design into one checker?
JH: Yes. I can write OOMRs in an instatiation and there are search rules for that.
KB: The search rules are dependent on the context where the OOMR appears. In order to resolve an OOMR depends on the context. If the expression is going to be an SV expression then it can be any expression. '+' means a different thing in SV than VAMS.
EC: If it is an OOMR then isn't it searched via the global OOMR? It doesn't have to be a global path and can be resolved over the global path.
SC: Why does it have to be a VAMS type if all you are doing is passing the OOMR down to the checker.
KB: We are going to define something that is only valid in the instantiation?
SC: The whole reason for going down the bind path is to answer questions like that. Putting it in the bind instead of instatiating it means that we don't have to parse it in the context of VAMS. Right? What is the reason someone proposed the bind in the first place?
KB: In order to back annonotate designs with checkers.
SC: Was it just that or for other reasons?
KB: I think this discussion has expanded outside of just defining assertions to defining how we get access to several contexts.
JH: For interest of history, the original Freescale bind proposal was because we thought it would be an easier way to limit the scope of some of these changes to a more narrow scope.
KB: That is a good purpose, but my understanding of bind is to back annotate a tb hierarchy. I understand that you are using it for something else.
SC: It gives you a controlled way to break the rules.
JH: How about a controlled way to relax the rules. The intention is to not prevent a harmonious language in the future.
KB: That is an important requirement that isn't here.
JH: Bind is not the same as instance.
KB: You are wrong about that.
JH: Why do we need a keyword bind?
KB: The effect of the bind is to create an instance.
JH: Why does the parser have to deal with the keyword bind?
KB: You can do it two ways, but the result is the same.
JH: They syntax of the language is not the same without bind. Within this language even though I am talking about a syntactic entity that has the same semantic behavior I can use the syntactic entity to help me contain the relaxation of the rules.
KB: Relaxing is the wrong word b/c you want to change the way things are for only a given entity. If the OOMRs refer to things that VAMS knows about than I am fine. Maybe we are talking about what names are allowed. Do we need to extend the sorts of names that are allowed?
PB: Also the data types?
KB: We may need to add data types.
PB: One question I have is that say I have an OOMR to a structure. Why does it make a difference if that OOMR is to a structure in an instance vs. bind? The target is VAMS. If the actual expression evaluated in the context of VAMS or SV.
KB: It is evaluated in the target context. Evaluated means to get the values from the names and do the arithmetic.
PB: We are talking about doing the evaluation in VAMS.
JH: If you have a mixed model and the name resolves to a SV structure. What do mixed-model tools do to evaluate that structure?
SC: In the pure instantiation case everything has to be evaluated in the target scope.
PB: Does bind work the same way?
SC: It is defined that way and supposed to. We could theoretically create something else that says something different.
KB: Does anyone remember the note I wrote about the little additional wrapper. That does just this.
PB: If we create something other than a bind to bypass this restriction then how does that help us be harmonious w/ SV-VAMS.
KB: It isn't harmonious at all.
JH: I want to note that I never suggested super bind or changing the syntax. My vision is what will bind look like in SV-VAMS? Then bind will be evaluated in SV.
KB: I don't understand it so, I would be voting on I don't know.
JH: It is also fair for it to fall for lack of intelligibility. My point is on the question of items 2 and 3. I will strike 2, but I would like to see item 3 get its day.
KB: My conclusion is that 1,4, and 5 are already incorporated.
JH: We will try to think about this and come back with what we want to do with these requirements.
KB: I think that there is also a requirement to explain it well enough to say yes and no. I think it is fair to put that burden on the author.
JH: We have been through these discussions several times and I don't know how much word smithing can help. We could take a prevote. It would be a precheck.
KB: Actually the only part of 3 I have a problem with is 3.1. The rest I consider to be language features.
--
ScottLittle - 2009-09-02