home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / arch / 11780 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  4.7 KB

  1. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!granite.pa.dec.com!ajc
  2. From: ajc@pa.dec.com (AJ Casamento)
  3. Newsgroups: comp.arch
  4. Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
  5. Date: 18 Dec 92 18:29:29
  6. Organization: Digital Equipment Corporation
  7. Lines: 84
  8. Message-ID: <AJC.92Dec18182929@thendara.pa.dec.com>
  9. References: <1992Dec15.171554.2781@twisto.eng.hou.compaq.com>
  10.     <1992Dec15.194637.10009@eng.umd.edu>
  11.     <AJC.92Dec16112232@thendara.pa.dec.com>
  12.     <1992Dec16.235011.17202@twisto.eng.hou.compaq.com>
  13. NNTP-Posting-Host: thendara.pa.dec.com
  14. In-reply-to: simonich@croatia.eng.hou.compaq.com's message of Wed, 16 Dec 1992 23:50:11 GMT
  15.  
  16.  
  17.  
  18. In article <1992Dec16.235011.17202@twisto.eng.hou.compaq.com> simonich@croatia.
  19. eng.hou.compaq.com (Chris Simonich) writes:
  20.  
  21.  
  22. >>Very well put.  However, wouldn't it be MUCH cheaper if you used a byte wide
  23. >>interface instead of 32 bit wide interfaces?  The same architecture with
  24. >>the Compaq Proposal saves a lot of pins on the control block.
  25.  
  26.   In terms of pin count on the "control block" (believing that you are using
  27. this term to define what I would call the Tc/CTL and you've been calling the
  28. MIOC) it would certainly be much cheaper. We'd have to talk about possible
  29. scaling to a higher throughput though. We've already got TURBOchannel options
  30. which exceed 50MB/s of data throughput.
  31.  
  32.   Actually, one of the points that I like about the use of a byte wide I/O
  33. channel is that it provides an easier view of >>>shudder<<< endianism. As long
  34. as you agree which orientation to pass the bytes, they can be reorderd one at a
  35. time on the other side of the link as needed by that logic.
  36.  
  37. >>I don't know all that much about Tc, but I've been told that each channel
  38. >>requires about 60ish pins on the controller once data, control, and power/
  39. >>gnd pins are taken into account.  The Compaq proposal requires 20ish pins
  40. >>per channel on the controller.  One could save 120 pins on the controller
  41. >>for this case by using the Compaq Proposal rather than Tc.  A 120 pin savings
  42. >>translates into a significant cost savings.
  43.  
  44.   TURBOchannel is 44 signal pins total (32 for address data, 12 control). It is
  45. I believe the most compact desktop I/O shipping today. However, your point is
  46. well taken. Pins are money in any package. And cost reduction is an obvious 
  47. win if we are given the same performance/functionality.
  48.  
  49. >>Also, it is possible to scale the aggregate bandwidth of a system using
  50. >>the Compaq Proposal to 400MB/s or higher.  The bottleneck is system memory.
  51. >> --
  52. >> ======================================================
  53. >> Christopher Simonich        simonich@twisto.compaq.com
  54. >> Compaq Computer Corp.       [713] 374-1898
  55. >> ======================================================
  56.  
  57.   I agree that the bottleneck is system memory (or the "control block"). A nice
  58. point in your favor is that you put that cost into the system once, rather than
  59. on every expansion card.
  60.  
  61.   Another point in favor of your non-bussed proposal is that you avoid the all
  62. too common issue of an expansion card which is a "bus hog". By this I am talk-
  63. ing about the type of card which arbitrates for the bus and then sits there and
  64. stalls until it needs to transfer data. By so doing, it appears to the end user
  65. that the response time of such an option is very fast. However, what it is in
  66. fact doing is using up valuable bandwidth.
  67.  
  68.  
  69.   One item I didn't see in your proposal was a discussion of form factor and of
  70. orientation. I would like to suggest that you use an orientation like PCMCIA as
  71. opposed to that of EISA. The issue for me here is one of cooling air. If we are
  72. really going to discuss the use of fast graphics options it requires cooling.
  73. The orientation of EISA (or MCA, or PCI proposal) is such that this is much 
  74. more difficult. Three of the cube faces are blocked:
  75.  
  76.         1. You can't blow air through the system module (z axis)
  77.         2. You can't blow air through the option module (x axis)
  78.         3. You can't blow air through the bulkhead (y axis)
  79.  
  80. Given some of the Floating point processors and rendering chip logic that is
  81. being used on high performance graphics (or array processors, etc.) you really
  82. need a clear air flow. The PCMCIA (or TURBOchannel, or Sbus) orientation is a
  83. lot easier for this. Just something to think about.
  84.  
  85.                 Thanx,
  86.                   AJ
  87.  
  88.  
  89.       **********************************************************************
  90.       * AJ Casamento            "The question is not whether or    *
  91.       * Digital's TRI/ADD Program     not the opinions are mine; but    *
  92.       * 529 Bryant Ave. PAG-2         rather, which of my personalities *
  93.       * Palo Alto, CA 94301-1616     do they belong to?"           *
  94.       * 415.617.3460                               *
  95.       * ajc@pa.dec.com                             *
  96.       **********************************************************************
  97.  
  98.  
  99.  
  100.