🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11111

Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE

#11111
From: Chris Simonich
Date: Wed, 16 Dec 1992 23:50
57 lines
3323 bytes
In article <AJC.92Dec16112232@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:
>
>  Actually, I personally find a great deal of merit in the COMPAQ proposal. I
>quite agree that a modular I/O design (whether one uses the terminology of a
>"star topology" or, as we do here in DEC, "radial") has a great deal to 
>recommend it. Consider a TURBOchannel implementation like this:
>
>			------------	    -------	
>		        |          |	    |	  |
>			|  Memory  |========| CPU |
>			|	   |	    |	  |
>			------------	    -------
>			     |		       |
>			     | <--- DMA	       |
>			     |		       |
>			----------	       | <--- PIO
>			|	 |	       |
>			| Tc/CTL |--------------
>		 -------|        |_________________________
>		/	----------			   |
>	       /	   |   |			   |
>	      /		   |   |___________		   |
>	     /		   |		   |		   |
>	    /		   |		   |		   |
>	-------		-------		-------		-------
>       |     |         |     |         |     |         |     |
>    	|sysIO|		| Tc0 |		| Tc1 | 	| Tc2 |
>	|     |		|     |		|     |		|     |
>   	-------		-------		-------		-------
>
>
>Where each of the links to the TURBOchannel Controller (Tc/CTL) is a standard
>25MHz 32bit wide TURBOchannel. The DMA path could be a 50MHz 64bit wide version
>of TURBOchannel (in order to balance the I/O requirements. This would generate
>a system with an aggregate bandwidth of 400MB/s of I/O. The key point here is
>obviously the Tc/CTL ASIC as it will require careful design to support this
>kind of bandwidth (additionally, one could imagine a true dual ported memory
>being used such that the CPU is not starved when DMA access is underway).
>

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.
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.

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
======================================================
Technical Details
Message-ID: <1992Dec16.235011.17202@twisto.eng.hou.compaq.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!wotan.compaq.com!twisto.eng.hou.compaq.com!croatia.eng.hou.compaq.com!simonich
References: <1992Dec15.171554.2781@twisto.eng.hou.compaq.com> <1992Dec15.194637.10009@eng.umd.edu> <AJC.92Dec16112232@thendara.pa.dec.com>

Show Full Headers
Complete Article Headers
Newsgroups: comp.arch
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!wotan.compaq.com!twisto.eng.hou.compaq.com!croatia.eng.hou.compaq.com!simonich
From: simonich@croatia.eng.hou.compaq.com (Chris Simonich)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Message-ID: <1992Dec16.235011.17202@twisto.eng.hou.compaq.com>
Sender: news@twisto.eng.hou.compaq.com (Netnews Account)
Organization: Compaq Computer Corp.
References: <1992Dec15.171554.2781@twisto.eng.hou.compaq.com> <1992Dec15.194637.10009@eng.umd.edu> <AJC.92Dec16112232@thendara.pa.dec.com>
Date: Wed, 16 Dec 1992 23:50:11 GMT
Lines: 57