Meeting 36 Minutes

Teleconference, October 8, 2007

A quorum of seven voting members present. Seven 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, Sandeep Desai, Stylianos Diamantidis

* Non-voting members: Charu Aggarwal, Serrie Chapman, Joe Daniels, Matan Vax, Ofer (Intel wi-fi), Mike Stellfox, Mark Strickland

1. Call to order

Call to order on October 8, 2007 at 9 am PDT (1600 UTC).
Andrew reminded members to mail a message to "rollcall@ieee1647.org" in order to record their meeting attendance.

2. Approval of September 24^th meeting 35 minutes

Mike Stellfox made the motion

Mike McNamara seconded the motion

No discussion of minutes and no objections

3. Review outstanding P1647-2008 clause issues

Andy: The next item on the agenda is the status. First, I'd like to go back to the action items from the last meeting. I had one action item which was to look up the term “unsafe” and find out whether unsafe is in fact documented in current, 2006, LRM. It is not―I did check over the reflection facility and it’s been updated to use a term that conveys that meaning. Joe Daniels can I ask you to quickly tell us what change you made to the reflection document to reflect that?

Joe D: What I did within the reflection clause is I found another place where the term “unsafe” was used and looked and believe confirmed that that was an appropriate reference. If it turns out in the review process that that is not, 30.4.3 if my memory serves me correctly, and if its not then I'd like people to tell me and then we'd need to get the appropriate material from Cadence. There’s just a reference to unsafe but we never actually had the actual material itself.

Andy: So, the upshot is that a reference has been added to that section of the reflection document, the reflection clause?

Joe D: The upshot is that any time unsafe is used it actually now a reference to 30.4.3, and there is a note to get the new material.

Andy: Okay. Well, we can double check that. Thanks. The second action item was Matan was going to provide an updated description of the definition element as part of Issue 730. As if this morning Matan, I haven't seen that yet. Were you planning on providing an updated description this week if possible?

Matan: Yes, sorry I can do that. I just haven't got to it until now but I'll do it in the next couple of days.

Andy: Good, that will allow us to make that change to the LRM (draft 4) update later this month. Then the other action item I had, Matan, which is one that shouldn't take much time in fact maybe with Mike on the line right now, is issue 690.

Issue 690, to jog your memory is where MVLs are mentioned or addressed. Mike did suggest that we have a more complete explanation of an MVL. A couple of people have looked at it and thought that perhaps we ought to reference the VHDL IEEE standard rather than replicate the description there. So, we were going to close that. Mike, would you have any objection to that if we put a reference into the VHDL stuff?

Mike: No.

Andy: Okay, thanks. So, Matan if you can close with a note that we're going to make a reference to the IEEE VHDL spec.

Matan: The intention is to pull in the definitions from VHDL as it’s the VHDL interfacing. It, in fact, makes more sense to reference the other LRM rather than just replicate it is a reference to that in the language view it’s meant to be a reference to whatever it means in that other language.

Andy: Absolutely. Because this particular clause we're talking about interfaces an HDL reference into VHDL so we have to be precise.

Joe D: What I did is within the reflection clause was put a forward reference to the ???? Operators and within there we defined a ???? Value and within there I think that will show up pretty quickly.

Andy: You might want to crank up the volume ...

Joe D: Sorry. It's just I understand pretty much what's happening there. Matan understands what happens. It is just going to be a reference to a document that we already have as a reference anyway.

Andy: Okay. Were there any other action items that anybody was aware of?

Matan: I looked into this issue that Mark raised about the unsafe operator and I realized that we are missing a subsection in the part which talks about which talks about e basic data types. This chapter corresponds to the chapter in the Cadence manual, and there’s one section missing there, which is the untyped pseudo-type. There, the unsafe operator is defined. We don't have that correlated in our LRM; I'm not sure why it is missing. We might consider putting it in its place and then doing the latest document stuff which is to reference that.

Andy: That would make sense to me―that was what I was hoping to find when I went back and double checked the 2006 LRM initially. I didn't see that in there and I was curious as to why it was absent.

Matan: Does it make sense to raise an issue and pull up that missing subsection? There's quite a lot of text which specifies what the untyped, pseudo-type is and what the unsafe operator type is. In its original state it's, I don't have the LRM in front of me but the version one LRM has it in the e data-types, maybe chapter five or something.

Joe D: Yes, it is chapter five. The only thing that we currently have in there are [section] 5.2, non-typed expressions, that would be the logical section to add this new material.

Matan: Actually, it's not exactly the same time. The section before that talks about data types and it talks about and strings and lists and all that and untyped is a function like typed, syntactically, semantically although it’s a non-typed type space holder. That's where it figures in the manual and the Cadence e manual and I think it makes sense. Untyped expressions are those that don't even have that type place holder―they just take any type of the context. It's not quite the same thing.

Joe D: What I think we need is the donated material and we put it in [section] 5.1 as appropriate.

Andy: That makes sense to me. Clearly the reflection clause, one of its uses is to write, for example, debug facilities or debug applications that looks into any program and where type checking is typically a strength of the language in the programming environment, in the debug environment you want to be able to reference objects and values without any associated type information That needs to both be clear and the operator methods. Matan, would you be willing to open an issue which says that this section needs to be added into the correct section of the LRM? Then, if it’s just a couple of paragraphs include those in the issue, if it’s larger than that make available the document and I'll post it in the donated section.

Matan: Its okay. It’s no more than a couple of paragraphs.

Andy: Okay are there any other discussions on the action items?

[Silence]

Andy: Okay, then I'd like to move to the review status:

Currently we have 194 issues posted for the seven clauses, three new issues since were opened since the September general meeting. Those are each sequence issues―small suggestions to correct, for example, a flow diagram. Two issues remain in the analyzed/work in progress status. One we just talked about, which was 690, the MVL. We're going to close that. The other is issue 626, floating point support, which we decided to postpone to the next PAR, beyond the one that we're currently working on. There are no issues currently assigned to editor for changes. Thank you Joe for tackling every one of those required changes and clauses for the draft. As a note, you should have received a message this morning that I did post the draft three of the LRM in the download section of the website. It is now ready for review and we will be working on that document moving forward rather than the separate seven clauses.

As there are several task force chairs on the line I'd like to give them a moment to comment on their respective areas. There might not be a lot to report but Stylianos, you have the floor for a moment. Do you have anything to say about constant fields?

Stylianos: I just want you to know that everything is under control.

Andy: That was my understanding there.

Andy: Darren with respect to encapsulation and name spaces?

Darren: All under control. Please, will all those who haven't closed their issues please close them down?

Andy: Okay thanks. I don't think there are any open [issues] right now. Mark, with regard to messaging, all the messaging issues have been addressed at this point. Am I correct?

Mark: Yep. That’s right, I believe it is.

Andy: Fine and then we have message ports. Matan? Go ahead and give me your vision right now on method ports.

Matan: The only issue that is still open right now is the one on MVL literals. We closed, if I remember correctly, they're all done.

Andy: The task force on reflection was managed by Henry von Bank. I don't think Henry's on the line. Is he? When we talked about reflection there’s one last issue to be taken care of which is the description of the reflection element which Matan will take care of in the next couple of days. Is Cristian on the line? Cristian opened most of the issues on sequences. I think sequences are in very good shape at this point, the three remaining are in need of minor changes which will either be made in the current draft or the next draft.

Joe D: In the current draft ...

Andy: In the current draft. Okay, thanks Joe. The last item I have under review status is the constant kind field, the kind field sequences we had some discussion on the reflector about making that kind field constant to allow for performance optimization and there appear to be no penalty issues by making that change. So, the working group has decided to make that kind field constant and Joe is that captured in the posted draft three?

Joe D: Yes. The only thing that’s not in draft three is the one that Matan raised today about getting the correct material into clause five everything else is in.

Andy: Was there any discussion about making the kind field constant here on this call?

[Silence]

Andy: The last item I have for agenda number three, status update, is an overview of where we are and where we are going forward. So, as I mentioned the draft three was posted on the download section today. Please review that over the next couple of weeks. I'm going to buttonhole a couple of you to go through that carefully, all 464 pages. Several of you will need to do this to make sure that nothing slips through. Our primary purpose of a full draft review is to ensure that no inconsistencies have been introduced into the LRM with the addition of this material and that there is nothing missing, for example how sequences fit in the context of the language. By the beginning of November we hope to have draft four, which will incorporate any issues that were open on the draft three review published for the working group. At that point we'll only be looking at the changes that were made between draft three and draft four. Also, the IEEE format material to prepare that for submission to the IEEE. Then, in December the final draft going to go to the IEEE will be reviewed. Any questions on points going forward here?

Joe D: Just as a formal point: whoever the formal voting members are in the working group will make a formal vote on the pre-ballot draft whether that’s November/December?

Andy: That's a heads-up for those of you who are close to but don't yet have voting privileges in the working group. Joe, as a segue to anything you have to add at this point, item four is editor's comments.

4. Editor

Joe D: Let me just say that clearly. What’s going to happen is that formally there are two votes, one of which as a WG member you vote and say yes “I approve this” WRT sending it to IEEE or not. Then, if you ballot the standard itself you have a vote there as well. So, that will be some time next year. The reason I'm giving everybody a heads-up is that that the formal vote needs to incur at least 30 days before it gets passed to the IEEE, so people hopefully have their membership status in shape etc. As for the draft standard itself, the main thing that I'd have people look for is, if you look at it you'll notice the syntax shows up in red now. Matan, we were finally able to get that approved, you can see things now that should jump out in red. Therefore, if it is in red it means its mandatory, its required, you must do it that way, it's a literal character and if I have mis-applied that and it should not be that way then please let me know. Also, if I've missed some places, for example if I've got a semi-colon in a regular font that should be shown in a red bold, let me know that too. That’s relative to syntax. Tthe bigger part is we know that the new material has not been thoroughly cross-checked against the existing one to our satisfaction, meaning that Andy and I both looked at it once but we want some other people to look at it. Please, do let us know if there are any inconsistencies, or obvious redundancies or duplications with the new material especially relative to messages, sequences and the refection clauses. That’s everything I wanted to point out.

5. Other business

Andy: This is optional for anyone on the call to raise any questions for discussion about anything really. In particular, about getting the final balloted version of the LRM together. Any technical issues at this point?

Joe: For those of you that are doing a review, if you want to see what’s different between draft two and draft three, in the issue list if you look at the filter 16???? verification that’s all the existing material that the 1.0 version that has not been verified yet, that we did at some point in time, there are roughly 21 that are stilled carried over from draft one which haven't been verified yet. And, there’s an additional 21 from draft two that are new that need to be verified. So, 42 total.

Andy: Okay. So, if I need to, I can email the owners of the issues.

Please email rollcall@ieee1647.org.

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 November 12^th at 9 am PST (1700 UTC). Are there any conflicts??

Joe D: Will this be the formal vote meeting if we resolve everything by then?

Andy: I don't think so. If we get everything done by the end of this month, it is likely to be the December meeting.

8. Adjourn

* Solicit motion to adjourn. – Darren Galpin

* Ask for second. – Serrie Chapman

* Adjourn meeting

9. Action Items

* Matan will open an issue to add untyped description to basic types section of LRM