🚀 go-pugleaf

In article <1992Dec15.171554.2781@twisto.eng.hou.compaq.com>,
leigh@croatia.eng.hou.compaq.com (Kevin Leigh) wrote:
> 
> ************************************************************
> *                                                          *
> *               COMPAQ COMPUTER CORPORATION                *
> *			HOUSTON, TX	                                      		   *
> *                                                          *
> *          STRATEGIC TECHNOLOGY DEVELOPMENT GROUP          *
> *                                                          *
> *   We're sick of beating our heads against the wall       *
> *   trying to expand the performance of I/O buses. Let's   *
> *   face it, buses are just not a long term cost effective *
> *   solution for high performance computer solutions.      *
> *   So here is an alternative...                           *
> *                                                          *
> ************************************************************
> *                                                          *
> *  Compaq presented a proposal at the PCMCIA sub-committee *
> *  (CardBus) meeting in Deerfield Beach, Florida, on       *
> *  12/7/92 for possible adoption as the CardBus standard.  *
> *                                                          *
> ************************************************************
> 
> Our proposed I/O solution is
> 	- hierarchical 
> 	- point-to-point
> 	- channel I/O architecture
> 	- scaleable
> 	- high performance
> 	- processor & endian independent
> 	- low cost
> 
> In short, NOT yet-another shared-wide-bus!!!
With regard to the following posting, which was forwarded to us by several
sources:
     
************************************************************
*                                                          *
*               COMPAQ COMPUTER CORPORATION                *
*                       HOUSTON, TX                        *
*                                                          *
*          STRATEGIC TECHNOLOGY DEVELOPMENT GROUP          *
*                                                          *
*   We're sick of beating our heads against the wall       *
*   trying to expand the performance of I/O buses. Let's   *
*   face it, buses are just not a long term cost effective *
*   solution for high performance computer solutions.      *
*   So here is an alternative...                           *
*                                                          *
************************************************************
*                                                          *
*  Compaq presented a proposal at the PCMCIA sub-committee *
*  (CardBus) meeting in Deerfield Beach, Florida, on       *
*  12/7/92 for possible adoption as the CardBus standard.  *
*                                                          *
************************************************************
     
     
We readily agree with you that connections of the future should be based on
point-to-point physics, since that reduces capacitive loading and stub
length problems, and eliminates the one-at-a-time bottleneck of buses. 

It's also clear that successful connections of the future will be open
standards, since proprietary solutions will have insufficient volumes to
justify their unique (or claimed unique) properties. Therefore, the
proposal to bring such thoughts to standards groups should be encouraged.
     
However, we have the following two concerns about your ANet proposal:

  1) Other (standard) solutions exist, why not use them?

  2) Endian Order. Don't try to punt this issue - you can't.

     
1) EXISTING SOLUTIONS.
     
Here at Apple research, we have been investigating the IEEE Scalable
Coherent Interface, IEEE 1596-1992 (an existing and approved standard, with
chips nearing delivery by multiple vendors). This point-to-point standard
would seem to meet the processor-to-processor communication needs
illustrated at the top of your hierarchy.
     
Another option for low-cost I/O is to use RamLink (P1596.4, chaired by Hans
Wiggers of HP, wiggers@hplhaw.hpl.hp.com). Although originally designed for
high-speed commodity DRAMs, this interface is appropriate to low-cost I/O
devices as well. However, it does not generalize well for directly
supporting future multiprocessor communications. One reason RamLink is
simple is that inside a single memory subsystem it doesn't have to deal
with multiprocessor issues like deadlock, starvation, or mutual exclusion;
those must be handled by the memory or I/O controller as it interfaces to
SCI (or to some bus).
     
It's not clear whether a CardBus interface should be targeted to the
highest flexibility (using SCI, with a modified physical layer) or the
lowest cost (using RamLink). However, regardless of your requirements
statement, an existing and/or an evolving (near completion) IEEE
point-to-point communication standard could be used.
     
     
2) ENDIAN ORDER
     
Let us be more specific. Anyone who has been through the endian wars hopes
to avoid them in the future. That's largely because those who are most
vocal usually come from a marketing department, with a fixed corporate
opinion to support at any cost. HOWEVER, these decisions cannot be avoided
by simply stating the bus is a "byte-wide" bus. Any claims to this affect
are naive and technically misleading. That's a benefit of using an approved
IEEE standard - these issues have already been thoroughly considered and
ambiguities have been resolved.
     
Any bus standard (including bit-serial buses, like the IEEE P1394 bus) has
two forms of byte ordering that are defined:
     
a) Register endian ordering. When 2-, 4-, or 8-byte registers are
   supported, does the byte with the lowest address have the
   most or least significance? Depending on the answer, the bus
   is either declared to be big-endian or little-endian.

b) Multiplexing ordering. When multiplexed with the address,
   in time or in space, is the first data byte multiplexed with
   the most or least significant byte of the address? Depending
   on the answer, the bus is declared to be either big-addressan
   or little-addressan (using the IEEE 896.2-1991 terminology)
   or MAD/SAD (using the terminology of June 1990 article
   "Multiplexed Buses: The Endian Wars Continue"  by
   Dave James)
     
As examples:
     
  1) the Apple Computer products using NuBus have a big-endian
     register ordering (i.e software thinks it's accessing 68K-like
     registers) and a little-addressan byte multiplexing
     order.
  2) The IEEE P1394 SerialBus project is a bit-sequential bus.
     However, since its basic registers conform to the IEEE 1212-1991
     standard (which you might want to consider), the bus is
     called big-endian (of course, application-specific registers
     could be either endian order).
     Since the most significant bits of the address
     and the lowest data addresses are sent first, this bus has
     a big-addressan multiplexing order.
     
So, with this background, please reconsider your "no-endian-order"
statement. What order is assumed by multiple-byte
registers? Something should be assumed, if you want auto-configuration
software to work. Also, which byte of a multiple-byte
address is sent first? I assume it would be the most significant,
which makes it big-addressan.
     
Dave James (dvj@apple.com) and Glen Stone (stone@apple.com)
THESE COMMENTS DO NOT NECESSARILY REPRESENT THE POSITION OF APPLE COMPUTER