In November 2000, TC-8 formed a subcommittee and gave it the task of reviewing the negative comments from the July 1999 ballot of the proposed High-Speed Revision of the IEEE-488.1 Standard Instrument Bus. This Ballot Review Committee (BRC) examined the points made in the negative comments, decided what changes if any to make in the draft specification, and wrote and rewrote rebuttals.
The membership of the BRC was:
The membership of TC-8 is:
The Negative Balloters, whose negative comments are listed below, were:
The ANSI/IEEE 488.1-1987 standard specifically prohibits the addition of new interface functions. Specifically, the last sentence of ANSI/IEEE 488.1-198 Section 5.1 System Compatibility reads "In order to provide system compatibility a designer shall not introduce new interface functions beyond those designed in Section 2".
The proposed draft violates this statement by adding the CF (Configuration) function as indicated in Table 1 Section 4.1.2.3 Interface function repertoire. The draft standard also adds the SHE and AHE interface functions.
Existing instruments compliant with IEEE 488.1-1987 may face compatibility problems with the new interface functions. No specification exists (nor can logically exist) for prediction of system behavior when the CF, SHE, and AHE functions are encountered with existing implementations. Existing implementations have unknown results when they encounter these new functions.
The CF, SHE, and AHE functions must be removed from the draft standard. This includes "section 4.14 Configuration (CF) interface function."
The statement in the 1987 specification can be read as applying to the users of the standard, not the writers of the standard. If designers heeded the mandate to not introduce new interface functions, then there should be no existing implementations that have a problem. No specific implementation was mentioned that had a problem with these new functions. There is not enough rationale here to support removing the CF, SHE and AHE functions from the draft.
To address concerns about compatibility of the new non-interlocked data transfer mode, we've explicitly added text to the draft that indicates the default condition of an implementation is to have non-interlock data transfer capabilities turned off. There are 3 places in the draft that we find appropriate to remind implementers that defaulting to non-interlocked turned off is a requirement:
Section 4.3.3.7 Source wait for RFD state (SWRS) (pg 28)
Add to the end of the first sentence:
NOTE: The SHE will enter SWRS to initiate a non-interlocked mode of data transfer. SWRS can only be entered if CNCS is false. CNCS can only be false if the controller explicitly issues a CFGn command. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Section 4.4.3.13 Accept non-interlocked configured state (ANCS) (pg 38)
Add to the end of the second paragraph:
NOTE: The AHE will enter ANCS to initiate a non-interlocked mode of data transfer. ANCS can only be entered if NIC is true indicating the SHE is in SNGS. The SHE can only be entered if previously CNCS was false. CNCS can only be false if the controller explicitly issues a CFGn command. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Section 4.14.3.3 Configure not configured state (CNCS) (pg 89)
Add to the end of the last sentence:
NOTE: The CF function exits CNCS only if the controller sends an explicit CFGn message. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Exposing the cable length parameters adds additional complexity to the user and systems integrators. A user adding an instrument to an existing system might very easily forget to update the cable length parameter. Is there a mechanism that can be added to the standard to hide the cable length from the application? This must be added to the standard to remove potential errors.
If this is not possible, then a mechanism needs to be added to ensure that the cable length is correct. System performance and data integrity are dependent on correct definition of cable length.
Finally, if the cable length needs to be added, then a mechanism for communicating with the controlling I/O software needs to be documented. The cable length parameter is a piece of information that is needed by the controlling I/O software. A standard mechanism should be specified for transferring that information to the controlling software.
If the default state of the CF interface function has been specified as FALSE, then the user and/or system integrator is not required to set the cable length parameter unless they want to set CF TRUE.
D. Clemens wrote: "… since the CF interface function adds substantial complexity, it is highly probable that another vendor would create an incompatible version." In the implementations of IEEE-488 available for many years it is possible to set the T1 delay for fast, normal or slow operation. The correct setting is dependent on the cable length and number of devices connected. The IEEE-488.1 standard does not describe how to set this, of course. If more instruments and/or more cable is added it is possible that this setting will need to be changed. The CF interface function and the cable length parameter serve the same purpose as setting T1 "fast". They will be described in the 488.1 standard. That is desirable. Setting a short cable length and forgetting to change it when adding devices is extremely similar to setting "fast T1" and then forgetting to change it when adding devices. CF will be FALSE by default similar to the way T1 delay is "normal" by default. Therefore, the argument that the CF interface function adds substantial complexity is not correct. This complexity already exists in the most widely used implementations, but is currently outside of the scope of the standard.
P. Fleming wrote: "Data integrity … can easily be compromised by simple-minded modifications to system layout. A configuration verification and confirmation methodology must be defined and implemented to solve this problem." S. Lomas makes a similar point.
As mentioned above, if we agree that CF defaults to FALSE then it does not mandate that anyone determine, set, and remember to update cable lengths. If a user takes it upon himself to configure the system for high speed transfer then, it is true, he must remember to update it if cable length is changed. Does this mean that it is the responsibility of the standard to include a confirmation methodology? Consider SCSI, a widely used high speed parallel interface that required termination at the end of a chain of devices. If the termination is missing, or if there are two, the system almost certainly does not work. A separate confirmation methodology was not implemented.
Consider the T1 "fast" setting mentioned above: again, there was no confirmation except that the system worked. Based on these precedents, it is clear that while it might be desirable it is not required that IEEE-488.1 include a confirmation methodology.
Let us make the attempt to consider what could be included as a verification
methodology. The standard could define a pseudo-random sequence (PRS) either
directly or by specifying a generating polynomial. The controller could send a
device specific message to a device to make it receive and check the bytes in
this PRS. The bytes would be sent using the high speed handshake, of course. At
the end of the transmission the controller could query the device to find out if
the sequence was received correctly. The method would have to be defined such
that the device could not "hang" if it missed bytes. The problems with this
suggestion include:
1) added cost to implement
2) Added complexity, possibility of incorrect implementation.
3) Unless the sequence is quite long it will not be possible to confirm a
reasonable byte error rate. For different applications different BER is
acceptable. At 5MB/s to verify to 1e-7 would take several seconds, verifying to
1e-9 would take about 10 minutes.
Although it is reasonable to try to confirm correct operation, verification to the tolerance desired is best left to the application level and should not be required of the 488.1 standard. For the user to do this all he'd need are two computers in the system, one being the controller which sends data to the second, which checks it. It would have to be assumed that when the second computer and the cable leading to it is removed the system will perform at least as well.
To resolve these comments, language should be added to the standard stating that if the high speed handshake is configured, correct operation should be verified on any system layout change. The method for performing such verification is outside the scope of the standard.
We make the following change to the draft:
Section 8.4.3 Cabling configurations (pg 111)
Add to the end of the section:
It is recommended that system communications be verified after cable layout
changes.
Historically, both IEEE 488.1 and IEC 60625-1 has been consistent (identical). This has benefited users by having both standards the same, thus eliminating confusion from regional differences in standard subscriptions in the rest of the world. The IEC through the IEC SC65C/WG3 has indicated that it disapproved of the proposed changes and indicated several serious technical flaws that have not been addressed. It would be highly beneficial to the worldwide users of 488 for the two standards to remain consistent (identical). If this ballot is passed, it will most likely cause instruments to be developed with the IEEE 488 standard to be incompatible with the IEC 60625-1 standard. The working groups must resolve differences and maintain a consistent standard.
This issue of the divergence of the IEEE and IEC versions of this standard has been prominent from the beginning of this revision project. Following is a summary of the interaction between IEEE TC-8 and IEC WG3 in the early stages:
Parliamentary procedure, of informed individuals voting in good faith, separated the IEC and IEEE on this issue. A majority of IEEE TC-8 members and IEEE NesCom members felt that supporters well outnumbered detractors, by enough margin to go ahead with the project, and that supporters' arguments were valid.
Further examining the points you make in your negative comment:
Your major complaint is that approval of this revision will create two divergent standards. Until now, IEEE-488.1 and IEC 60625-1 have been identical, making this a truly international standard, which benefits users worldwide. With divergent standards, you claim, instruments using the IEEE standard may not be compatible with instruments using the IEC standard.
Disagreement between the IEEE and IEC versions is unfortunate. But that's what happens when there is disagreement between two distinct standards bodies. Does TC-8 have to get approval from WG3 before drafting standards? No. We would like to work closely with them and develop standards in harmony. But if after thorough discussion there is disagreement, and we decide that the merits of a standard outweigh the drawbacks of disagreement, we are obliged to go ahead and develop the standard.
In the past, the IEEE has taken the lead in IEEE-488 revisions, and the IEC has followed after the fact. In particular, IEC 60625-2 was rewritten to match IEEE-488.2, and IEC 60625-1 was revised to drop an alternate connector type in order to match IEEE-488.1. Therefore, there is historical precendent for the IEEE taking action in the 488 standards area without prior approval of the IEC.
Another rebuttal to this complaint is that National Instruments's years of development and field use of their HS-488 technology makes it very likely that instruments using high-speed IEEE-488.1 will be fully compatible with instruments using the existing IEC 60625-1 standard. And if for any reason there is concern about compatibility, the user can simply not activate high-speed mode, making things identical to the old 488.1.
Finally, there have been complaints that IEC WG3 members have been ignored when they have brought up technical flaws in the proposed high-speed protocol. But it appears that these issues were made well known to everyone involved. Particularly, Steve Greer made these flaws known to TC-8 members at multiple TC-8 and WG3 meetings in the early stages of the project. The fact is that, rather than ignoring these complaints, a good majority of TC-8 and working group members simply felt that either 1) the flaw did not exist or 2) the probability of the flaw affecting any user was insignificantly small, and the advantages of the technology outweighed its drawbacks.
It is a given that, for such a widely used and accepted international standard such as 488, a thorough, public, and well-documented verification of compatibility with both existing and potential applications be implemented and published. Results of such investigations must also be submitted with ballots of this nature to ensure a thorough examination of potential adverse consequences due to such serious proposed changes.
Has there been sufficient multi-vendor interoperability testing with the proposed standard? I would like to see these results shared in a public forum.
In addition, I would have to believe that any "testing" that may have been completed would not be representative of a true-multivendor solution. Hearsay has it that multiple products from different vendors were shown to be "interoperable". However, all of these products were based on one company’s proprietary implementation. This does not provide evidence that multiple vendors can implement the standard, nor does it provide evidence that other vendors are willing or interested in providing such a complex solution. Further, since the CF interface function adds substantial complexity, it is highly probable that another vendor would create an incompatible version. This would cause user confusion, frustration, and potentially serious application results.
Your comment is, essentially, that you are not going to vote for this proposed high-speed revision without being provided thorough documentation of compatibility testing. The testing must be with many different brands and types of instruments that use IEEE-488. Preferably the testing should also be with high-speed control electronics (integrated circuit and/or circuit board) made by different companies. You argue that the >20 year history of IEEE-488, the number of existing instruments and current users, and the complexity of these high-speed changes make documented compatibility testing mandatory. In further discussions, you (N. Berg) have said that it is the responsibility of the Working Group (WG), TC-8, and the IEEE to perform this testing before revising the standard.
However, the balloters will NOT receive any documentation of compatibility testing. Neither the WG volunteers, TC-8 volunteers, nor IEEE members and staff have the resources or time to perform such testing. And there is no IEEE requirement that a proposed revision to a standard be compatibility-tested before balloting.
That said, as we all know, this revision is based on the National Instruments (NI) HS-488 product. The first version of this product was released by NI approximately two years prior to the Working Group's first meeting in 1995. Meeting minutes show that one reason TC-8 and the WG voted to go ahead with this revision was that NI's product was already developed, tested, and in industry use.
Currently, on NI's website at http://www.ni.com/hs488/hs488.htm, it says:
"In addition to rigorous simulation testing, field deployment of HS488-compatible products from National Instruments, Anritsu, Adtech, Nicolet Technologies, Nuclear Diagnostics, and Elektrobit has revealed no reported instances of incompatibility. In fact, National Instruments has been shipping HS488-compatible products for more than four years with no reported problems."
NI has not provided any more concrete compatibility information than that. Each balloter should decide whether that information, NI's past performance and integrity, and the Working Group's decisions are adequate assurance of compatibility.
Section 5.7 of the current IEEE 488.1-1987 spec deals with how instruments should behave when an unrecognized universal command is received. This is not, however, a requirement, and thus there is no guarantee about how an instrument will behave when an unrecognized universal command is received. This implies that adding new universal commands to the 488.1 spec can cause compatibility problems with existing instruments, ranging from simple instrument problems to catastrophic system failures.
Section 4.14 of the proposed specification adds several new interface functions to the original 488.1-1987 spec associated with the Configuration Interface function.
Section 4.14 should be removed.
Section 5.7 is designed to cover the handling of "inappropriate" multi-line messages. These are the defined messages that aren't implemented because of the configuration of the device. The section does not apply to unspecified signal conditions not covered by the standard - especially given the mandate in 5.1 to not introduce new interface functions. There is insufficient cause given here to remove section 4.14 of the proposed standard.
The 488.1-1987 specification has mechanisms in place to allow a controller to reliably interrupt a data transfer. The controller can then perform other necessary work (such as serial poll a device), and resume the interrupted data transfer. This interrupted data transfer is guaranteed to have not compromised the integrity of the data despite the interruption.
However, when a non-interlocked transfer is in progress, there is no way for a controller in each of the 3 possible states (as an AHE, as a SHE, or as neither) to reliably interrupt that data transfer.
Provide mechanisms for controllers to interrupt a non-interlocked data transfer reliably (with no data loss or corruption), whether the controller is a source, an acceptor, or neither.
The new draft handles this in a manner consistent with the original standard. As with the original standard, a controller must be a listener if it wishes to be able to take control in the middle of a transfer. The controller asserts the local message tcs (take control synchronously) just like the original standard. Below is a description of how the controller can interrupt a non-interlocked data transfer to send commands and allow it to resume again without any loss of data or sending of redundant data. Three separate cases exists that will be analyzed:
1) The controller is a listener accepting data in the non-interlocked
mode.
As a listener, the controller's Acceptor Handshake function will be
transitioning between ANDS and ANES on the assertion and unassertion of DAV
respectively. When the controller wants to take control it will set it's local
message "tcs" to true, causing a transition from ANAS to ALNS and then to ANCS
after T17. If DAV is not true the Acceptor Handshake function transitions from
ANES to ACRS. If DAV is true it transitions from ANDS to ANTS where it accepts
the byte that is currently being sourced then transitions to AWNS. Both AWNS and
ACRS are part of the original IEEE 488.1 Acceptor Handshake function and from
either of these states the controller can take control and source commands in
the same manner as the original specifications.
2) The controller is a talker sending data in the non-interlocked mode.
The new Extended Source Handshake function is very similar to the original SH
function and likewise the controller can take control in the same manner. When
the SHE is waiting for the next byte ("nba" to become true) while in SGNS the
controller can issue a "tca" local message instead of an "nba". This is safe
since while in SGNS no transfer is in progress. This causes the controller
function to assert ATN forcing the SHE into SIDS. When the controller function
goes into CACS the SHE moves back to SGNS but this time with ATN asserted so it
is ready to send commends. This is exactly the way the original SH function
operates.
3) The controller is neither talker or listener during a non-interlocked
transfer.
It is not possible for the controller to take control synchronously if it is
neither a talker or listener. This is true for both the original IEEE 488.1
specification and the new draft. To solve this the controller must assert the
"lon" local message to force it to listen before it unasserts ATN. This
situation is exactly the same as the first case described above since the
controller is also an active listener.
Section 7.2.4 of the proposed spec mentions that "If the SHE and AHE functions are used to transfer data with non-interlocked handshake cycles, all guidelines of section 7.2.3 should be followed". First, this reads ‘should be’, not ‘shall be’, so it is a strong recommendation, not a requirement. Yet there is no discussion of how system performance or data integrity is affected when these guidelines are not met. Many systems have devices that do not meet the specifications outlined in 7.2.3, but rather follow the guidelines in 7.2.1 or 7.2.2. Simply having one of these devices connected could cause problems with non-interlocked data transfers.
A comprehensive discussion is needed of how performance and data integrity is affected when devices are included in a system that conform to either section 7.2.1 or 7.2.2 but not 7.2.3.
To address concerns regarding the use of 'should' versus 'shall' in the data
rate considerations discussion, we make the following change to the
draft:
Section 7.2.4 Data rate considerations (pg 104)
Replace the following sentence:
If the SHE and AHE functions are used to transfer data with non-interlocked
handshake cycles, all guidelines of section 7.2.3 should be followed.
With the sentence below:
If the SHE and AHE functions are used to transfer data with non-interlocked
handshake cycles, all guidelines of section 7.2.3 shall be followed.
488.1 has been a widely used standard for over 20 years. Any changes to this standard must be accompanied by a comprehensive study of cross-vender interoperability. I do not believe that enough multi-vendor testing has been accomplished at this time to make such substantial changes to such an established specification.
Publish the results of extensive and comprehensive multi-vendor system testing.
Your comment is, essentially, that you are not going to vote for this proposed high-speed revision without being provided thorough documentation of compatibility testing. The testing must be with many different brands and types of instruments that use IEEE-488. Preferably the testing should also be with high-speed control electronics (integrated circuit and/or circuit board) made by different companies. You argue that the >20 year history of IEEE-488, the number of existing instruments and current users, and the complexity of these high-speed changes make documented compatibility testing mandatory. In further discussions, you (N. Berg) have said that it is the responsibility of the Working Group (WG), TC-8, and the IEEE to perform this testing before revising the standard.
However, the balloters will NOT receive any documentation of compatibility testing. Neither the WG volunteers, TC-8 volunteers, nor IEEE members and staff have the resources or time to perform such testing. And there is no IEEE requirement that a proposed revision to a standard be compatibility-tested before balloting.
That said, as we all know, this revision is based on the National Instruments (NI) HS-488 product. The first version of this product was released by NI approximately two years prior to the Working Group's first meeting in 1995. Meeting minutes show that one reason TC-8 and the WG voted to go ahead with this revision was that NI's product was already developed, tested, and in industry use.
Currently, on NI's website at http://www.ni.com/hs488/hs488.htm, it says:
"In addition to rigorous simulation testing, field deployment of HS488-compatible products from National Instruments, Anritsu, Adtech, Nicolet Technologies, Nuclear Diagnostics, and Elektrobit has revealed no reported instances of incompatibility. In fact, National Instruments has been shipping HS488-compatible products for more than four years with no reported problems."
NI has not provided any more concrete compatibility information than that. Each balloter should decide whether that information, NI's past performance and integrity, and the Working Group's decisions are adequate assurance of compatibility.
The existing IEEE 488.1 standard is a very stable standard and is being widely used by many vendors and users around the world (IEEE 488.1 and IEC 60625-1). Many hundreds of thousands of instruments and controllers have been developed to this standard over the many years that the standard has existed. The vast majority of customers are satisfied with the performance of IEEE 488.1 and do not require higher performance. Do we need to change the standard to support higher speed operation for a limited number of users? Who is driving the need for a higher speed standard?
Action Required to Change Vote: Validate the compelling need to improve the existing IEEE 488.
The TC-8 committee has already addressed this issue. This issue was raised before the TC-8 Committee when we discussed whether we should proceed with the project and ask for a PAR. The TC-8 committee voted in favor of the project and proceeded with a PAR from the NesCom.
Historically, the IEEE 488.1 and IEC 60625-1 have always worked together to ensure that these two standards are in agreement. The WG3, the working group of the IEC responsible for IEC 60625-1, has expressed numerous concerns over the proposed IEEE 488.1/D1.2 Revision and will not match those changes in IEC 60625-1. It would be highly beneficial to continue to have the United States Standard be the same as the International Standard. A divergence could cause users to have difficulty, if they purchased a product that followed a United States standard, but was incompatible with an international standard that it was historically equivalent to.
Action Required to Change Vote: Ensure that both the IEEE 488.1 standard and the IEC 60625-1 standard continue to be in agreement.
This issue of the divergence of the IEEE and IEC versions of this standard has been prominent from the beginning of this revision project. Following is a summary of the interaction between IEEE TC-8 and IEC WG3 in the early stages:
Parliamentary procedure, of informed individuals voting in good faith, separated the IEC and IEEE on this issue. A majority of IEEE TC-8 members and IEEE NesCom members felt that supporters well outnumbered detractors, by enough margin to go ahead with the project, and that supporters' arguments were valid.
Further examining the points you make in your negative comment:
Your major complaint is that approval of this revision will create two divergent standards. Until now, IEEE-488.1 and IEC 60625-1 have been identical, making this a truly international standard, which benefits users worldwide. With divergent standards, you claim, instruments using the IEEE standard may not be compatible with instruments using the IEC standard.
Disagreement between the IEEE and IEC versions is unfortunate. But that's what happens when there is disagreement between two distinct standards bodies. Does TC-8 have to get approval from WG3 before drafting standards? No. We would like to work closely with them and develop standards in harmony. But if after thorough discussion there is disagreement, and we decide that the merits of a standard outweigh the drawbacks of disagreement, we are obliged to go ahead and develop the standard.
In the past, the IEEE has taken the lead in IEEE-488 revisions, and the IEC has followed after the fact. In particular, IEC 60625-2 was rewritten to match IEEE-488.2, and IEC 60625-1 was revised to drop an alternate connector type in order to match IEEE-488.1. Therefore, there is historical precendent for the IEEE taking action in the 488 standards area without prior approval of the IEC.
Another rebuttal to this complaint is that National Instruments's years of development and field use of their HS-488 technology makes it very likely that instruments using high-speed IEEE-488.1 will be fully compatible with instruments using the existing IEC 60625-1 standard. And if for any reason there is concern about compatibility, the user can simply not activate high-speed mode, making things identical to the old 488.1.
Finally, there have been complaints that IEC WG3 members have been ignored when they have brought up technical flaws in the proposed high-speed protocol. But it appears that these issues were made well known to everyone involved. Particularly, Steve Greer made these flaws known to TC-8 members at multiple TC-8 and WG3 meetings in the early stages of the project. The fact is that, rather than ignoring these complaints, a good majority of TC-8 and working group members simply felt that either 1) the flaw did not exist or 2) the probability of the flaw affecting any user was insignificantly small, and the advantages of the technology outweighed its drawbacks.
The existing 488.1/D1.2 revision revises the original 488.1 document to include many new state diagrams to implement high speed transmission. This solution is very complicated and the same goal could be accomplished using alternatives that are much simpler to implement. An example of this is the proposal submitted by the German National Committee (DKE) which was submitted to the IEEE for consideration. It appears that other alternatives were not considered for this standard.
Action Required to Change Vote: 1. Please explain what other alternatives were considered, if any. 2. If alternatives were not considered, then evaluate other alternatives, and modify 488.1 as appropriate. 3. If other alternatives were considered, provide a satisfactory explanation of why they are not present in 488.1, especially since some of the alternatives appear simpler to implement.
main author: D. Kwock
The first meeting of the Higher Speed Extension to IEEE 488.1 Working Group took place on August 1995 at Autotestcon in Atlanta, Georgia. During that meeting two competing standards were proposed. One proposal was from CEC and the other was from National Instruments.
From the first meeting’s minutes:
"We then discussed how to proceed, since we have two competing standards. The path of least resistance and risk is to adopt one of the existing protocols which has already been developed and proven. This will not be satisfactory to the vendor whose protocol was not chosen and will give an unfair advantage to the vendor whose protocol is selected. A concern was brought up that if we change either protocol too much, it would require additional prototyping and testing. This increased amount of work may be enough resistance to cause us to lose interest in the new protocol. It was generally agreed to review both protocols and any newly proposed protocols. We can, then, select the best features from each"
There was also discussion on how other proposals would be considred:
"It was generally agreed that we allow other companies to submit proposals to the working group for consideration. Therefore, the working group will entertain other proposed specification extensions. If anyone is interested in submitting another proposal, please notify Robert Canik of your intent to do so by Sept. 29, 1995. The target completion of the new specification must be by the end of the year for it to receive consideration"
After that meeting, CEC withdrew its proposal towards the end of 1995. No additional proposals were submitted by the next meeting in February 1996, therefore the working group decided to use National Instrument’s proposal as the basis for the proposed high speed extensions.
In December 1996, the Working Group (WG) Chair circulated Draft 1.3 to all WG members. He also circulated an alternative high-speed proposal submitted by Chris McKenna, formerly of ines Corp. He asked WG members to vote whether to Approve or Disapprove Draft 1.3 for submittal to the next step: the official IEEE balloting process. He directed that anyone having significant issues with the draft or wanting to consider in depth the McKenna proposal should vote to Disapprove and should explicitly indicate his or her issues or wishes for reconsideration.
The result of the December 1996 WG Draft 1.3 ballot was 9 Approves, 3 Disapproves, and 2 Abstains. In February 1997, on the recommendation of then TC-8 chair Marlyn Miner, the WG chair handed over Draft 1.3 for IEEE balloting. The 3 Disapprove votes in the Dec. 1996 WG ballot were accompanied by general comments that the draft was flawed and that the WG should go back to the drawing board and consider all alternatives freshly. But due to the 9 Approve votes, TC-8 felt it appropriate to end the WG phase and proceed into the IEEE ballotting phase.
At this point, the working group’s activities were completed. However, the status of the working group ballot and the process for moving forward was not clearly communicated to members of the working group. There was a signficant delay between submittal (February 1997) and balloting (July 1999). This occurred because the IEEE Standards Association had difficulty estabilishing a balanced voter pool.
During this period, the DKE (Deutsches Komitee der Internationalen Elektrotechnischen Kommission - which is the German National Committee of the IEC) introduced a proposal for "high speed extensions to IEC 60625", which is the IEC equivalent of IEEE 488.1 in June 1998.
The current proposal implements high speed alternatives by adding a large number of new state machines. This complex implementation has been "tested" in multiple vendors implementation but they were all based on a single vendor’s implementation of a custom ASIC. Given the complexity of the implementation it is highly probably that many vendors will not be able to successfully duplicate the required behavior. This would lead to incompatibility issues. Because of this incompatibility risk and the limited need for high speed, it would be better to eliminate this section of the standard or use a simpler to use alternative.
Action Required to Change Vote: (a) REMOVE complex state diagrams related to high speed implementation (specifically the interface functions CF, SHE, AHE) OR (b) REPLACE the complex changes related to high speed implementation with a simpler alternative (better technical solution).
The high speed configuration more than doubles the number of state machines in IEEE-488.1. This proposal was, however, accepted by both NI and CEC and by a large majority of the working group. When this proposal was first raised NI did not have an implementation. Neither vendor believed that the result was too complex to implement.
IEEE-488 predates IEEE-488.1 by about 15 years, and the changes for IEEE-488.1 were not major. The state machines in IEEE-488.1 therefore date back about 25 years. The advances in IC design apparently allow both NI and CEC to believe that they can implement this feature.
A more significant issue is not whether this can be done, but whether it is worthwhile to do it. This was already addressed by the working group and NesCom when the working group requested and received a PAR.
National Instruments Corporation has been granted United State Patent #US5315706 issued on May 24, 1994 titled "High speed IEEE 488 bus interface system and method" to inventors: Thomson, Andrew C,;Odom, Brian K.; Butler, C. Paul; Jablin, Michael G.; Nowlin, Jr., William C.; Canik, Robert W. The IEEE 488.1/D1.2 revision appears to make extensive use of patented material. My understanding of the IEEE patent policy is that patented material can be included in standards provided patents have unrestricted licensing and fair economic licensing conditions. Inquires to the IEEE, regarding patent status have been directed to the IEEE legal department, which has failed to respond to inquires. What patents are involved with this proposal and do the licensing terms abide by IEEE policy?
Action Required to Change Vote: 1. Add text to the standard that lists what Patents are involved in this proposal and applicable licensing terms that are consistent with IEEE policy. This would be similar to the wording in Paragraph 6, Page iii in the introduction to the standard that describes Hewlett-Packard's patent on the three-wire handshake.
The patent release was issued by National Instruments in conformance to IEEE rules in 1996. This issue was brought up at the NesCom hearing to approve the PAR and at a future working group meeting. The NesCom approved the PAR despite this objection for two reasons: (1) Hewlett-Packard owned the patent to the original three-wire handshake when the original version of the IEEE Std 488.1 was approved by the IEEE, and (2) National Instruments submitted a letter to the IEEE assuring that they would openly license the technology to anyone if the new standard utilized any of it’s patented technologies. In a meeting of the working group this issue was raised by Paul Skar; at that time, National Instruments issued a letter giving up it’s right to the patent covering the technology incorporated in the draft standard. A copy of that letter has been attached to this rebuttal for reference.
[Attach NI letter to ballot recirculation package.]
My understanding is that the working group distributed draft revision 1.3. The balloted specification is revision 1.2. The balloted revision appears to have addressed some of the prior comments, however, which people in the working group reviewed the drafts and which people made changes? I was not informed of the current progress since the last sponsor ballot, until I received the new proposed ballot.
Action Requested: Document what process was used to make revisions. Ensure that the process followed was correct and that a majority of the working group had a chance to have input.
Following is a summary of the events and the process by which the Working Group (WG) arrived at the draft specification on which we are voting:
It has become apparent that the WG leadership and TC-8 leadership did not communicate in early 1997, to all WG members and other interested parties, the results of the December 1996 WG ballot nor an explanation of the IEEE balloting process that was beginning. Some parties, both on the majority supporting side and the minority opposition side of the matter, stated that they were confused and frustrated due to the lack of communication at that time.
Some opposing this high-speed 488 revision have stated that the WG did not follow proper procedure, and that therefore the WG should reconvene to develop a new draft using proper procedure. However, IEEE leadership involved in standards activities have not found any evidence of improper procedures that would warrant scuttling the balloting process now underway.
Finally, regarding the inconsistent version numbers:
This typographical error has not resulted in any misunderstanding of the
technical content of the draft standard. There was an inconsistency in the draft
numbering between the last vote of the working group and the official IEEE
sponsored ballot. The working group approved draft 1.3 and the ballot
distributed by the IEEE was labeled draft 1.2. This was a simple typographical
mistake on our part. The working group worked from a list of instructions that
explained how the original standard should be modified. Between the time the
working group voted to support draft 1.3 and when the IEEE conducted its ballot,
we had to merge the instruction list into the original document. For that
process we used draft 1.3 as approved by the working group; however, for some
reason, most likely due to a typo, the draft sent to the IEEE stated it was
draft 1.2. This will be corrected in the final draft, which we are currently
working on that incorporates the editorial changes we received for balloters
that voted to approve with comments.
I have not received the results of the previous sponsor ballot.
Action Requested: Publicly communicate results of previous sponsor ballot.
There was no Sponsor Ballot prior to the official IEEE ballot in July 1999 on which you voted Negative. There was a Working Group ballot in December 1996. The WG ballot is described and results are given in the above rebuttal to your previous comment. In 1997 and again in 1998, TC-8 chair Marlyn Miner sent out invitations to be in the IEEE official ballot group, but these invitations were not Sponsor Ballots.
Section 4.14 refers to interface functions (CF, SHE, and AHE) that are incompatible with the fundamental logic applied to all previous 488 implementations. This logic specifically disallows introduction of new and previously undefined functions. Review of that logic leads to a logical impossibility for assurance of system behavior and stability with previous adaptations of 488.1. These functions must be removed from the specification proposal.
The new functions have been shown to work in a compatible manner with the existing 488.1 functions. If the comment references Section 5.1, then that doesn't match our interpretation of the standard which is that the designer, the user of the standard, is not to introduce new functions. This doesn't apply to the developers of the standard itself and in fact allows the introduction of new features with relative safety.
To address concerns about compatibility of the new non-interlocked data transfer mode, we've explicitly added text to the draft that indicates the default condition of an implementation is to have non-interlock data transfer capabilities turned off. There are 3 places in the draft that we find appropriate to remind implementers that defaulting to non-interlocked turned off is a requirement:
Section 4.3.3.7 Source wait for RFD state (SWRS) (pg 28)
Add to the end of the first sentence:
NOTE: The SHE will enter SWRS to initiate a non-interlocked mode of data transfer. SWRS can only be entered if CNCS is false. CNCS can only be false if the controller explicitly issues a CFGn command. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Section 4.4.3.13 Accept non-interlocked configured state (ANCS) (pg 38)
Add to the end of the second paragraph:
NOTE: The AHE will enter ANCS to initiate a non-interlocked mode of data transfer. ANCS can only be entered if NIC is true indicating the SHE is in SNGS. The SHE can only be entered if previously CNCS was false. CNCS can only be false if the controller explicitly issues a CFGn command. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Section 4.14.3.3 Configure not configured state (CNCS) (pg 89)
Add to the end of the last sentence:
NOTE: The CF function exits CNCS only if the controller sends an explicit CFGn message. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
The CFGx function states that are intended to define the system cable length(s) are still subject to implementation errors. Data integrity and system instability can easily be compromised by simple-minded modifications to system layout. A configuration verification and confirmation methodology must be defined and implemented to solve this problem.
In the following discussion, it is assumed that a default state of the CF interface function has been specified as FALSE. If that is so, then the user and/or system integrator is not required to set the cable length parameter unless they want to set CF TRUE.
D. Clemens wrote: "… since the CF interface function adds substantial complexity, it is highly probable that another vendor would create an incompatible version." In the implementations of IEEE-488 available for many years it is possible to set the T1 delay for fast, normal or slow operation. The correct setting is dependent on the cable length and number of devices connected. The IEEE-488.1 standard does not describe how to set this, of course. If more instruments and/or more cable is added it is possible that this setting will need to be changed. The CF interface function and the cable length parameter serve the same purpose as setting T1 "fast". They will be described in the 488.1 standard. That is desirable. Setting a short cable length and forgetting to change it when adding devices is extremely similar to setting "fast T1" and then forgetting to change it when adding devices. CF will be FALSE by default similar to the way T1 delay is "normal" by default. Therefore, the argument that the CF interface function adds substantial complexity is not correct. This complexity already exists in the most widely used implementations, but is currently outside of the scope of the standard.
P. Fleming wrote: "Data integrity … can easily be compromised by simple-minded modifications to system layout. A configuration verification and confirmation methodology must be defined and implemented to solve this problem." S. Lomas makes a similar point.
As mentioned above, if we agree that CF defaults to FALSE then it does not mandate that anyone determine, set, and remember to update cable lengths. If a user takes it upon himself to configure the system for high speed transfer then, it is true, he must remember to update it if cable length is changed. Does this mean that it is the responsibility of the standard to include a confirmation methodology? Consider SCSI, a widely used high speed parallel interface that required termination at the end of a chain of devices. If the termination is missing, or if there are two, the system almost certainly does not work. A separate confirmation methodology was not implemented.
Consider the T1 "fast" setting mentioned above: again, there was no confirmation except that the system worked. Based on these precedents, it is clear that while it might be desirable it is not required that IEEE-488.1 include a confirmation methodology.
Let us make the attempt to consider what could be included as a verification
methodology. The standard could define a pseudo-random sequence (PRS) either
directly or by specifying a generating polynomial. The controller could send a
device specific message to a device to make it receive and check the bytes in
this PRS. The bytes would be sent using the high speed handshake, of course. At
the end of the transmission the controller could query the device to find out if
the sequence was received correctly. The method would have to be defined such
that the device could not "hang" if it missed bytes. The problems with this
suggestion include:
1) added cost to implement
2) Added complexity, possibility of incorrect implementation.
3) Unless the sequence is quite long it will not be possible to confirm a
reasonable byte error rate. For different applications different BER is
acceptable. At 5MB/s to verify to 1e-7 would take several seconds, verifying to
1e-9 would take about 10 minutes.
Although it is reasonable to try to confirm correct operation, verification to the tolerance desired is best left to the application level and should not be required of the 488.1 standard. For the user to do this all he'd need are two computers in the system, one being the controller which sends data to the second, which checks it. It would have to be assumed that when the second computer and the cable leading to it is removed the system will perform at least as well.
To resolve these comments, language should be added to the standard stating that if the high speed handshake is configured, correct operation should be verified on any system layout change. The method for performing such verification is outside the scope of the standard.
To address concerns regarding the effect of changing cable configurations, we found an appropriate place to recommend that communications verifications be performed after cabling changes:
Section 8.4.3 Cabling configurations (pg 111)
Add to the end of the section:
It is recommended that system communications be verified after cable layout
changes.
The costs associated with implementation of such a complicated proposal can be overwhelming to many implementers and developers. A brief discussion of this topic that has been previously published is included within an additional attachment for reference. The complexity of this solution is addressed through a number of alternative proposals. These alternatives must be carefully reviewed and integrated with this proposal in a formal, open, and professional manner.
The high speed configuration more than doubles the number of state machines in IEEE-488.1. This proposal was, however, accepted by both NI and CEC and by a large majority of the working group. When this proposal was first raised NI did not have an implementation. Neither vendor believed that the result was too complex to implement.
IEEE-488 predates IEEE-488.1 by about 15 years, and the changes for IEEE-488.1 were not major. The state machines in IEEE-488.1 therefore date back about 25 years. The advances in IC design apparently allow both NI and CEC to believe that they can implement this feature.
A more significant issue is not whether this can be done, but whether it is worthwhile to do it. This was already addressed by the working group and NesCom when the working group requested and received a PAR.
The last version of this proposal that I reviewed (in 1997) was version 1.3. How did we get back to version 1.2, or is this really version 1.4? There is at least a procedural flaw involved that has precluded visibility or comment regarding changes from version to version. Given the magnitude of observed changes within the document, there is ample reason to question from whence this version evolved. This procedural flaw must be corrected and explained.
This typographical error has not resulted in any misunderstanding of the technical content of the draft standard. There was an inconsistency in the draft numbering between the last vote of the working group and the official IEEE sponsored ballot. The working group approved draft 1.3 and the ballot distributed by the IEEE was labeled draft 1.2. This was a simple typographical mistake on our part. The working group worked from a list of instructions that explained how the original standard should be modified. Between the time the working group voted to support draft 1.3 and when the IEEE conducted its ballot, we had to merge the instruction list into the original document. For that process we used draft 1.3 as approved by the working group; however, for some reason, most likely due to a typo, the draft sent to the IEEE stated it was draft 1.2. This will be corrected in the final draft, which we are currently working on that incorporates the editorial changes we received for balloters that voted to approve with comments.
The introductory comments to this proposed specification (page iii, paragraphs 7 & 8) are somewhat misleading, suggesting that this standard is a joint creation effort supported and contributed by the IEC Technical Committee 65. The implied agreement is FALSE in that no known coordination has taken place with that organization to ensure agreement and harmonization of this proposal with the existing IEC version of the 488 standard (known as IEC60625-2). Specifically, it is known that serious disagreement does exist and must be resolved.
To correct this error, we make the following change to the draft:
Introduction (page iii)
Replace the following two paragraphs:
This standard is based on work initiated by the International Electrotechnical Commission (IEC) within Technical Committee 65, Subcommittee 65C, Working Group 3 (formerly TC66/WG3), and follows the general concepts of a standard prepared by the IEC. This standard influenced, and was influenced by, working documents in the IEC.
The two IEEE Committees responsible for the preparation and evaluation of this standard within the US were the Instrumentation and Measurements Society Subcommittee on Instrument/Computer Interfaces (which also serves as the US Advisory Committee to US representatives on IEC SC 65/WG3) of the Instrumentation and Measurements Society Technical Committee on Automated Instrumentation.
With this paragraph:
The 1987 version of this standard was based on work initiated by the International Electrotechnical Commission (IEC) within Technical Committee 65, Subcommittee 65C, Working Group 3 (formerly TC66/WG3), and follows the general concepts of a standard prepared by the IEC. In 1995 and 1996, the IEEE technical working group enhanced the 1987 standard to improve performance over IEEE 488.1-1987.
The DKE has, in fact, submitted an alternative proposal to the IEC for higher speed 488 which seems much more robust, backwards compatible to existing applications, and also appears to be simpler and less costly to implement. This proposal has been widely published in both European and American Press sources, but there is no evidence of technical dialog with the IEC or other sources regarding other means for accomplishing the higher performance goals for 488. A formal technical review must be performed, with the results publicly reported, regarding the merits and/or integration of such alternatives. At a minimum, this kind of technical review is fundamental to ANY good engineering decision. It is MANDATORY for such an important world standard as IEEE 488.x.
main author: D. Kwock
The first meeting of the Higher Speed Extension to IEEE 488.1 Working Group took place on August 1995 at Autotestcon in Atlanta, Georgia. During that meeting two competing standards were proposed. One proposal was from CEC and the other was from National Instruments.
From the first meeting’s minutes:
"We then discussed how to proceed, since we have two competing standards. The path of least resistance and risk is to adopt one of the existing protocols which has already been developed and proven. This will not be satisfactory to the vendor whose protocol was not chosen and will give an unfair advantage to the vendor whose protocol is selected. A concern was brought up that if we change either protocol too much, it would require additional prototyping and testing. This increased amount of work may be enough resistance to cause us to lose interest in the new protocol. It was generally agreed to review both protocols and any newly proposed protocols. We can, then, select the best features from each"
There was also discussion on how other proposals would be considred:
"It was generally agreed that we allow other companies to submit proposals to the working group for consideration. Therefore, the working group will entertain other proposed specification extensions. If anyone is interested in submitting another proposal, please notify Robert Canik of your intent to do so by Sept. 29, 1995. The target completion of the new specification must be by the end of the year for it to receive consideration"
After that meeting, CEC withdrew its proposal towards the end of 1995. No additional proposals were submitted by the next meeting in February 1996, therefore the working group decided to use National Instrument’s proposal as the basis for the proposed high speed extensions.
In December 1996, the Working Group (WG) Chair circulated Draft 1.3 to all WG members. He also circulated an alternative high-speed proposal submitted by Chris McKenna, formerly of ines Corp. He asked WG members to vote whether to Approve or Disapprove Draft 1.3 for submittal to the next step: the official IEEE balloting process. He directed that anyone having significant issues with the draft or wanting to consider in depth the McKenna proposal should vote to Disapprove and should explicitly indicate his or her issues or wishes for reconsideration.
The result of the December 1996 WG Draft 1.3 ballot was 9 Approves, 3 Disapproves, and 2 Abstains. In February 1997, on the recommendation of then TC-8 chair Marlyn Miner, the WG chair handed over Draft 1.3 for IEEE balloting. The 3 Disapprove votes in the Dec. 1996 WG ballot were accompanied by general comments that the draft was flawed and that the WG should go back to the drawing board and consider all alternatives freshly. But due to the 9 Approve votes, TC-8 felt it appropriate to end the WG phase and proceed into the IEEE ballotting phase.
At this point, the working group’s activities were completed. However, the status of the working group ballot and the process for moving forward was not clearly communicated to members of the working group. There was a signficant delay between submittal (February 1997) and balloting (July 1999). This occurred because the IEEE Standards Association had difficulty estabilishing a balanced voter pool.
During this period, the DKE (Deutsches Komitee der Internationalen Elektrotechnischen Kommission - which is the German National Committee of the IEC) introduced a proposal for "high speed extensions to IEC 60625", which is the IEC equivalent of IEEE 488.1 in June 1998.
A careful examination of what this proposal does in fact represent is required. IEEE-488 IS a packet-data transfer methodology that has integrated data corruption protection with its built-in handshake and verification tools. The basic elements of this proposal are designed to eliminate this most important feature of 488 and transform the methodology into a data-streaming process without the data verification features. One must ask the question – WHY? This question must be answered in light of the fact that other data transfer methodologies are readily available to the user today, such as IEEE-1174 or IEEE-1394. In fact, these methodologies are MUCH less complex and expensive to implement while giving significantly better performance than the marginal results of this proposal. Given this perspective, it is clear that this proposal is not really 488 at all, but really something else that piggybacks on some of the existing 488 supporting infrastructure. Technically, there would not be a serious problem with that IF (AND ONLY IF) the proposal is treated correctly for what it is and given a NEW and INDEPENDENT TITLE and NUMERICAL DESIGNATION.
In reading the Scope and Object of 488.1, we would not characterize 488.1 as described above as a packet-data transfer handshake and verification tool. It is a way to interconnect programmable instrumentation. The proposal adds nothing that isn't consistent with the overall scope and object of the current standard. The extensions of the proposal are very closely intertwined with the current standard and additional and unnecessary confusion would be added by separating the material to form a new standard.
The high speed data transfer scheme uses IEEE 488.1 signals in a way which existing equipment will not recognise, and which may therefore cause them to behave unpredictably.
It is difficult to argue with this statement except to say that good engineering design practice would prevent disruptive actions to come out of the receipt of undefined signals. As no specific problems with specific products, GPIB IC's, etc. were mentioned, this is just hypothetical at this point and is not sufficient to cause the proposal to be rejected.
To address concerns about compatibility of the new non-interlocked data transfer mode, we've explicitly added text to the draft that indicates the default condition of an implementation is to have non-interlock data transfer capabilities turned off. There are 3 places in the draft that we find appropriate to remind implementers that defaulting to non-interlocked turned off is a requirement:
Section 4.3.3.7 Source wait for RFD state (SWRS) (pg 28)
Add to the end of the first sentence:
NOTE: The SHE will enter SWRS to initiate a non-interlocked mode of data transfer. SWRS can only be entered if CNCS is false. CNCS can only be false if the controller explicitly issues a CFGn command. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Section 4.4.3.13 Accept non-interlocked configured state (ANCS) (pg 38)
Add to the end of the second paragraph:
NOTE: The AHE will enter ANCS to initiate a non-interlocked mode of data transfer. ANCS can only be entered if NIC is true indicating the SHE is in SNGS. The SHE can only be entered if previously CNCS was false. CNCS can only be false if the controller explicitly issues a CFGn command. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Section 4.14.3.3 Configure not configured state (CNCS) (pg 89)
Add to the end of the last sentence:
NOTE: The CF function exits CNCS only if the controller sends an explicit CFGn message. It is a REQUIREMENT that all non-interlocked handshake mode features default (power-on) to disabled until an explicit CFGn command is issued.
Perhaps of even more concern I the fact that this revision will lead to the destruction of the harmony between IEEE 488.1 and the IEC 60625-1 equivalent, which has benefited the standard with true international status up until the present time.
This issue of the divergence of the IEEE and IEC versions of this standard has been prominent from the beginning of this revision project. Following is a summary of the interaction between IEEE TC-8 and IEC WG3 in the early stages:
Parliamentary procedure, of informed individuals voting in good faith, separated the IEC and IEEE on this issue. A majority of IEEE TC-8 members and IEEE NesCom members felt that supporters well outnumbered detractors, by enough margin to go ahead with the project, and that supporters' arguments were valid.
Further examining the points you make in your negative comment:
Your major complaint is that approval of this revision will create two divergent standards. Until now, IEEE-488.1 and IEC 60625-1 have been identical, making this a truly international standard, which benefits users worldwide. With divergent standards, you claim, instruments using the IEEE standard may not be compatible with instruments using the IEC standard.
Disagreement between the IEEE and IEC versions is unfortunate. But that's what happens when there is disagreement between two distinct standards bodies. Does TC-8 have to get approval from WG3 before drafting standards? No. We would like to work closely with them and develop standards in harmony. But if after thorough discussion there is disagreement, and we decide that the merits of a standard outweigh the drawbacks of disagreement, we are obliged to go ahead and develop the standard.
In the past, the IEEE has taken the lead in IEEE-488 revisions, and the IEC has followed after the fact. In particular, IEC 60625-2 was rewritten to match IEEE-488.2, and IEC 60625-1 was revised to drop an alternate connector type in order to match IEEE-488.1. Therefore, there is historical precendent for the IEEE taking action in the 488 standards area without prior approval of the IEC.
Another rebuttal to this complaint is that National Instruments's years of development and field use of their HS-488 technology makes it very likely that instruments using high-speed IEEE-488.1 will be fully compatible with instruments using the existing IEC 60625-1 standard. And if for any reason there is concern about compatibility, the user can simply not activate high-speed mode, making things identical to the old 488.1.
Finally, there have been complaints that IEC WG3 members have been ignored when they have brought up technical flaws in the proposed high-speed protocol. But it appears that these issues were made well known to everyone involved. Particularly, Steve Greer made these flaws known to TC-8 members at multiple TC-8 and WG3 meetings in the early stages of the project. The fact is that, rather than ignoring these complaints, a good majority of TC-8 and working group members simply felt that either 1) the flaw did not exist or 2) the probability of the flaw affecting any user was insignificantly small, and the advantages of the technology outweighed its drawbacks.
The interlinked state machines of the existing IEEE 488.1 standard have been largely unchanged for over two decades, a fact which I believe has contributed to the success and wide acceptance of the standard. Introducing the additional complexity embodied in this revision is likely to lead to errors in interpretation.
The high speed configuration more than doubles the number of state machines in IEEE-488.1. This proposal was, however, accepted by both NI and CEC and by a large majority of the working group. When this proposal was first raised NI did not have an implementation. Neither vendor believed that the result was too complex to implement.
IEEE-488 predates IEEE-488.1 by about 15 years, and the changes for IEEE-488.1 were not major. The state machines in IEEE-488.1 therefore date back about 25 years. The advances in IC design apparently allow both NI and CEC to believe that they can implement this feature.
A more significant issue is not whether this can be done, but whether it is worthwhile to do it. This was already addressed by the working group and NesCom when the working group requested and received a PAR.
The high speed data transfer scheme relies on knowledge of cable lengths, which systems in general have no automated way of checking. If a cable length is changed without updating the data available to the system then unreliable data transfers could result, and furthermore could remain undetected.
In the following discussion, it is assumed that a default state of the CF interface function has been specified as FALSE. If that is so, then the user and/or system integrator is not required to set the cable length parameter unless they want to set CF TRUE.
D. Clemens wrote: "… since the CF interface function adds substantial complexity, it is highly probable that another vendor would create an incompatible version." In the implementations of IEEE-488 available for many years it is possible to set the T1 delay for fast, normal or slow operation. The correct setting is dependent on the cable length and number of devices connected. The IEEE-488.1 standard does not describe how to set this, of course. If more instruments and/or more cable is added it is possible that this setting will need to be changed. The CF interface function and the cable length parameter serve the same purpose as setting T1 "fast". They will be described in the 488.1 standard. That is desirable. Setting a short cable length and forgetting to change it when adding devices is extremely similar to setting "fast T1" and then forgetting to change it when adding devices. CF will be FALSE by default similar to the way T1 delay is "normal" by default. Therefore, the argument that the CF interface function adds substantial complexity is not correct. This complexity already exists in the most widely used implementations, but is currently outside of the scope of the standard.
P. Fleming wrote: "Data integrity … can easily be compromised by simple-minded modifications to system layout. A configuration verification and confirmation methodology must be defined and implemented to solve this problem." S. Lomas makes a similar point.
As mentioned above, if we agree that CF defaults to FALSE then it does not mandate that anyone determine, set, and remember to update cable lengths. If a user takes it upon himself to configure the system for high speed transfer then, it is true, he must remember to update it if cable length is changed. Does this mean that it is the responsibility of the standard to include a confirmation methodology? Consider SCSI, a widely used high speed parallel interface that required termination at the end of a chain of devices. If the termination is missing, or if there are two, the system almost certainly does not work. A separate confirmation methodology was not implemented.
Consider the T1 "fast" setting mentioned above: again, there was no confirmation except that the system worked. Based on these precedents, it is clear that while it might be desirable it is not required that IEEE-488.1 include a confirmation methodology.
Let us make the attempt to consider what could be included as a verification
methodology. The standard could define a pseudo-random sequence (PRS) either
directly or by specifying a generating polynomial. The controller could send a
device specific message to a device to make it receive and check the bytes in
this PRS. The bytes would be sent using the high speed handshake, of course. At
the end of the transmission the controller could query the device to find out if
the sequence was received correctly. The method would have to be defined such
that the device could not "hang" if it missed bytes. The problems with this
suggestion include:
1) added cost to implement
2) Added complexity, possibility of incorrect implementation.
3) Unless the sequence is quite long it will not be possible to confirm a
reasonable byte error rate. For different applications different BER is
acceptable. At 5MB/s to verify to 1e-7 would take several seconds, verifying to
1e-9 would take about 10 minutes.
Although it is reasonable to try to confirm correct operation, verification to the tolerance desired is best left to the application level and should not be required of the 488.1 standard. For the user to do this all he'd need are two computers in the system, one being the controller which sends data to the second, which checks it. It would have to be assumed that when the second computer and the cable leading to it is removed the system will perform at least as well.
To resolve these comments, language should be added to the standard stating that if the high speed handshake is configured, correct operation should be verified on any system layout change. The method for performing such verification is outside the scope of the standard.
To address concerns regarding the effect of changing cable configurations, we found an appropriate place to recommend that communications verifications be performed after cabling changes:
Section 8.4.3 Cabling configurations (pg 111)
Add to the end of the section:
It is recommended that system communications be verified after cable layout
changes.
The high speed data transfer scheme only provides a benefit in applications and devices where large blocks of data are transferred. It does not affect addressing cycles or other ATN true interactions, and is therefore of limited benefit. Also, it is clear that many applications requiring higher data transfer rates actually require rates significantly higher than the improvements offered by this revision, and would probably look to different interface technology altogether to meet their needs.
The TC-8 committee has already addressed this issue. This issue was raised before the TC-8 Committee when we discussed whether we should proceed with the project and ask for a PAR. The TC-8 committee voted in favor of the project and proceeded with a PAR from the NesCom. The balloter observes that the speed increases only helps in applications with large block transfers and the working group and TC-8 were aware of this when both groups agreed to proceed with the standardization process. The balloter also observes that some applications need even higher speed that should probably be addressed by other interface technologies altogether. This can be address by another standards body or working group, however this is still significant value in a protocol that provides a significant (8 times) speed increase while maintaining compatibility with the large installed base of existing implementations.
I am concerned that the chairman of the working group for this project appears to have a conflict of interest in that the only currently available implementation of the high speed data transfer scheme is, as far as I am aware, a product of his employers.
During the time when the working group was drafting its proposal this issue was raised, and Robert Canik offered to step down. This is recorded in the August 1995 working group minutes. No one volunteered to be chairman. Emails show that both Bob Cram, TC-8 chair, and Robert Canik encouraged others to take over or to be co-chairs. Shortly after that differences between CEC and NI were resolved and the minutes from February 1996 working group meeting state that in light of that "the group agreed that Robert Canik would remain as chair."
Once the working group, which included a representative from CEC and more than one from HP (now Agilent), had agreed on one proposal the possibility of Mr. Canik finding himself in a conflict was very greatly reduced. The working group at that time found it acceptable. The TC-8 chair had been involved, this was not a matter of lack of oversight; he too found it acceptable.
It is likely that the reason no one else wanted to be chair was because they could not get support from their company for the time commitment involved. Mr. Canik could get support from NI. In my very limited experience with this working group (from before CEC and NI reached agreement), Mr. Canik tried hard to act as an unbiased chairman. There was another person from NI present to defend NI's interests. TC-8 was lucky to have someone willing to do the work.
There are other examples of companies pushing standardization efforts, including NI pushing IVI interfaces in C and Agilent pushing COM interfaces. It is simply a given that these companies are working partly in their own interests. They both have a vision of how to allow interchangeable instruments, and probably would not be thinking about that issue if they didn't have a "conflict". The fact that each is an interested party does not detract from the value of the work they are doing.
It is worth noting that the IEEE Standards Board reviewed complaints about this issue and arrived at the "preliminary finding" that they could not find evidence of improper procedures, except for the rebuttals to negative comments in August 1999. That is why we are preparing rebuttals again now.
It is clear that if everyone agreed with this proposal the idea that the chair was biased would not have arisen. I believe it has arisen primarily due to a proposal from the German National Committee (DKE) on achieving higher speed by using active terminations. Some of the negative comments directly mention this "simpler" solution and question why it was "ignored" when raising the issue of bias. Therefore let me address that. Mr. Canik has written that this proposal was submitted by Chris McKenna to the working group just before the final working group ballot. The ballot allowed members to vote for or against the final draft, or to vote to consider the new proposal. The vote was in favor of the final draft. At that time Mr. McKenna's proposal had not yet been submitted to the DKE. After the final draft was submitted to the IEEE the working group's job was completed. It is conceivable that the IEEE will not approve this revision or will simply allow the PAR's four year lifespan to expire, but it is no longer the working group's role to discard the final draft. The DKE proposal requiring active terminators also adds complexity, could compromise reliability if terminations are not correct as system configuration is changed, and does not allow speeds quite as high as HS488. The DKE proposal is orthogonal to HS488: it does not propose modifying the state machines, but does propose modifying the terminations. How could a device know if the terminations were proper? This is similar to a concern raised about HS488. It is easy to conceive that the working group voted against re-opening the entire topic to consider this new suggestion. Mr. McKenna's proposal was considered. The fact that it was voted upon seems to preclude the possibility that its rejection showed bias by the chair.
I believe that this project should have been raised to the international level, particularly as an alternative proposal, which does not appear to exhibit the same technical flaws, is currently under the scrutiny of the IEC.
main author: D. Kwock
The first meeting of the Higher Speed Extension to IEEE 488.1 Working Group took place on August 1995 at Autotestcon in Atlanta, Georgia. During that meeting two competing standards were proposed. One proposal was from CEC and the other was from National Instruments.
From the first meeting’s minutes:
"We then discussed how to proceed, since we have two competing standards. The path of least resistance and risk is to adopt one of the existing protocols which has already been developed and proven. This will not be satisfactory to the vendor whose protocol was not chosen and will give an unfair advantage to the vendor whose protocol is selected. A concern was brought up that if we change either protocol too much, it would require additional prototyping and testing. This increased amount of work may be enough resistance to cause us to lose interest in the new protocol. It was generally agreed to review both protocols and any newly proposed protocols. We can, then, select the best features from each"
There was also discussion on how other proposals would be considred:
"It was generally agreed that we allow other companies to submit proposals to the working group for consideration. Therefore, the working group will entertain other proposed specification extensions. If anyone is interested in submitting another proposal, please notify Robert Canik of your intent to do so by Sept. 29, 1995. The target completion of the new specification must be by the end of the year for it to receive consideration"
After that meeting, CEC withdrew its proposal towards the end of 1995. No additional proposals were submitted by the next meeting in February 1996, therefore the working group decided to use National Instrument’s proposal as the basis for the proposed high speed extensions.
In December 1996, the Working Group (WG) Chair circulated Draft 1.3 to all WG members. He also circulated an alternative high-speed proposal submitted by Chris McKenna, formerly of ines Corp. He asked WG members to vote whether to Approve or Disapprove Draft 1.3 for submittal to the next step: the official IEEE balloting process. He directed that anyone having significant issues with the draft or wanting to consider in depth the McKenna proposal should vote to Disapprove and should explicitly indicate his or her issues or wishes for reconsideration.
The result of the December 1996 WG Draft 1.3 ballot was 9 Approves, 3 Disapproves, and 2 Abstains. In February 1997, on the recommendation of then TC-8 chair Marlyn Miner, the WG chair handed over Draft 1.3 for IEEE balloting. The 3 Disapprove votes in the Dec. 1996 WG ballot were accompanied by general comments that the draft was flawed and that the WG should go back to the drawing board and consider all alternatives freshly. But due to the 9 Approve votes, TC-8 felt it appropriate to end the WG phase and proceed into the IEEE ballotting phase.
At this point, the working group’s activities were completed. However, the status of the working group ballot and the process for moving forward was not clearly communicated to members of the working group. There was a signficant delay between submittal (February 1997) and balloting (July 1999). This occurred because the IEEE Standards Association had difficulty estabilishing a balanced voter pool.
During this period, the DKE (Deutsches Komitee der Internationalen Elektrotechnischen Kommission - which is the German National Committee of the IEC) introduced a proposal for "high speed extensions to IEC 60625", which is the IEC equivalent of IEEE 488.1 in June 1998.