Wednesday, 18 September 2000, 1:00 PM, Autotestcon 2000 conference, Disneyland Hotel, Anaheim, California.
Nathan Berg, Agilent Technolgies
Robert Canik, National Instruments
Joe Czapski, AutoMeasure (Meeting Chair, TC-8 Co-Chair)
Dr. Philip J. Fleming, P.J. Fleming & Associates
Stephen Greer, Agilent Technologies
Andrew Thomson, National Instruments
Vanessa Trujillo, National Instruments
Ron Wolfe, National Instruments
David Ringle, IEEE Standards Association Staff (on speaker-phone)
Denise Scozzafava, IEEE Standards Association Staff (on speaker-phone)
Editor's Note: In the following meeting minutes, statements attributed to persons are not exact quotes but brief approximations of what was said.
The Chair read his prepared document entitled "Welcome and Plan of Action."
Robert Canik read his prepared document entitled "History of Higher Performance 488.1 Standardization Effort."
Chair - In addition to what you read, Robert, in 1992 CEC made a high-speed 488 proposal at a TC-8 meeting, and in 1993 National Instruments made another high-speed 488 proposal at a TC-8 meeting. So, the committee work on this project actually began in 1992.
Canik - That's right. I included just the history of the Working Group in what I prepared.
Steve Greer - The August 1997 IEC meeting you listed, Robert, was actually a September 1997 DKE meeting in Germany.
The Chair read his prepared document entitled "Summary of Complaints and Responses."
In this 25-minute discussion, the first complaint "Biased Working Group Chair" was discussed, and the remainder of the discussion dealt with general complaints of lack of adequate participation in the working group, ignoring others concerns, and a flawed process being followed.
Nathan Berg - In the Aug. '95 TC-8 meeting, TC-8 told the P488.1 working group to resolve the issue of having a non-neutral chair. The working group failed to resolve the issue, though they were explicitly directed to do so. Two levels of conflict: between CEC & NI, and NI being both the chair and major proponent of the proposal.
Canik - The working group did resolve the issue. We asked for volunteers and encouraged potential volunteers over a few months. Then the working group decided that having a chair from NI was no longer an issue because of the CEC-NI agreement.
Ron Wolfe - The PAR was approved to pursue the proposal. The issue was resolved, and it was discussed adequately. It is common for companies proposing changes to be involved in the process.
Greer - The issue was ignored, not resolved. Other working groups have worked hard to find neutral chairs.
Wolfe - Can you, Steve, explain just how the issue was ignored? It was not ignored - meeting minutes show discussion. Bob Cram (TC-8 Chair at the time) worked hard to find others to be chair.
Phil Fleming - We are judged by perception of the quality of our work. The list of people who attended the WG meeting in Feb. '96 looks suspicious. 4 out of 7 attendees are from NI. Why didn't others come to Texas? Because they didn't care, they didn't think the revision proposal was worth participating in. A client of mine (whom I cannot name) expressed early on that it was not worthwhile to pursue. Someone has antagonized European industry members.
Canik - Again, nothing was ignored by the working group.
Fleming - The working group process was flawed. Why do others in the industry feel that they were left out? Some think they were essentially "run over."
Wolfe - What can we do about other people's perceptions? Should that be our concern? Proper procedure was followed.
The Chair asked for discussion on patent issues. Phil Fleming made a motion that the item be dropped from the agenda as having been resolved. Hearing no objections, the Chair dropped the item from the agenda.
The Chair read from Phil Fleming's negative ballot comment on this issue. Robert Canik read from his rebuttal to that comment. Discussion followed:
Canik - The PAR authorized revision of 488.1. The WG could not consider anything else. This data streaming protocol is nothing new -- it's the same as used by SCSI and VME.
Greer - I'm speaking as the representative of the IEC. The IEC wants HS-488 to have a different standard number. The WG could have asked at any point to change the number on the PAR.
Wolfe - So you're saying that, as far as the IEC is concerned, this high-speed proposal is technically sound but should just have a different number.
Fleming - NI has every right to develop and market a product, and should do so. But everybody says "just don't change 488."
Wolfe - Who is "everybody"?
Fleming - I can't give you a list.
Wolfe - This is not open for debate. This is a revision of IEEE-488.1. It's in the balloting stage now.
Fleming - Again, market your product, just leave 488 alone.
Vanessa Trujillo - The standard number is not an issue at this point in the standardization process. It's 488.1.
Wolfe - Our customers see value in keeping the same number. Users see value in enhancing the existing standard.
Phil Fleming handed the Chair a June 1998 press release from the DKE on the subject. The Chair said we could read it out loud at the end of the meeting.
The Chair read from Robin Steele's negative ballot comment on this issue. Discussion followed:
Canik - Issue was discussed at TC-8 meeting before PAR approved. TC-8 approved PAR because there was evidence of a demand for high speed. This issue was resolved.
Greer - IEC WG3's opinion is that 1 or 2 octaves is not enough speed improvement to make a change. 10 or 100 times is what's needed.
Wolfe - Enhancing existing standard has value (vs. other solutions). This is not the only interface bus project. The speed increase is fine for this project. Start another standards project if you want a higher speed increase.
Berg - Complexity jeopardizes the entire spec. This proposal risks all of IEEE-488 for just a modest speed increase.
Trujillo - TC-8 should make sure it works technically. That's what matters.
Berg - This proposal is not technically sound.
Canik - The goal is backward compatibility. It doesn't complicate the spec. because it's fully compatible with existing instruments. User's don't need to worry about its effects on 488.
The Chair read from Robin Steele's negative ballot comment on this issue. Discussion followed:
Canik - Alternative proposals were considered from CEC and Chris McKenna - even though the McKenna proposal was submitted after the deadline. We have to balance moving forward vs. considering all ideas that come up. There have to be deadlines.
Fleming - The perception is: if this were done effectively, we would not have things floating in the background. The DKE believes it was ignored by the working group
Wolfe - We considered alternatives. How can we change perception? Please tell the DKE that they were considered, even voted on by the WG.
Canik - We can't address perceptions. We can't do anything about that.
Greer - IEC WG-3 is now considering a high-speed proposal submitted to the DKE. [We may ultimately get two different approved standards for high-speed 488, one the IEEE's and one the IEC's.]
The Chair read from Robin Steele's negative ballot comment on this issue. Discussion followed:
Greer - The forward to IEEE Std. 488.1 mentions that there was close cooperation with the IEC on the development of the standard. IEC WG-3 was active in previous revisions, such as in 1987. The IEEE and IEC worked well together in making compromises. The WG-3 feels that the IEEE has abandoned it.
Canik - Issue was brought up at NesCom and TC-8, but the PAR was still approved. It was discussed and voted on. Why debate it again?
Phil Fleming referred to his previously submitted press release from the DKE for their position on this issue.
The Chair read from Phil Fleming's negative ballot comment on this issue. Robert Canik read from his rebuttal to that comment. Discussion followed:
Fleming - What is cost effective? Extra circuitry would add considerably to the cost of implementation. Why wouldn't it add cost?
Canik - NI sells a chip on the open market which is cost effective. It's actually cheaper than older non-high-speed 488 chips.
Fleming - My clients have trouble believing the response. They would appreciate a more specific response if possible. They want details.
Canik - Should a standards body decide cost effectiveness issues? The marketplace should decide.
Trujillo - Technical issues need to be resolved on an individual basis. General cost and complexity is not a technical issue
Fleming - We need to address the root cause, "Why are we doing this?".
Berg - Cost may not be a technical issue, but it's an issue.
Steve Greer read WG3's concern on this issue, saying that excessive complexity puts system reliability and compatibility at risk.
Wolfe - Our job is to deal with complexity and build products which meet the needs of our more sophisticated users. We must step up to that challenge. Should we be afraid of complexity? More complexity is a general trend in the industry.
Berg - First need is reliability over speed. Customers want reliability.
Canik - We should focus on specific problems. How is this standard unreliable? The issue of complexity is one of perception.
Chair - More complex solutions are more likely to fail, as a general rule.
Group agreed that each topic would be started by the Chair reading a comment from a negative ballot, rather than first asking if anyone wants to start the topic.
The Chair read from David Clemens's negative ballot comment on this issue. Robert Canik read from his rebuttal to that comment. Discussion followed:
Berg - In reality, customers tend to just use cables of any length and now they need to known their lengths. Interfaces don't usually require users to known and enter cable lengths. Customers even ignored the 15 to 20 meter limit, sometimes running 100 meters. It just worked. 488 is that robust.
Wolfe - That violates the original spec. It's intended that they consider and abide by the 15 to 20 meter cable length limit.
Fleming - Problem of mixing marketing issues with good engineering practice. Users are very creative. Original performance specification was under worst case conditions. Same bus loading doesn't get higher speed performance with HS488. Perception exists that the performance is not really there. HS488 is not a worst case spec.
Canik - McKeena/ines proposal also requires cable length entry. Phil Fleming voted positive on that proposal in the working group.
Fleming - I looked at the physics of the HS488 proposal for performance. McKeena proposal allows changes to loading and delays to enhance performance of original 488.1 without added complexity. It's a better proposal.
Canik - Both proposals require knowing cable lengths.
Fleming - Give users the best chance to configure a reliable system.
The Chair read from Nathan Berg's negative ballot comment on this issue. Discussion followed:
Berg - The second point was resolved by a change in 7.2.1-3 System Requirements of the word "should" to "shall." The rebuttal from Robert Canik agreed to this change. The first point on interrupting a non-interlaced handshake remains.
Canik - Controller must be a listener to take control synchronously. We need a clarification on "shadow handshaking."
Berg - Controller can be in one of three situations - listening, talking, or not involved.
Andrew Thomson - Currently the controller must be involved in the handshake.
Canik - Current standard doesn't address shadow handshaking so HS488 doesn't either. I can document the three cases and show how the state machines behave.
Nathan Berg stated that shadow handshaking is different from being a listener in the current standard. Robert Canik stated that shadow handshaking can only be accomplished by being a listener.
The Chair asked Nathan Berg and Robert Canik to discuss this matter by e-mail and/or phone and post an agreed-upon technical answer on the P488.1 website. The Chair asked if the controller can interrupt an instrument-to-instrument high-speed data transfer without corrupting the data.
The Chair asked the group to address the other part of this topic: does higher speed cause more susceptibility to noise, crosstalk, and data errors? No one had anything to say on the issue, so we moved on.
The chair read from Nathan Berg's negative ballot comment on this issue. Robert Canik read from his rebuttal to that comment. Discussion followed:
Greer - Section 5.7 of IEEE 488.1 was added in 1987. It does not add any new requirements. I was there. We were careful that any device complying to the original spec. would comply with the 1987 spec.
Fleming - I talked to others present at the writing of 5.7. They say you can't possibly add undefined commands without a risk.
Canik - One objective is to not break anything. Working group felt is was a safe risk. How can you improve the standard at all if you can't add any commands? I don't think a rigid restriction exists.
Berg - It is a good goal to have backwards compatibility, but this draft does not meet that objective.
Chair - Would be nice to have statement about how likely a crazy device might exist.
Fleming - Unknown risk. Impossible to really know. They will exist. We have to acknowledge the risk.
Canik - Very small probability, and can turn off HS488, preventing any sending of CF messages.
Berg - DKE proposal does allow enhancements without new ATN-true commands.
Canik - DKE proposal does not address how to communicate cable lengths throughout the system. A new command is necessary.
Thomson - McKeena proposal relies on devices to meet certain requirements.
Fleming - DKE proposal is not McKeena's proposal.
Canik - Working group was only sent McKeena proposal. It never saw the DKE proposal.
Wolfe - This proposal is an optional feature. It can be turned off in the presence of any problems. 1987 revision closed some holes in the spec., and this can also be done with HS488. Some devices don't even meet 488.1 and users still need to use them.
Fleming - The root question is "Why are we doing this?". Just don't call it 488.
Wolfe - PAR explains why.
Fleming - The world is moving beyond what HS488 supplies, e.g. USB.
Trujillo - USB doesn't always fits the needs of users. They need improvements to existing systems.
Thomson - Market choice of interface is not an issue for standardization.
Chair - We have a difference of opinion on whether 5.7 prevents devices from doing strange things when receiving an undefined command.
Canik - Issue of 5.7 was heavily debated. WG thought there was minimal risk, and the benfits outweigh the risk.
Fleming - There is a risk. Ability to quantify the risk is difficult.
Berg - The WG minutes do no show any indication of a discussion of 5.7.
Canik - Minutes reflect procedural topics and changes to the draft, but not all the technical discussions. We made notes on the spec. document.
Wolfe - Can't I, as a user, just choose not to turn off HS488 and eliminate the risk?
Fleming - Yes. So why have high speed at all? Why have it if you can just turn it off?
Wolfe - Lots of devices shipped today violate 488.1. So, even the existing standard has risk. HS-488 risk is small and a mode exists where risk is zero -- you can shut off high-speed.
Berg - Does draft spec. provide a way to disable HS488?
Canik - Yes.
Chair - Do we all agree that there is some, unknown risk in the introduction of the new command?
Canik - Yes, but I think we agree that it's a small risk.
In the opinion of the Chair, the attendees came to an agreement that there is a small, unknown risk that older instruments will react unfavorably to the new ATN message: CFn to configure cable length and high-speed mode. The 1987 spec. says that a device "shall" handshake an undefined command and "should" ignore the command. It comes down to the definitions "handshake," "shall," and "should." A device that complies with all recommendations of the 1987 spec. will ignore undefined commands and not be affected by CFn.
The Chair read from David Clemens's negative ballot comment on this issue. Discussion followed:
Fleming - Lots of noise from NI on interoperability issue. Most of the hype is marketing. Real issue is the credibility of claims and their validity. IEEE provides a peer review. I want an open presentation of testing that's been done. Visibility is not there.
Canik - What does the IEEE require? What requirements does the IEEE have for this? This is a "chicken and egg" problem. Do you write a standard, then build it after it's approved? Or do you build it first then write the standard? Without a standard, companies do not want to invest effort developing products and testing them.
Fleming - I offer this as Exhibit A (plunks down IEEE Code of Ethics document in front of Robert Canik). There is a responsibility to be open and honest. Need to make issues public to gather input.
Canik - Which results are shared and which are intellectual property? We don't want to embark on a never ending investigation.
Berg - If this were a new standard number there would be no conflict.
Wolfe - What interoperability testing was done in 1975? Vendors built 488 components after the standard was approved. We need a standard before people will design to it. Who is responsible for testing? Is it a requirement of the working group? Why is it an issue this time?
Fleming - No one knows what testing has been done. The unknown aspects of the testing concern people.
Wolfe - Are you talking to NI, TC8, IEEE, or whom?
Fleming - I see this as NI's product.
Chair - Should the rebuttal to this negative comment state that NI has done some testing but won't share its results? Should NI share its results?
Wolfe - I think the rebuttal should state that the IEEE standards process does not require testing prior to approval. NI implemented it in silicon and it works. Problem is that other vendors won't implement HS488 until it is an IEEE standard.
Canik - Is the complaint about interoperability with multiple IC implementations? How do you get someone to do another implementation?
Berg - There are two points. Interoperability with existing instruments, and interoperability with other HS488 implementations. What is the default setting of your controller chip?
Canik - Default setting is off.
Berg - If default setting is disabled, then the "hundreds of thousands of users" claimed are only tests of 488.1 compliance, not HS488, because most probably did not turn on HS488.
Wolfe - Default setting to off shows the zero risk solution does work. I am not at liberty to say which competitors have implemented HS488.
Fleming - This is not a technical issue, but a perception issue of adequate testing. I don't have confidence to recommend HS488 as a well tested, reliable solution.
Canik - What is the IEEE requirement? I have not found anything in IEEE documents saying that testing must be done.
Berg - Given that default is off, rebuttal should not claim hundreds of thousands of systems with HS488.
Chair - Some testing was done by CEC and NI. TC8 rebuttal could either mention this testing, or state that IEEE does not require testing.
Berg - Given theoretical problem with new ATN true command, and the magnitude and importance of this revision, working group or TC8 is under an obligation to do some testing.
Wolfe - (to Nathan Berg and Steve Greer) Your company [Agilent] is the largest test instrument maker in the world. Maybe you should do the testing. Why should NI do it?
Canik - What's enough testing? We could post some data, but someone would say, "no, that's not enough." I could check to see if testing could be shared.
Berg - Anything is better than nothing.
Wolfe - After approval of this revision, if holes are found, the working group comes back and tightens up the standard to eliminate problems. Users find the problems.
Berg - This case is different with the theoretical problem of backward compatibility.
Wolfe - What is liability of NI if they release testing information? It is a very complicated issue.
The Chair opened the floor for discussion on any topic that we wanted to bring up or expand on. No one suggested a topic at first, so the Chair began the first topic.
Chair - This question is for Dave Ringle. Is the complaint that the IEEE should not have let the WG continue with Robert Canik as chair a valid complaint? Should the IEEE administration have stepped in and halted the WG?
Dave Ringle - (over speaker-phone) We at the Standards Assoc. would not have known about the situation. That was a TC-8 decision. They had the responsibility to deal with that issue.
The Chair read the DKE Press Release from June 1998 presented earlier in the meeting by Phil Fleming. The Chair agreed to add the press release to the Web site.
Fleming - What happened to the 1997 ballot?
Canik - There was no ballot in 1997. It was an invitation to a ballot, and not a ballot. At that point there were some problems because the voting pool was unbalanced.
Fleming - Does the voting pool need to be balanced?
(group) - Yes. IEEE has such a rule.
Canik - Marlyn Miner dealt with all the voting pool unbalance issues and conducted the ballots.
Fleming - My customers have the perception that the correct procedures were not followed.
Wolfe - Do you think that the negative publicity and press campaign by opponents of the proposal hurt the perception?
Fleming - [NI employee] Amar Patel did or said things to persons in industry that hurt your perception. Your measurement of success is your perception.
Thomson - Can you give specific examples of things done or said?
Fleming - No, I'm not at liberty.
Thomson - Then how can we address that?
The meeting was adjourned at 5:00 PM.
These minutes were submitted by:
Parts I, II, and III: Andrew Thomson and Joe Czapski.
Part IV: Steve Greer, Andrew Thomson, and Joe Czapski
Part V: Vanessa Trujillo
and were compiled and edited by Joe Czapski, 29 September 2000.