IEEE P1647 Header
Home
About
Membership
Patent related
Mail Archive
Minutes
Next Agenda
Downloads
Issue Tracking



Meeting 33 Minutes

Teleconference, September 10th, 2007

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

Attendees

  • Voting members

    • Yaron Kashai

    • Joe Hupcey

    • Darren Galpin

    • Andrew Piziali

  • Non-voting members

    • Joe Daniels

    • Michael McNamara

    • Mike Stellfox

    • Cristian Amitroaie

    • Sandeep Desai

    • Matan Vax

1. Call to Order

Call to order on September 10th 2007 at 9 am PDT
Andrew reminded members to mail a message to "rollcall@ieee1647.org" in order to record their meeting attendance

2. Approval of Meeting 32 Minutes

Solicit motion to approve the minutes

  • Darren made the motion

  • Yaron seconded the motion

  • No discussion of minutes and no objections.

Matan: You need attend three out of the past four meetings but sometimes it is not possible to attend all meetings. If you miss two meetings in a row you loose your voting rights for the quarter.

Andy: Only if you don't send an email message to the reflector to discuss an agenda or minutes item.

Matan: OK.

  • Motion passed

3. Status Update

Action Items From Previous Meeting

  • Andy: Mail a reminder to WG to mail roll call message! done

  • Andy: Consider annex for sequences. open

  • Andy: Assess FP demand and its schedule consequences. postponed FP

  • Andy: Plan September 10, 17 and 24 meetings. done

  • Joe H.: Provide floating point (aka “real data type”) technical excerpt from Specman 6.1. done

Review Status

  • 187 issues have been posted for the seven clauses that have been posted

  • 6 new issues have been opened since the last meeting

  • 58 issues have been reviewed and assigned to the editor for changes:

    • 21 sequences

    • 14 reflection

    • 11 method ports

    • 5 constant fields

    • 3 encapsulation

    • 2 messaging

    • 1 name spaces

  • 49 issues have been assigned to task forces but not yet evaluated for editing changes

  • Task Force Chairs Reports

    • Constant Fields (Stylianos Diamantidis)

      • Andrew provided report in Stylianos' absence

      • Issue 682 is now resolved

      • Matan will update the issue comments

      • Next 1.2 draft to be published

    • Encapsulation and Name Spaces (Darren Galpin)

      • All open issues have been resolved

      • A couple of non-encapsulation issues were also submitted and reviewed

      • Draft 1.2 of encapsulation and name spaces published for review

      • If you opened issues on one or both of these clauses, please review the second draft

    • Messaging (Mark Strickland)

      • Andrew provided report in Mark's absence

      • Draft 1.2 published for review

      • If you opened issues on one or both of these clauses, please review the second draft

    • Method Ports (Matan Vax)

      • Two outstanding issues to be resolved (analysis)

      • These two are marked as "work-in-progress"

      • Three issues actually: 677, 687, 690

    • Reflection (Henry Von Bank)

      • Andrew provided report in Henry's absence

      • Three remaining "Assigned to TF" issues

      • Darren will close one of the remaining issues

    • Sequences (Cristian Amitroaie)

      • Cristian: Nothing new since the last meeting since I have not had time to work on it

      • Andy: What's your expectations?

      • Christian: some of them Matan said he would forward to editor. I will attempt to talk to him this week to clean up.

      • Andy: Joe D - that would be the last clause behind Reflection?

      • Joe D.: Yes.

      • Andy: Any other comment on clauses or second drafts? Second draft is one before final integrated doc for LRM.

      • Nothing ...

      • Andy: Plan for going forward - some second drafts still to be published. Then need to integrate docs for LRM for October review. Then, ballot doc after. Any questions on where we are or where we are going?

      • Nothing …

Plan of Action

Andy :

  • Second draft of constant fields, method ports, reflection and sequences to be published

  • Followed by full-up LRM draft publication

  • October review

4. Editor

Joe Daniels

  • The gist is that most of the material is out for review

  • Constant fields this week

  • Method ports this week or next

  • Reflection issues need to be moved to his queue

  • Sequences

    • Informative annex discussion

    • Joe thinks that a 6-7 page document would be useful

    • Joe needs a first draft by month end

    • The current sequence/item/BFM diagram is at a very high level

    • Matan: We do need some background information for the sequences API.

    • Matan: There are two diagrams: one a static relationship diagram and the other a more detailed runtime flow.

    • The consensus is that we should use both the static and dynamic diagrams

    • Discuss this solution during the two technical meetings (9/17 and 24)

  • Discussion

    • Joe D — Most relevant data already heard. Most material out for review except constant fields (publish later this week), method ports (possibly later this week, certainly this month), Reflection (this month), Sequences depends on when issues get assigned to editor. Andy mentioned an informed annex for sequences, but I don't recall any resolution on this action?

    • Andy — Cristian mentioned this last time. If we pare down the sequences doc, we lose direction to user on how sequences are used. For example, the flow of the sequence driver. One way would be to move material into an informative annex. Joe and I have not talked about it, but could discuss in work group whether we do this whether we let user find other sources, or whether we do annex.

    • Joe — I'd like input here.

    • Andy — Cristian, what do you think?

    • Cristian — Some cases would be useful. But who would do that? Most probably someone from Cadence should do that, as some of it is about architecture. It affects API, hook methods, overriding hook methods. These hook methods are called in a specific flow in a specific moment, and these are essential for a complete verification of the architecture. For example, when do(), mid_do() are called and executed. But the LRM is not for the user to understand, but is a formal description.

    • Andy — The LRM is aimed at implementers, not users. We provide annexes for additional extra information.

    • Cristian — For me I could say it is necessary to know when these things for implementation. If I don't do these things, I could change the implementation. I would expect to see something. I can review, give some feedback. I can list some of the APIs I have reservations about which are not well defined.

    • Andy — Joe D, how do you think we should receive?

    • Joe D — If anyone were to look at the load order annex and say could we do something similar for semantics, then it would be a reasonable approach. I would need to see a first draft at the end of this month. Needs to be ten pages or less, and could I see it in three works. If not possible, perhaps Cadence or someone else could put out a more informational piece that would be beneficial.

    • Matan — Cristian referred to a diagram we have in the sequences doc which deals with the high level flow of a transaction request from the sequences through to the BFM via the drivers. This diagram is in no way internal implementation. Cristian is right: the APIs without the flow is not enough to say what the APIs and hooks do and when. It would be a easy enough and a good step to include that diagram in the LRM in the annex or main chapter. The diagram is in pretty good shape it shouldn't require much work.

    • Andy — perhaps the diagram could serve as the vehicle to build description around for flow and APIs. There was originally a UML diagram in the document, but this diagram is not UML.

    • Matan — the diagram describes static relations between the driver and sequence. Cristian was referring to more detailed diagram describing run time flow on the driver unit and how it delegates things to the right sequence, things which are relevance.

    • Andy: Is run time diagram currently included in clause?

    • Matan/Christian — No.

    • Andy — That one should be included in annex?

    • Matan — Yes, but not necessarily in the annex. The information is not in any way a tutorial. It defines the basic algorithm of the flow. It could be described in a verbal manner, but the diagram is more satisfactory.

    • Andy — so have a paragraph introducing sequences, and include diagrams in a brief way, then do away with informative annex. Does that sound OK Joe?

    • Joe — Fine.

    • Andy — Do you have the diagrams Joe?

    • Joe — I don't know. We'll need to talk about that.

    • Andy — Any comments from anyone else about annex and diagram?

    • Cristian — I think it is obvious to describe what is the definition of a pattern. We don't have a language construct here we need the diagram.

    • Matan — we have another in messages with static and dynamic flow. We describe some things verbally. The diagrams are in the source, and is in the PDF is in the 5.18.3 and 5.18.4 do item flow in push and pull mode. (erm_sequences_061205.pdf)

    • Andy — Joe, we'll talk afterwards about that.

    • Joe — we can discuss this and get it in front of people in the next meetings.

    • Andy — Christian, a reminder that the next couple of meetings are to discuss technical issues. We could discuss whether these diagrams settle the issues. Any further issues/questions, send them to the reflector.

    • Matan — These diagrams fit more at the end rather than the beginning because the API is described statically. Perhaps it makes more sense to do this.

    • Joe Daniels — That makes sense.

    • Andy — We'll discuss this more next meeting. I'll send out a note for people to review the original Cadence source document. Any other editor issues?

    • Joe Daniels — No. We need to see materials by the end of the month to hit the review in October and ballot end of this year.

    • Andy — We are on track if we get the issues updated, primarily sequences.

    • Joe Daniels — Finally found diagrams looks good, should be included, need to decide where to place them. Document all calls for changes.

5 . Other Business

6. Call for Essential Patents

Please review the mandatory slides posted.

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.

An essential patent is a patent that would be infringed if it were not licensed or transferred to the IEEE in order to file it legally as standard. So, if people leave with any claims that are essential patent claims they should meet with the work group and take a look at the posted slides for more information on the subject.

7. Next Meeting

  • September 17 at 9 am PDT (1600 UTC) specific issue review meeting. We will review issues in detail. Another meeting a week later. If you can't call in, please email to reflector on agenda or issue in minutes to retain your voting rights.

  • September 24 at 9 am PDT (1600 UTC) specific issue review meeting

8. Adjourn

Andy solicited a motion to adjourn.

Michael McNamara made a motion to adjourn.

Matan seconded.

Meeting adjourned.



IEEE/SA home
IEEE Standards Association
DASC Home
Design Automation Standards Committee
VLSG Home
Verification Language Study Group
The 1647  PAR
Project Authorization Form




(Updated Tue Sep 11 15:16:59 CDT 2007)