Philip J. Fleming & Associates, Inc.

World-Wide Consultants to Innovation & Technology

July 15, 1999

Page 1 of 5

Response & Comments re:

Letter Ballot of the TC-8 Automated Instrumentation Committee of the IEEE

Instrumentation and Measurement Society on the Approval of the Revision of

IEEE Project 488.1/D1.2

Regretfully, we must confirm a NEGATIVE (Disapproval) vote for the proposed revisions to IEEE Project 488.1/D1.2 for the following very abbreviated list of reasons:

1. 1. 1. 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.
      2. The CFG_x 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.
      3. 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.
      4. 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.
      5. 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.
      6. 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.
      7. 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.

July 15, 1999

Page 3 of 5

Attachment to Response & Comments re:

Letter Ballot of the TC-8 Automated Instrumentation Committee of the IEEE

Instrumentation and Measurement Society on the Approval of the Revision of

IEEE Project 488.1/D1.2

(Extraction from "Feature Article" T&M World Online , March 10, 1998)

"Understanding the 488 Change Proposal"

The recent public and volatile debate over a proposed change to the well used and understood IEEE-488.1 Standard has, unfortunately, provided little in the way of high quality technical information for the engineering audience that actually uses this specification. We would also note that , contrary to a number of comments seen in recent publications, the roots of this debate go back more than 6 years to at least 1992 and have obviously not been resolved. As a matter of professional policy, we recommend structured, public, and professional debate as a healthy and logical approach to achieving error resistant engineering decisions. Our clients world-wide have asked for an independent "engineering " appraisal of the HS-488 issue; and, as a result, some of this work is presented in this article for the purpose of providing a foundation for better understanding and decision making.

Overview

Good engineering practice will always require a rigorous questioning process at the beginning of application development to determine the benefits and shortcomings involved with new technology and methodology selections. In particular, we would ask:

1. 1. What are the known features or attributes of this methodology that are important to my application?
   2. What is different from what my engineering resources are familiar with?
   3. What are the risks and/or adverse consequences to implementation with my application?
   4. What benefits will be derived for my products, my customers, my company, and my career from this decision?

Applying these questions to the 488 issue in brief, some of the key features of the existing IEEE-488.1 and of the proposed "HS-488" can be presented as follows:

¹ NDAC (Not Data Accepted) line can be used by an acceptor that is unable to buffer more data.

² NRFD(Not Ready For Data) line , when activated by any acceptor, signals HS controller to switch to standard 488 mode. 

July 15, 1999

Page 4 of 5

Attachment to Response & Comments re:

Letter Ballot of the TC-8 Automated Instrumentation Committee of the IEEE

Instrumentation and Measurement Society on the Approval of the Revision of

IEEE Project 488.1/D1.2

Analysis

Now that we have created our list of "features" that might impact our choice of methods for data manipulation on the 488(GPIB) bus, the items with common or similar answers can be set aside while we look at the other elements.

On the positive side of the scale for choosing HS-488 we see that it uses the same GPIB cables and connectors currently in use. The data-streaming methodology is well suited to the transfer of very large amounts of data. The maximum data transfer rate appears to be nearly 8 times faster than existing 488.1 solutions, but we need to examine this further. There is a method for handling non-HS-488 compliant devices connected to the bus, although non-HS compliant devices receive no benefit in performance from an HS controller.

On the negative side, however, three elements from our list show up very prominently as potentially serious problems:

1. 1. The first problem results from "CFE". What is CFE? CFE is a new command (Configuration Enable) introduced to the GPIB bus by an "HS" controller. This command is "non-addressed" which means that it is sent to all devices on the GPIB bus at the same time to inform these devices of the cabling configuration that has been programmed. Reviewing the IEEE-488.1 specification, we find that, for system compatibility reasons, it clearly disallows introduction of a command such as this. Further, it implies that the 488 designer may treat such signals in almost any manner, e.g. error messages to shut down the system. This makes it impossible to guarantee a transparent interface with other 488.1 devices that may be active on the GPIB bus.
   2.  
   3. Cable length is directly related to data transfer speed. From the IEEE-488.1 specification again, we can see that the Settling Time T1 and the Data Valid Time T2 have been set for "worst-case" cable length of a full 15 meters and with 15 active devices. Thus, the 1 MByte/s data transfer rate is "guaranteed" over the full range of cable configurations. The "HS" solution, however, is not so simple to understand. In fact, there are 6 ranges of cable length that are specified and need careful attention. If we extract these two sets of data and plot the results, the graph below gives us some better insight:
   4. 

      ( Note good agreement with results of Pieper, et al. Ref. Http://ourworld.compuserve.com/acea/hs_gpib.htm )

      July 15, 1999

      Page 5 of 5

      Attachment to Response & Comments re:

      Letter Ballot of the TC-8 Automated Instrumentation Committee of the IEEE

      Instrumentation and Measurement Society on the Approval of the Revision of

      IEEE Project 488.1/D1.2

      It now becomes clear that the 8 Mbytes/s advertised for HS-488 becomes something considerably less if you wish to use "HS" with an application that is more complex in terms of cabling runs. If you have only a single node application and less than 2 meters of cable length, the HS methodology does indeed seem to give better performance. Beyond 2 meters, there is little performance improvement over the existing 488 solutions.

   5. The third element of concern is COST. Since the decoding logic has more than doubled for the HS solution, it doesn’t require a great deal of intellectual effort to realize that the cost of the HS controller is going to be more expensive than existing 488 controllers. Simple rule-of -thumb analysis tells us that a 2X increase in chip area equates to a 4X higher probability of defects. This equates directly to higher cost per working circuit, particularly where functions such as 488 are integrated into much larger and more complex circuits that would find such an increase in silicon real estate (and subsequent cost penalties) totally unacceptable and disastrous to their product developments.

Conclusions