Article View: comp.arch
Article #11202Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
From: AJ Casamento
Date: Fri, 18 Dec 1992 18:29
Date: Fri, 18 Dec 1992 18:29
81 lines
4870 bytes
4870 bytes
In article <1992Dec16.235011.17202@twisto.eng.hou.compaq.com> simonich@croatia.
eng.hou.compaq.com (Chris Simonich) writes:
>>Very well put. However, wouldn't it be MUCH cheaper if you used a byte wide
>>interface instead of 32 bit wide interfaces? The same architecture with
>>the Compaq Proposal saves a lot of pins on the control block.
In terms of pin count on the "control block" (believing that you are using
this term to define what I would call the Tc/CTL and you've been calling the
MIOC) it would certainly be much cheaper. We'd have to talk about possible
scaling to a higher throughput though. We've already got TURBOchannel options
which exceed 50MB/s of data throughput.
Actually, one of the points that I like about the use of a byte wide I/O
channel is that it provides an easier view of >>>shudder<<< endianism. As long
as you agree which orientation to pass the bytes, they can be reorderd one at a
time on the other side of the link as needed by that logic.
>>I don't know all that much about Tc, but I've been told that each channel
>>requires about 60ish pins on the controller once data, control, and power/
>>gnd pins are taken into account. The Compaq proposal requires 20ish pins
>>per channel on the controller. One could save 120 pins on the controller
>>for this case by using the Compaq Proposal rather than Tc. A 120 pin savings
>>translates into a significant cost savings.
TURBOchannel is 44 signal pins total (32 for address data, 12 control). It is
I believe the most compact desktop I/O shipping today. However, your point is
well taken. Pins are money in any package. And cost reduction is an obvious
win if we are given the same performance/functionality.
>>Also, it is possible to scale the aggregate bandwidth of a system using
>>the Compaq Proposal to 400MB/s or higher. The bottleneck is system memory.
>> --
>> ======================================================
>> Christopher Simonich simonich@twisto.compaq.com
>> Compaq Computer Corp. [713] 374-1898
>> ======================================================
I agree that the bottleneck is system memory (or the "control block"). A nice
point in your favor is that you put that cost into the system once, rather than
on every expansion card.
Another point in favor of your non-bussed proposal is that you avoid the all
too common issue of an expansion card which is a "bus hog". By this I am talk-
ing about the type of card which arbitrates for the bus and then sits there and
stalls until it needs to transfer data. By so doing, it appears to the end user
that the response time of such an option is very fast. However, what it is in
fact doing is using up valuable bandwidth.
One item I didn't see in your proposal was a discussion of form factor and of
orientation. I would like to suggest that you use an orientation like PCMCIA as
opposed to that of EISA. The issue for me here is one of cooling air. If we are
really going to discuss the use of fast graphics options it requires cooling.
The orientation of EISA (or MCA, or PCI proposal) is such that this is much
more difficult. Three of the cube faces are blocked:
1. You can't blow air through the system module (z axis)
2. You can't blow air through the option module (x axis)
3. You can't blow air through the bulkhead (y axis)
Given some of the Floating point processors and rendering chip logic that is
being used on high performance graphics (or array processors, etc.) you really
need a clear air flow. The PCMCIA (or TURBOchannel, or Sbus) orientation is a
lot easier for this. Just something to think about.
Thanx,
AJ
**********************************************************************
* AJ Casamento "The question is not whether or *
* Digital's TRI/ADD Program not the opinions are mine; but *
* 529 Bryant Ave. PAG-2 rather, which of my personalities *
* Palo Alto, CA 94301-1616 do they belong to?" *
* 415.617.3460 *
* ajc@pa.dec.com *
**********************************************************************
Technical Details
Message-ID:
<AJC.92Dec18182929@thendara.pa.dec.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!decuac!pa.dec.com!granite.pa.dec.com!ajcReferences:
<1992Dec15.171554.2781@twisto.eng.hou.compaq.com> <1992Dec15.194637.10009@eng.umd.edu> <AJC.92Dec16112232@thendara.pa.dec.com> <1992Dec16.235011.17202@twisto.eng.hou.compaq.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!decuac!pa.dec.com!granite.pa.dec.com!ajc From: ajc@pa.dec.com (AJ Casamento) Newsgroups: comp.arch Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE Date: 18 Dec 92 18:29:29 Organization: Digital Equipment Corporation Lines: 84 Message-ID: <AJC.92Dec18182929@thendara.pa.dec.com> References: <1992Dec15.171554.2781@twisto.eng.hou.compaq.com> <1992Dec15.194637.10009@eng.umd.edu> <AJC.92Dec16112232@thendara.pa.dec.com> <1992Dec16.235011.17202@twisto.eng.hou.compaq.com> NNTP-Posting-Host: thendara.pa.dec.com In-reply-to: simonich@croatia.eng.hou.compaq.com's message of Wed, 16 Dec 1992 23:50:11 GMT