|
|
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
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.
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
Two
outstanding issues to be resolved (analysis)
These
two are marked as "work-in-progress"
Three
issues actually: 677, 687, 690
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.
|