Phone Conference P1450

Meeting discussion

Draft D15

This draft version is now complete. All agreed changes have been made in the document. The working group has the action item to review all the changes to see if changes are as agreed to (identified with change bars). Will vote to ratify these changes at the 4/10 meeting.

Lockstep (issue CTL-1)

The 1450.6 working group has raised concern over the definition of Lockstep. The working group assigned Greg the AI to work with 1450.6 to identify the issues and see what can be done to reconcile them.

Pattern Tiling (DM3 in D15 review resolution)

There was an issue left open from D15 with regard to the Fixed, Wait, Extend statements used for pattern tiling. Jason had expressed a desire to provide additional input. Jason said that he has reviewed it in D15 and is now comfortable with it as defined. The issue will be removed from the D16 issues list and will be marked resolved in D15.

Enums as constants (DM-1)

As currently defined in D15, enum values in a SignalVariableEnum can only be used by SignalVariables of that enum type. It has been requested to allow these enums to be used as constants anywhere that the variables block is in scope. i.e., should be OK to say "V {group='enumval';}". The working group's response was that this was how they would expect it to be used. The working group agreed to change the wording to so indicate. Tony has the AI to make the change in D16. Note-1: This should only be allowed when the size of the group is equal to the size of the enum. Note-2: This should also apply to integer enums.

Constant Integer Expressions (DM-2)

Now that integer constants can be defined, it has been requested to be able to use expressions that contain constants anywhere in STIL that a bare integer is allowed. The working group agreed that an expression that can be completely resolved at parse time should be allowed anywhere that a bare integer can be used. Tony has the AI to update D16.

Fail Data and the X statement (GR-1)

Several people have raised concern over the current definition of fail feedback using the X statement - CTL working group, Gordon Robinson, Jason. The main concern seems to be that it is too verbose. Jason's suggestion was to have a simple statement like "FailReport { (LABEL OFFSET PIN;)* }". Jason has the AI to contact the parties interested in this issue and start a dialog on this issue. We will use one of our future dot1 meetings to discuss this issue. The people suggested for this dialog are: Jason Doege, Doug Sprague, Rohit Kapur, Gordon Robinson, Paul Reuter, Tom Bartelstein.

Ballot plans

We are getting close to completing all of the open issues with p1450.1. We discussed the alternatives as to where to go next. The options discussed were:

a) wrap things up and start the IEEE ballot process;

b) allow a period of time (6 to 12 months) for users to build applications.

Although approach (b) would allow for an easier process for making adjustments to the spec, there was a definite sense from the working group is that getting "official" ballot approval (approach (a)) is a necessary step for many users to start doing development. The working group agreed to review their needs and be prepared to make a decision at the 4/10 meeting.

Meeting adjourned at 11:00 PST.