Meeting 37 Minutes

Teleconference, November 12, 2007

A quorum of seven voting members present. Three non-voting members are also present. Attendance and voter status indicated on the roster web page.

Attendees

* Voting members: Michael McNamara, Yaron Kashai, Darren Galpin, Andrew Piziali, Joe Hupcey, Serrie Chapman, Matan Vax

* Non-voting members: Charu Aggarwal, Joe Daniels, Mark Strickland

1. Call to order

Call to order on November 12th, 2007 at 9:04 am PDT (1604 UTC).
Andrew reminded members to mail a message to "rollcall@ieee1647.org" in order to record their meeting attendance.

2. Approval of October 8^th meeting 36 minutes

Darren Galpin made the motion

Matan Vax seconded the motion

No discussion of minutes and no objections

3. Review outstanding P1647-2008 clause issues

Andy : There was one action item from the last meeting that I have down here but I don't have the status on it. Matan will open an issue to add untyped description to the basic types section of the LRM. Matan, have you opened that issue already? Do you know what the status of that is?

Matan : I actually have the material ready, so it shouldn't be hard but I haven't done that so far.

Andy : Okay, I would like to roll this in ASAP, because we're trying to close the number of issues that are actually remaining for the final ballot ready draft. So, if it were possible, could you put that text in place and open an issue for Joe this week so that we can make sure that it's in the draft 5 that goes out?

Matan : OK, I'll do it this week. I'll try to make it.

Andy : The review status. The status update: There were 44 new issues opened since the September general meeting, most of those were opened by yours truly (Andy) after I read the draft 3 cover-to-cover. Some other people hopefully took a look at it but most of those issues were small syntactic and grammar issues. At this point 37 have been fixed and need verification. There are currently no issues assigned to the task forces. Five issues are in the status “analyzed/work-in-progress,” several we'll discuss later in the meeting this morning. They are issue 844, which is “DUV/DUT Substitution and [its interaction with] dut_error().” Issue 847 is “Extending Type Syntax Clarification.” Issue 848 (“Determinant Fields Shall Not Be Explicitly Referenced?”): I sent an email message out 15/20 minutes ago about determinant fields, whether or not they may be explicitly referenced in the context of inheritance and we have some feedback from Guy Mosenson that still needs to be taken care of regarding, I think that was on draft 3 or maybe draft 2. Finally, issue 855, which is somewhat related to 847, that is titled “Superfluous Syntax Box Semicolons” and that may go on. Matan and I have had some dialog on that and we'll talk about that in a few moments also. Lastly, there are two issues Joe this morning that are currently assigned to the editor, ready for changes. One I know I changed just this morning so you might not have seen it yet.

Joe D : 824, that’s correct, in part because of the way the table contents work for automatic generation but I'll correct that. And then 877 that Darren caught, yeah good catch.

Andy : Perfect - so we're in pretty good shape there. So, forward looking, regarding where we're going with the LRM at this point. As you know, draft four was posted for review last week. The changes there are the fixes that have been made since draft three, and some IEEE boiler plate things I think that Joe has rolled in at this point. In December the final draft will be reviewed so draft five will be available early December, and we're still planning on balloting a copy of the LRM in January.

Joe : Let me check that you and I are in sync. Draft five will be in place no later than just after Thanksgiving. Therefore the work group will vote on that. We will be voting on that to ratify that in the December meeting and then go to ballot later in December.

Andy : You are correct – when I said the January ballot I was referring to the IEEE so I will add an explicit bullet here that in December the working group will vote on draft five.

Joe : The terminology is that “the working group will ratify draft five in December” and we will go to IEEE ballot with draft six. The only change, for those people on the phone is, we pull out all the issue box numbers and all the change bars get removed. It will look like a really clean copy and that’s the idea.

Andy : Okay – thanks for that clarification there Joe. I’ve updated that here in my notes and Serrie will copy it. So, we’ll have a final draft in December, that will be draft five and the working group will vote to ratify that draft. Then in January we’ll go to ballot with the IEEE. Any discussion, comments, questions on the status at this point before we get in what will be the bulk of our discussions at this meeting which will be items four and five?

*NOTHING*

4. Substituting “DUV” for “DUT” in the text of the LRM

Andy : This is substituting the term “design under verification” and the acronym “DUV” for the term “design under test” and its acronym “DUT” in the text of the LRM. Just as some background, I opened issue 844 with respect to that to suggest that we make that change in the text, but don't, of course, change any of the language components which use “DUT” in their method names or struct names or anything else. The history is that in early days of design, designs were tested and the term that arose was “DUT” or “design under test” referred to the system that was being tested. As Darren has pointed out, this system could be all the way up to a bread board or a physical device in the lab. When simulation was introduced, the term carried forward into simulation-based designs that were represented by software. In recent years, I guess most emphatically in the past three years, the term “DUV” or “design under verification” has gained some favor because we are generally verifying designs rather than testing them so it makes sense to refer to those designs as being the DUV rather than the DUT. So, that’s the background. I think most of those on the call know my position, I’m in favor of DUV but I’d like to open the discussion and try to find out what people's points of view are. Both from the perspective of the various tool vendors on the line as well as design houses that are using the language within this context. So, the floor is open.

Darren : Hi Andy. As I kicked up a fuss about this I feel I ought to speak. Firstly, although “DUV” is becoming more common in literature, we have an internal problem in Infineon in that DUV also can mean “design under validation.” From a language point of view, we certainly need something in the spec which, if we’re going to use DUV, clarifies that you still use dut_error() when looking for DUV errors. Because we have this historical legacy in the code which uses “DUT” but the new text, if you like doesn’t use it. So, as a minimum, you need to insert something which clarifies that we’re still using dut_error() and that a DUT error is one of the things related to a DUV error and I guess, long term, you need to look at introducing a duv_error() language construct to make the language a little bit more coherent with itself. Internally, at least within Infineon, we would generally use DUT and having seen some Cadence presentations this week I would say that they had about a 70/30 split in favor of DUT over DUV at the moment.

Andy : Great! Thanks Darren. Charu, when you were widely using e within your organization what terms did you use?

Charu : It basically agrees with what the previous speaker said. We understand the meaning of DUV but within the flow we are looking for DUT. TI generally uses DUT.

Andy : Mark, would you mind commenting from the perspective of your time at Cisco?

Mark : We generally use term DUT. I think that we don't even think about what it means anymore. Probably just from a historical perspective “the DUT” just means the design to the verification guys. There isn’t really any usage of the term DUV.

Andy : Others on the line?

*SILENCE*

Andy : Any thoughts Mac?

Mac : My feelings are somewhat with the last one where DUT is what people have used for a long time. DUV maybe brings it up to a higher level more academic view, but DUT has been used all along.

Andy : So, you are in favor of leaving it?

Mac : Yes.

Joe D : Perhaps we deliberately defer this until next year?

Andy : A reasonable suggestion. Perhaps we drop it as its something that e users find distracting Perhaps DUT is a historical artifact.

Joe H : It appears to be pretty unanimous in keeping with compatibility.

Mac : We can table it indefinitely. People can bring it up, we can say no – lets go back to DUT or we can defer it and people who like DUV might feel a little bit better but its effectively the same.

Joe : *GARBLE* *GARBLE* *phone randomly cuts out* Lets not take up too much time *phone randomly cuts out* showing up late in the cycle *phone randomly cuts out*

Andy : At this point, I'm in favor of leaving the text as it is. Joe Daniels, we could leave the acronym DUV in the early section of the document so that people know what DUV means but we’ll continue to use DUT throughout the text. Of course leave that term in all the e language elements also.

Joe D : Except that if we’re going to show it as an acronym, we have to use it at least once.

Andy : OK, if we’re not going to do that then just we can delete the entry.

Joe D : Yep – and you and I can confirm that next week but that’s the way I’m looking at it.

Andy : Any objections to this resolution?

*SILENCE*

Andy : Perfect.

5. e language error handling: “check that” and “assert”

Andy : e language error handling: “check that” and “assert”. The background here is the following: “check that” is a language construct that was introduced in the e language at an early stage, intending to associate a Boolean expression that references some behavior of the design under verification or the DUT, as we’re calling it, and then have an associated action in the case that the check fails, typically an invocation of dut_error(). A less well known construct also having been there from the early days, is called assert. assert is the same as assert in other languages such as C or Java, C++ - and that is a Boolean expression representing a truth, a status that must be true referencing elements of the e program itself. If violated, the assertion will then fail and the program will come to a halt and there's some error handling that can be configured, associated with it. Darren brought to my attention that assert, where expressed should be used is not. Rather, often check that is being used both in the case of checking DUT errors as well as errors within the verification environment itself. So, I’d like to open the floor to some discussion on the use of check that and assert. Then, relative to the outcome of that discussion, we’ll look at that section of the LRM and discuss and see WRT the current recommendation as in does it align with use? And, probably more importantly, we ought to discuss whether or not, if the language recommends that check that is used for DUT errors and assert for verification environment errors, whether we ought to leave that as it is, recognizing the fact that that may not be the way in which those constructs are widely used by e programmers. So, the floor is open for that discussion

Darren : Hi Andy. Darren again. The problem is that the assert statement doesn’t say it checks for test bench errors. It explicitly says that it checks purely for e code errors therefore the problem is what if your test bench is actually made up of other pieces of IP which are not necessarily [written] in e? For example I might be using C models of memories or importing something in which is SystemVerilog or something in which case I can’t use the assert error because the definition in the LRM is to use it for e code and I can’t use the dut_error() either because that’s meant to be purely for the design under test. Therefore, there isn’t actually an official error mechanism I can use in this case.

Andy : Given then that assert allows a Boolean expression to be used with it, whose operands can be both native e variables and fields, as well as references to external components, that is C program component sor Verilog test bench components, I’m not sure how assert doesn’t serve that purpose.

Darren : The reason why it can’t serve that purpose is because the LRM explicitly says that its only used for checking the e language

Andy : Ah – gotcha! So, if that description regarding assert conveyed more broadly that its intention was to check test bench errors, independent of whether we’re referencing e code or external elements, then that may satisfy your concern here?

Darren : Agreed. There is a minor problem then with systems which are eRM compliant because if you write, say a master agent which can be both passive and active and you’re moving it around interfaces, some of which may be test bench and some of which may be your DUV/DUT, then you’re using one set of checks: one for checking the test bench and one for checking bits of your design and technically you’re not going to be agreeing with what we’ve just stated.

Yaron : I think that there’s another way to drive this. I would say that asserts are failures that are not expected – when you write the test bench you take into account the possibilities that things will fail and those are DUT errors. Asserts are really errors in the logic of the [verification] program and therefore I would make that the distinction. That is certainly how asserts are used in the implementation of the language. In that case, whether you implement a component in e or whether you implement it in HDL, if it is a check that you anticipate could possibly fail, it should be some sort of a DUT check.

Darren : So, something like in Java where if something could go wrong because your thread of execution’s gone somewhere unexpected and you’re throwing an exception then you would put an assert but if I’m actually explicitly checking that values are correct we use check that? No matter where. That sounds fine to me.

Mark : We don’t exactly use it that way. We use assert for things that we know could go wrong based on the integration coding , but don't want a message to pop up and say “DUT error” because we absolutely know its not a DUT rror.

Andy : So, this is a state Mark where there’s an assumption being made in the integration code that some condition needs to be satisfied and the assertion is there to make sure it is satisfied and, if in the current integration its not, then it fails?

Mark : That’s right. Perhaps the LRM shouldn't be dictating how you use these things. Theres no reason why someone can’t use it however they want.

Joe D : The LRM doesn't say if you can use it a particular way or not.

Darren : Except that the LRM does at the moment say that you can only use assert for checking your e code. If you freed that up so that its for checking test benches then you would have a bit more freedom.

Joe D : Agreed – that should work with the design.

Andy : Joe, do you recall whether there is currently an issue of any sort open with ‘check that’ and ‘assert’?

Joe D : No

Matan : Darren is right. The wording is not as good as it could be. It's customary to use assert to assert properties that you suppose hold just to make them explicit and hopefully exit when they don’t. From the point of view of formal semantics, the way they are used is not restricted to a methodology. They check a condition and otherwise issue a DUT error. I think that a better wording could be used in the LRM.

Andy : Throughout the LRM in the descriptive text associated with the language construct, and this is true even in newly introduced clauses such as sequences, we describe what the intended use is behind that construct. So, if we clarify the intended use for both the case of dut_error() as well as assert it sounds like we could address the points which have been raised. I’m going to solicit a volunteer to open an issue that points out the state of the current draft four as to where they are on assert and dut_error() and suggest what I think will be a minor clarification in the recommended use and in that way the whole thing will be addressed. Can I have a volunteer to open that issue please?

Darren : Yeah, okay

Andy : Thank you Darren

Matan : Darren do you think that there’s a problem with the way the dut_error() is described?

Darren : I think there’s a particular problem with assert in that it explicitly says you’re checking e code.

Matan : That’s what I thought

Darren : That’s one obvious place. Now it depends whether we intend assert to be used more generally for checking test benches or we go along the lines of what Yaron was suggesting and that assertions are general checks of something going fundamentally wrong in code you’ve constructed and then use dut_error() for checking more expected values. Now I guess its up to us to decide which of those biases we prefer and I guess that will make the most of the review of what’s there and the entire LRM with respect to this.

Andy : I like that description that Yaron made between assert being used for unexpected values and using check that for expected values. That seems like a clean way to separate it and in general that also clarifies values between the verification environment and the DUV itself. Okay, are there any other discussions on ‘check that’ and ‘assert’? Then, I’ll turn the floor over to Joe Daniels and agenda number six.

Joe D : I’d like to defer that and go through issues 848 and 855 as I think that will really shorten my list of things to talk about.

Andy : Okay – so issue 848. 848 is “Determinant Fields Shall Not Be Explicitly Referenced.” In section 6.4 of the LRM we read:

6.4 Restrictions on inheritance

The following restrictions shall apply when using inheritance:

• Determinant fields shall not be explicitly referenced.

• Generation of a parent does not create like children.

• when subtypes shall not be added to a struct with like children. Similarly, a like child shall not be created from a struct that has when subtypes.

The question in this issue is, in 848, what is the intention behind this statement? “Determinant fields shall not be explicitly referenced” as the blanket statement is, of course ,wrong. A determinant field such as the field name ‘kind’ in a struct that’s being used with a determinant field can be used as an l-val that is a field to which one is making an assignment or change or an r-val, a field read in many contexts procedural codes and actions within a method and constraints and constraint expressions. So, the open question what was the intended meaning behind that restriction and where does it come from? Matan and I corresponded on it a little earlier, over the past few days actually and he was not aware of where that came from. I’m just wondering if Yaron or Mark can think of in what context that would make sense?

Yaron : No sorry - I see no reason for this restriction.

Mark : Me neither.

Andy : Matan has suggested simply dropping the bullet, which I was okay with as long as we’re certain that no one's overlooking something. So, my proposal was that I will suggest on issue 848 on the next draft that we drop that bullet out of the LRM.

Yaron : There is some sensitivity to the determinant field obviously. Everyone’s aware of that, but that bullet doesn't help there.

Andy : Issue 855 is titled “Superfluous Syntax Box Semicolons.” The background there is that as, I think most of you know, in the e language semicolons, and I think in many cases commas also, are used as separators for elements: to separate one element from another. So, for example in a literal list, one would specify the list as “a;b;c”, where a semicolon is needed to separate each list element from the next. This is also true in all other contexts such as actions within methods and the context of statements within an e module and about any place else you can consider. So, I recently finished reformatting all of the code examples in the LRM to remove the semicolons which the language did not demand and only leave those that serve as a separator in respect to context. In the process of doing that I opened issue 855, pointing out that in the syntax boxes, we would typically specify an example I’ll use is for event: The body of an event one would have an open brace, an action, and the way the syntax box specifies this as action—semicolon and then ellipses. The intended interpretation to mean that one can specify zero or more actions. If you specify more than one, you separate each action from the next with a semicolon. However, that’s not clear in my opinion in the syntax box diagram so I suggested that instead we would write in this context “action” and then, in brackets, semicolon, action and then close bracket and then ellipses, which would indicate that if you specify one action you have a semicolon for every action in addition that you add to separate it from the previous one.  Matan and I agreed that if we made this change wholesale throughout the LRM in the syntax box descriptions, many of them would become more complex and somewhat obfuscated. They would be technically perhaps more correct, but more difficult to read. The current proposal was to state in section 1.4 of the LRM where we talk about conventions sued in the LRM that when we state anything semicolon ellipse or anything comma ellipse it means exactly what I just said: That if you specify two or more of these preceding items then they must be separated from one another by a separator character, either a semicolon or a comma. So, I’d like to open the floor to any discussion on that subject and then we’ll move to the editor.

Joe D : I would like to propose this as a resolution.... *slightly mumbled*

Andy : So you suggested Joe that we simply add that explicit convention to the appropriate section of the LRM?

Joe D : Yes…….PDF page 30 … physical page eight where it actually talks about constructs…….

Andy : Right now we have an element there for comma – is there actually one for … actually it doesn’t look like it.

Joe D : it says an item followed by a separator, usually a comma, a semicolon and an ellipse ……..we can enhance that description a little bit…….

Andy : I like that - any other comments?

Matan : I think that this is the right way to go. Just on some comments on the background. The semicolon and the comma function as separator characters in the e syntax, but for semicolon we have actions in action blocks, which is the most common case, we have an empty action. So, that’s it’s acceptable to have a semicolon at the end of the last action. In most other languages, such as C, C++, Java the semicolon is a terminator – everyone likes to … the next line and not worry whether or not the last action was the last till now …. So, it is a common style in e to use it as you would in Java or C and have a semicolon on the last action. But obviously you’re right, from the pure syntactic perspective, it is not only that its not required, but what you have is an action block with the last action being empty.

Andy : Thanks for pointing that out that there is an empty action because if there were not then a lot of code would not compile today with the current implementation.

Matan : Yes and everyone writes this way so it makes sense and we do that in our code.

Andy : I'm dating myself because it appeals to me to use it as a separator from my early experiences with the Pascal language, which also uses different characters as separators. So, its not foreign but for 21^st century programmers, it may be somewhat foreign.

Matan : So, I’m actually wondering if it worth the trouble of going through the code and removing that last semicolon that must be some trouble doing that and I’m wondering if its worth the trouble?

Andy : It is actually done,. In draft four the code has all been updated. It was worthwhile exercise not for that purpose alone but also for the fact that a small number of code errors were found and I corrected them. They were minor things but they were incorrect code if you tried to compile them they would have failed. So, if you look in draft four you’ll see that the work has been done already.

Mark : So, if you had a list of integers what would happen if you had a semicolon after the last element in that?

Andy : You’re not allowed as that would be a NULL list element.

Matan : You don’t have an empty expression and these are semicolon separated expressions/ semicolon separated actions.

Andy : So, if we just put something with the ellipses that said that we always could or could not put a semicolon – would that not fail when you applied it to a list of integers?

Matan : We didn’t say that you can or cannot – we said that when you have the ellipses signs then the convention says that it means zero or more of these non terminal occurrences, separated by the separator character. But, in the case of actions in action blocks, we just have an empty action in the sequence so it's in fact permissible to put a semicolon after the last action. We don’t have an empty expression so its not permissible to have a semicolon after the last expression in this literal.

Andy : That makes sense to me. It’s also true that the language does allow empty statements because within particular code, such just before an end code block, you’re allowed to insert a load of statements and the last one in fact can be terminated by a semicolon before the close right?

Matan : We have that in all the syntactic categories apart from expressions and for some reason we have it for statements and for struct members, or actions even for cover items and constraints. But we don’t have that for expressions as then we would have for example parameters that go into a method would end with a comma because it would then be an empty expression. There are many constructs which become ambiguous if you have empty actions.

Andy : The C style for loop for example.

Matan : Yes, that’s a good example.

Andy : We agree that we will update the the convention early in the document to point out explicitly what we mean by this, and then we’ll leave the syntax diagrams as they currently are in LRM. Any objections?

Joe D : On a practical matter we have an issue. Currently in draft four, when you see the syntax box with 855 change bars these will be backed out just as issue 844 will be backed out.

Andy : Okay, you have the floor Joe anything else you’d like to bring up?

6. Editor

Joe D : Just to reiterate what we said earlier and to clarify. There are two steps with the work group and an IEEE ballot. The first is the ratify step when the work group votes to say that this is the draft that we say we want to send to IEEE to be balloted. Then, the second IEEE ballot step. So, the first ratification vote will be in the next meeting in December. Am I correct?

Andy : Correct

Joe D : First will be early December, so I need all changes by Wednesday, November 21^st. That will then give me enough time to turn things around and to get you guys a draft copy roughly by December 1^st so you’ll have 10 days or so to look at it before the meeting to say you’re okay with the final copy. Unless there is an issue with the time line. Andy, do you have anything to add to that?

Andy : I don't. I just want to reiterate that there are currently roughly 37/40 issues that need to be verified. The majority of those are mine. I have no problem with it. Does anybody else?

Joe D : Actually it’s larger than that. There are 52 issues. Of those, 16 were filed and addressed at some point in the previous two drafts so we have 37 that still remain. There are a big chunk which were originally filed by Matan and Andy you have the bulk of them. Also, while I have the work group here, you have roughly ten days to address anything that’s in there before deciding that that’s the version we send to ballot. Need to verify what has been done.

Andy : Any objections to that?

*SILENCE*

Joe D : Once sent to ballot I go into sleep mode as I have no work to do until the ballot comes back. * garbled*

Andy : We’ll discuss the timing there at the December meeting.

Joe D : I appreciate everyone being thorough … I’m grateful

Andy : Thanks Joe

7. Other business

Andy : Please send message to rollcall@ieee1647.org. Any other business?

6. Call for essential patents

The IEEE-SA updated the patent policy effective April 30.

The details are available in updated slide set at

http://standards.ieee.org/board/pat/pat-slideset.pdf (See “Patent related” from the IEEE 1647 home page, “Slides about IEEE Patent Policy”).

If you believe that any patent claims are essential patent claims, please inform the working group. Review the posted slides for more information.

7. Next meeting

Andy : The next meeting will be on December 10^th at 9 am PST and, correct me if I’m wrong Darren, that would be 1700 UTC?

Darren : That would be

Joe D : Any conflicts?

Serrie : We’re fine.

8. Adjourn

* Solicit motion to adjourn. – Darren Galpin

* Ask for second. – Serrie Chapman

* Adjourn meeting