home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / arch / 11665 < prev    next >
Encoding:
Text File  |  1992-12-15  |  15.8 KB  |  352 lines

  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!wotan.compaq.com!twisto.eng.hou.compaq.com!croatia.eng.hou.compaq.com!leigh
  3. From: leigh@croatia.eng.hou.compaq.com (Kevin Leigh)
  4. Subject: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
  5. Message-ID: <1992Dec15.171554.2781@twisto.eng.hou.compaq.com>
  6. Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus
  7. Sender: news@twisto.eng.hou.compaq.com (Netnews Account)
  8. Organization: Compaq Computer Corp.
  9. Date: Tue, 15 Dec 1992 17:15:54 GMT
  10. Lines: 340
  11.  
  12. ************************************************************
  13. *                                                          *
  14. *               COMPAQ COMPUTER CORPORATION                *
  15. *            HOUSTON, TX               *
  16. *                                                          *
  17. *          STRATEGIC TECHNOLOGY DEVELOPMENT GROUP          *
  18. *                                                          *
  19. *   We're sick of beating our heads against the wall       *
  20. *   trying to expand the performance of I/O buses. Let's   *
  21. *   face it, buses are just not a long term cost effective *
  22. *   solution for high performance computer solutions.      *
  23. *   So here is an alternative...                           *
  24. *                                                          *
  25. ************************************************************
  26. *                                                          *
  27. *  Compaq presented a proposal at the PCMCIA sub-committee *
  28. *  (CardBus) meeting in Deerfield Beach, Florida, on       *
  29. *  12/7/92 for possible adoption as the CardBus standard.  *
  30. *                                                          *
  31. ************************************************************
  32.  
  33. Our proposed I/O solution is
  34.     - hierarchical 
  35.     - point-to-point
  36.     - channel I/O architecture
  37.     - scaleable
  38.     - high performance
  39.     - processor & endian independent
  40.     - low cost
  41.  
  42. In short, NOT yet-another shared-wide-bus!!!
  43.  
  44.  
  45.                         CPU
  46.                          |
  47.                          |---memory
  48.                        MIOC
  49.                        /  \
  50.                      IOC  dev3
  51.                      / \
  52.                  dev1  dev2
  53.  
  54.                       Figure-1
  55.  
  56. The basic I/O subsystem [figure-1] consists of a "main" I/O 
  57. concentrator (MIOC) which interfaces the I/O architecture to 
  58. any CPU/Memory architecture.  One or more point-to-point 
  59. channels propagate in a hierarchical manner from the MIOC to 
  60. the devices.  One such device is an I/O Concentrator (IOC) 
  61. which allows the bandwidth of a single point-to-point 
  62. channel to be shared amongst several devices.  Other devices 
  63. might include network interfaces, graphics, SCSI, etc.  You 
  64. may optionally allow a few low bandwidth devices to share 
  65. the same channel under a controlled environment.
  66.  
  67. An interconnection consists of an upstream port (residing
  68. in either an MIOC or IOC), the physical channel
  69. connection, and a downstream port (a device or an IOC).
  70. The physical channel consists of 12 signals:
  71.     -  a 50 MHz synchronizing clock
  72.     -  two handshake signals
  73.     -  eight data, and 
  74.     -  a parity
  75.  
  76. The small number of signals reduces the pin requirements for 
  77. interface ASICs and physical size of adapters/connectors, 
  78. reducing the cost of implementation.  Because all data 
  79. transfers in byte wide quantities and in increasing address 
  80. order, the solution transfers in a non-endian specific 
  81. manner.  Also note that the channel pin-out is NOT a 
  82. derivative of any particular CPU chip's memory interface 
  83. signals, allowing the solution to be connected independent 
  84. of CPU architecture.
  85.  
  86. The proposed solution minimizes "out-of-band" signals.  All 
  87. operations within the I/O subsystem are carried out via 
  88. packets.  Even the synchronizing channel clock is propagated
  89. from the MIOC to the devices through IOCs.  In other words,
  90. the channel clock is redistributed on every IOC's downstream
  91. port.  The signal timings of a channel is independent from
  92. all other channels.  This virtually eliminates signal skew
  93. problems, especially for the clock, common in today's shared
  94. bus systems.
  95.  
  96. The standard data transfer rate on a channel is 50 
  97. MBytes/sec (MBPS) and the upper-bound will be limited by the 
  98. physical environment of the channel.  For example, a current 
  99. high performance implemention with GTL (Gunning Transistor
  100. Logic) drivers and receivers could yield a transfer rate of
  101. 200 MBPS.
  102.  
  103. Two ports on a channel "agree" on a transfer rate during the 
  104. initialization.  Each port multiplies the 50 MHz channel 
  105. clock to generate internal clocks to operate at the agreed 
  106. transfer rate.  Each IOC port can operate at a different
  107. transfer rate.  A device designed to support high transfer
  108. rates also works at lower transfer rates.  That means a
  109. device can be used at any I/O hierarchy level.  The I/O "tree"
  110. should be carefully configured to optimize the bandwidth
  111. distributions according to the system and devices requirements.
  112.  
  113.  
  114. Operations occur using packet-based commands that flow 
  115. through the channels.  Each packet generally contains four 
  116. fields
  117. - command (Read, Write, Error, Extensions/Interrupts, etc.)
  118. - size (the amount of data to be transferred)
  119. - address
  120. - data
  121.  
  122. Only the command field is mandatory.  All ports are 
  123. responsible for some encoding and decoding of packets.  Note 
  124. that only one packet at a time can be transferred on a 
  125. channel.  This means that there will be times that
  126. - a devices cannot send or receive when an IOC downstream port
  127.   does not have space or data, respectively, and
  128. - both ports want to send at the same time.
  129. The channel protocol supports handshaking for data transfers
  130. as well as for conflict resolutions.
  131.  
  132. The commands are designed to allow optimal use of the
  133. distributed I/O bandwidth and to let devices maintain high
  134. bandwidths even when latencies are long.  For example, the
  135. read operations are split transactions, where each read
  136. packet is later responded by a corresponding read-response
  137. packet.
  138.  
  139. The proposed solution is designed to allow the CPU to 
  140. directly read and write registers of MIOCs, IOCs, and
  141. devices in a programmed I/O manner.  However, the
  142. architecture particularly lends itself to Command List
  143. Processing Master devices.  These entities run device-
  144. specific command contexts placed in system memory that define
  145. their operation.  This potentially frees the main CPU to
  146. perform other operations.
  147.  
  148.  
  149. ************************************************************
  150. *                                                          *
  151. *  So, what do you think?  We are interested in making     *
  152. *  this proposal an open Industry Standard.  As such, you  *
  153. *  may request further information, give us your comments, *
  154. *  or ask questions.                                       *
  155. *                                                          *
  156. *                                                          *
  157. *  Contact:                                                *
  158. *                                                          *
  159. *   David Wooten, Manager,                                 *
  160. *     Strategic Technology Development                     *
  161. *     Compaq Computer Corporation,                         *
  162. *     20555, SH 249,                                       *
  163. *     Houston, TX                                          *
  164. *                                                          *
  165. *   Email: davidw@twisto.compaq.com                        *
  166. *   Phone: (713)378-7231                                   *
  167. *   Fax:   (713)374-2580                                   *
  168. *                                                          *
  169. *                                                          *
  170. *                                                          *
  171. *  CONTINUE READING IF YOU'RE INTERESTED IN WHY WE SPENT   *
  172. *  TIME DEVELOPING THIS CONCEPT!!!                         *
  173. *                                                          *
  174. ************************************************************
  175.  
  176. The question we asked ourselves was how can one build an I/O 
  177. subsystem that is high performance, easy to interface, easy 
  178. to expand, and inexpensive?
  179.  
  180. A shared wide-bus is not the solution due to its inherent 
  181. limitations, such as distributed capacitance, one-at-a-time 
  182. transmit, and high pin count for the mother board and add-in 
  183. cards.
  184.  
  185. In the past, shared bus architectures made sense because of 
  186. the TTL technology and the high-cost-and-low-integration of
  187. silicon.  The PC architecture that started almost a decade
  188. ago with a single, shared, 8-bit memory-I/O bus (known as 
  189. "ISA") has evolved into many variants due to the ever-
  190. escalating performance requirements of x86 based CPU
  191. systems.  This phenomenon is also seen in other system
  192. architectures based on non-x86 CPUs.
  193.  
  194. One of the first changes in PC evolution was to move the CPU 
  195. and the memory to a faster proprietary local bus when the 
  196. ISA bus became a bottleneck.  The I/O data bus was widened 
  197. to 16-bit and then to 32-bit to provide higher bandwidth 
  198. for some devices.  There were two PC "wide-bus" solutions: 
  199. EISA, a super-set of ISA for backward compatibility, and 
  200. Micro Channel (MCA).
  201.  
  202. EISA system is more flexible than ISA (and MCA) system
  203. because it can accept either EISA or ISA card.  Also, EISA
  204. cards in EISA systems can provide higher performance than
  205. ISA cards in ISA (or EISA) systems.  As a tradeoff for the
  206. higher bandwidth, the system and the add-in cards for the
  207. wider I/O buses became more expensive than comparable ISA
  208. solutions.  However, even with the presence of higher
  209. bandwidth buses, ISA provided bandwidth adequate for the
  210. majority of devices.  As a result, board vendors continue
  211. to build boards for ISA because of the larger available
  212. market.  ISA cards could be sold into ISA systems and EISA
  213. systems, while EISA cards were limited to EISA systems only.  
  214.  
  215. More recently, color graphics and video applications have
  216. become popular for PCs.  In addition, high pixel 
  217. resolution and more bits-per-pixel (for color) displays
  218. have become more affordable.  Consequently, the bandwidth
  219. demands for the graphics/video devices have become too
  220. large for even EISA and MCA.  To correct this deficiency,
  221. several system OEMs have moved graphics onto higher
  222. bandwidth proprietary local buses.  As the practice of
  223. moving faster devices onto the local bus became common,
  224. there was a need for a standard.  Currently, there are
  225. two local bus standard proposals, namely, PCI (by Intel)
  226. and VL-Bus (by VESA).
  227.  
  228. Existing processors do not have a PCI bus and future 
  229. processors will not directly support the VL-Bus.  Besides, 
  230. PCI and VL have limited plug-in (card) support.  
  231. Consequently, PC systems utilizing PCI or VL may have 
  232. multiple levels of buses (CPU bus, local bus, standard I/O 
  233. bus) and IC bridges to interface between different bus 
  234. protocols.  All of this leads to higher system and add-in 
  235. board costs.  Chip and board vendors also need to choose 
  236. between many different interfaces and form-factors to 
  237. support a wide range of system types.
  238.  
  239. Worse yet, both PCI and VL buses will very likely try to 
  240. satisfy future needs, such as higher bandwidth and 3.3V 
  241. technology, by CHANGING the physical layer.  Examples 
  242. might include: a wider (64-bit) bus once 32-bits runs out of 
  243. steam, and a different driver/receiver technology for higher 
  244. frequencies.  When a 32-bit bus is expanded to 64-bit, a
  245. high-bandwidth (e.g., video) device will not gain 
  246. performance on the 64-bit bus unless it is redesigned for
  247. 64-bit transfers.  Protocols might also have to change and 
  248. many of these changes will render today's PCI and VL devices 
  249. incompatible (PCI does have a compatible transition to 64-
  250. bits).  The additional drivers/receivers and new design will
  251. make the new devices to be more expensive.  The trick is to
  252. allow the aggregate system bandwidth to go up without having
  253. to redesign everything.
  254.  
  255. Neither PCI nor VL supports ease-of-use (hot-insertion,
  256. plug-and-play, etc.) features.  Depending on implementation,
  257. PCMCIA does not support hot-swap and may not offer enough
  258. performance for some applications.  A PCMCIA sub-committee
  259. was created to come up with a PCMCIA super-set called
  260. CardBus.  As mentioned earlier, board vendors made more ISA
  261. cards than than EISA cards for cost reasons and larger
  262. market share.  Similarly, we are guessing that, board vendors
  263. will build more PCMCIA cards than CardBus cards, if CardBus
  264. is a super-set of PCMCIA, i.e., a wider and more expensive
  265. 32-bit bus and backward compatible.
  266.  
  267. To summarize: the PC industry has tried several times to 
  268. solve increasingly higher performance I/O requirements by 
  269. utilizing a multitude of wide, shared buses.  Most solutions 
  270. did not last long because they were not scaleable and they 
  271. were EXPENSIVE.  As a result most PC users continue to buy 
  272. cheap and reasonable performance solutions.  What the 
  273. computer industry needs is a solution that:
  274. (a) solves today's problems (performance, expansion and
  275.     ease-of-use) in a cost effective manner AND
  276. (b) offers a migration path for those who want it AND
  277. (c) is processor independent AND
  278. (d) will provide longevity.
  279.  
  280. Our proposed solution can offer ALL of these properties!
  281.  
  282.  
  283. ************************************************************
  284. *                                                          *
  285. *   To summarize the major Features:                       *
  286. *                                                          *
  287. ************************************************************
  288.  
  289. Our proposed solution is scaleable in multiple dimensions:
  290. performance, expandability and cost.  Specifically
  291.  
  292. FOR PERFORMANCE:
  293. (a) the CPU-memory bandwidth is decoupled from the slower 
  294.     device latencies,
  295. (b) point-to-point minimizes the physical constraints and 
  296.     GTL enables higher signal rates than TTL,
  297.  
  298. FOR EXPANDABILITY:
  299. (c) virtually unlimited number of devices can be connected
  300.     on-board or off-connectors,
  301. (d) expansion can also be made in external boxes via a small
  302.     pin-count robust protocol (e.g., a fast serial link)
  303. (e) hot plug-and-play is supported,
  304.  
  305. FOR COST:
  306. (f) small packages/connectors/boards and high integration 
  307.     can be achieved because of the small number of pins to 
  308.     interface,
  309. (g) the number of PCB layers can be minimized because of 
  310.     "clean" layout and no long traces (even in the case of 
  311.     busing, the fanouts are fairly short),
  312. (h) development cost can be reduced by utilizing common 
  313.     functional blocks (e.g., state machines, FIFOs),
  314. (i) time-to-market can be reduced by integrating common 
  315.     parts,
  316. (j) common parts for a wide range of systems enable large 
  317.     volume, fewer inventory part types and consistent 
  318.     test/manufacturing techniques,
  319.  
  320. FOR COMPATIBILITY:
  321. (k) standard I/Os such as ROM and keyboards can be tapped 
  322.     off of an MIOC or IOC,
  323. (l) existing standard buses (e.g., ISA, PCMCIA) can also be 
  324.     implemented off MIOC or IOC,
  325. (m) Existing application software and operating systems will
  326.     be compatible with some driver updates.
  327.  
  328. FOR LONGEVITY:
  329. (n) the same devices can be reused in future systems because
  330.     they are processor-neutral,
  331. (o) the same I/O subsystem or architecture can be used in a 
  332.     family of products (portables, desktops, workstations, 
  333.     servers),
  334. (p) the same device can be used for different transfer rates 
  335.     without changing the physical interface, and
  336. (q) changing a device interface in the future on a channel 
  337.     does not affect the rest of the devices [we call this 
  338.     "damage control"].
  339.  
  340. ************************************************************
  341. *                                                          *
  342. *   Thanks for reviewing our thoughts!  Feel free to       *
  343. *   to contact us for more information, we're here to      *
  344. *   help!!!                                                *
  345. *                                                          *
  346. *   Happy Holidays from (Strat. Tech. Dev.)                *
  347. *     David Wooten, Kevin Leigh, Reynold Starnes,          *
  348. *     Thanh Tran, Chris Simonich, Brett Costly,            *
  349. *     David Murray, Craig Miller, Roger Tipley             *
  350. *                                                          *
  351. ************************************************************
  352.