Meeting 9 Minutes

Teleconference, January 24th, 2005
A quorum of 9 out of 13 voting members present.
Attendance is noted on the web site roster.

1. Call to order

Meeting was called to order at 09:02 PST/16:02 GMT.

2. Approval of minutes from meeting 8

Darren Galpin moves to approve the minutes.
Andy Piziali seconds.
No objections/abstainers. The motion to approve the minutes was carried.

3. Review Keywords Ballot Results (Language TF)

The policy for moving forward on this has been decided from the ballot and was concluded one week ago. For the benefit of any others who are not aware of the outcome it is as follows:

We had 17 eligible voters and 16 responses (94.1% participation). Which is acceptable for the standard associations rules.
The distribution of votes was as follows:
6 __ (1) keywords in e are not reserved (per section 2.1)
2 __ (2) all keywords in e are reserved names (per section 2.2)
9 __ (3) all key-phrases in e are reserved (per section 2.3)
1 __ (4) some selected keywords are reserved (per section 2.4)
1 __ (4) abstain (chair - should only need to vote in case of a tie)

The selected strategy, therefore is the one outlined in section 2.3 of the document created by Cristian and the basic language task force.

Thank-you to all who voted and especially Cristian, Chris and the Basic Language TF for all that took place in the background to produce the proposal.

Whilst this process was underway some people were giving some thought towards a more elegant solution which would be less restrictive for the parser and the language itself. This work is still on-going so I think we should remain open minded and should a better proposal be put in front of the WG then it should also be considered if only as a possible future enhancement.

No comments.

4. A Plan to advance technical Work

Yaron : I think everyone is aware that we slowed down over the holidays due to personal commitments, however now we really need to make progress in order to hit our deadline of getting the draft ballot in by September and at the latest for the end of the year. There are two things that we need to focus on:

1) Providing all the technical data – this should be in by June so that its finished before the summer slowdown. The TF’s need to engage within their groups and plan ahead for this
2) Editorial work – we are attempting to engage another editor under contract, called Joe Daniels to supplement Ron, our current overworked volunteer. Joe is asked to provide a short introduction

Joe : This is the 4th standardization committee documentation I've worked on, including both versions of Verilog. I will need to use you all and Yaron to drive me in the right direction to get this ready. I do know quite a lot about the IEEE process but an example of the help I may need is for example – there are many examples in the current LRM – they may need to be taken out so I may need help to take these out or perhaps rewrite them.

Joe: Yaron – when we're saying it's a deadline for June – is that for June the 1st or June the 31st? – Personally I believe we would be better off aiming for June 1st.

Yaron : June 1st sounds good

Joe : I suggest this as there is a lot of downtime after this point and normally quite a heavy workload in June before the summer holidays.

Andy Piziali : while most of the work goes into reviewing the material, is this a good time to introduce extensions to the language?

Mac : In my experience, it is best to document the standard and focus on JUST that particular activity. When you start looking into new additions to the language it becomes more difficult, risking that we will fail to even document the de-facto by June. There will be opportunities to extend the language beyond the first draft. I would suggest just working toward documenting the de-facto.

Yaron : Yes I trust you on this
Mac : At this point in time even getting ready for a de-facto release on June 1st is a push. Normally the first revision is behind what has been happening within the language by a good couple of years. We need to make a conscious decision to work toward a de-facto only as in my experience it will still take all of the time just to clean this up!

Andy : that was my hunch as well. I am quite happy to work toward cleaning it up in future revisions and adding any future changes in at a later time.

Joe : To expand – as a proposal to this working Group – You need to set a timeline of 1 month or maybe 2 weeks from this date in which time anything that you want included in the first revision which is not part of the de-facto needs to be known about. Due to the time limitations this should be a ’this is how it looks’ with no substantial redrafting needed for it.

Yaron : Andy – if you feel or any of the working group feel that anything else is required with the TF in mind, then prepare a proposal to put in front of the WG so that we can then decide whether or not to put it into the first draft, or table it for revision 1.1.

Matan : How does the WG continue after the first draft is released?

Yaron : once the draft is ready it is provided to the balloting group, which is a group of individuals in our case. These individuals will come back with rejections that need to be addressed and settled as much as possible. Finally, the draft should pass the ballot and RevCom should recommend to accept the standard it should approve it as a Rev 1 standard. In parallel, the WG can continue working on a revision. We will probably need to push a new PAR through for the revision process.

Mac : The WG continues to serve as a body to respond to users who are confused by the Rev1. It should exist for at least another year. It may create another PAR and proceed as mentioned to revise the standards or produce a new side standard. With Verilog we did one and kept revising it. I suggest we get this de-facto done now and then clarify things in the next draft.

Joe : You'll also find that in the Ballot process you'll find some members within the community that we haven't hit or thought of for this revision. The next revision may be affected by the ballot process and from when we start talking about the process it will occur 2/3 years later.

Yaron: In summary, the intention is to step up the work on the technical side and get all inputs in as there's a lot of editing in the backend of this. I will be contacting the various TF leads in order to chase this up.

5. Task force updates

Floor open for task force updates:

Matan – TF3 - AOP, introducing the import order issue

Brief Outline:
AOP features of e include the ability to extend structs, add to the behavior of a method, macro instructions etc. All of these make the order of definition in e important semantically. The order can be viewed as ‘a series of additions to existing definitions’, which needs to be consistent between implementations in order for programs to be analyzed the same way. The order in which to load modules is crucial for the behavior. This all needs to be defined accurately. There are several related issues, such as forward references, which could make definitions dependent on one another. It all needs to be accurately defined for a standard by which different implementations of e can be equivalent.
The AOP TF already has a draft of the document ready – we hope to discuss it and bring it to the WG for further comments. So far there are no competing alternatives – just the documentation of the issue as it is at present. This will have to be included into the LRM once the issue is decided.

Pitchu - TF8 - Foreign access
We didn't have much activity, except for validating the fixes to the issues that were included in draft 0.2. Since the page numbers have changed between the drafts, validating the fixes takes time. Other than that Brett has joined the TF in the last month. In the next couple of weeks we will be reviewing all our outstanding issues.

Yaron : are there any sections of the LRM pending for your review?

Pitchu : No not really – there are some issues regarding interfaces, beyond the current LRM

Andy : What's happening with the chapters that have no TF assigned to them such as the e libraries and synthesis ?

Yaron : e libraries is a real issue for now – we'll need to bring it up in the coordination meeting. Synthesis we can safely defer as its nor needed for the first revision of the draft but the libraries we really do need to look into!

Matan : There is also an issue with the reflection API, which may be viewed as a library though it is currently with the AOP TF. Should we consider it as a library component, given all the other issues pending for the AOP TF?

Yaron : Reflection is not part of the current spec, we may decide to defer it, especially given the June time line.

Matan : A document describing the reflection API is already available – so really it's a matter of the decision as opposed to there being a lot of technical work to invest.

Yaron : Ok – lets consider it once we address the library stuff. So far the ongoing AOP topics are of higher priority.

6. Other Business

Yaron: I need to address the update of our roster. We need to provide an annual update to the standards organization of all the active members registered. Hopefully everyone on the call is registered with the WG and is current in their DASC and SA memberships.
Some members have not participated in calls or e-mails throughout 2004. I will send out a polite e-mail to those members asking if they are still interested – anyone not interested or who doesn't respond will become inactive and will be removed from this years roster. When this is done I will provide DASC with the necessary list.
Attendance and being a member of this list is important as IEEE will cover you for any litigation issues relating to any work carried out when related to the WG – so it works in your favor.

Joe : I propose a new item re. the Schedule: since we want TF work to be done by June 1st. we should request that all technical matters that have to be included in the first draft are listed by the next meeting. This way we would have identified all Outstanding issues.

Yaron : I'll follow up with the TF leads to produce the list of technical items for inclusion. If any other members wish to contribute items then please contact me or send to the reflector.

Avi : the whole issue of the C interface being not part of the spec – should be discussed – that's one issue that does need to be taken care of.

Yaron : yes – we will need to add it to the list.

Joe: In reality there's only 3 months to get things written and to make the LRM make sense. Although people count for 13 weeks through the summer – due to commitments there are generally only 3 or 4 working ones.

Yaron : Any other business?

8. Patent policy

The chair has issued a call for essential patents, in compliance with current IEEE/SA PatCom guidelines. The WG members are advised to review the call for essential patents and the patent related slide presentation posted on the web site .

9. Next meeting

Please remember to send e-mail to rollcall@ieee1647.org so that your attendance on this call is recorded.

• Please DON'T send these e-mails to the reflector
• Use the e-mail address you registered with

Next meeting is set to Monday, February 28th at 9:00 AM pacific (same time as today's meeting).

10. Adjourn

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 Wed Oct 11 16:18:40 PDT 2006)