Article View: comp.arch
Article #11229Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
From: AJ Casamento
Date: Sat, 19 Dec 1992 13:24
Date: Sat, 19 Dec 1992 13:24
83 lines
4866 bytes
4866 bytes
In article <1992Dec18.100700.62150@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!)
writes:
>>In article <1992Dec17.190553.17417@twisto.eng.hou.compaq.com>, simonich@
>>croatia.eng.hou.compaq.com (Chris Simonich) writes:
>>>In article <1992Dec17.100528.62134@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!)
>>>writes:
>>>>
>>>>Well, working for a small company that can't afford to run out and spin
>>>>ASICs for every design, I would much rather deal with a TURBOchannel that
>>>>can be managed with a few PALs and jellybeans than a lower pin-count bus
>>>>that requires an ASIC to unpack that packets.
>>>>
>>Uh, why do you assume an ASIC is required? Anyway, the intermediate nodes
>>of the network may be used over and over in any new design. The only time
>>>you would have do design anything new is if you changed the system interface
>>>Perhaps an ASIC isn't required, but picking the transactions apart on this
>>>sort of bus requires a more complex state machine than something like the
>>>TURBOchannel. You've traded pin-count for states; to make up for the lack of
>>>pins on the bus, each module has to keep track of which state the bus is in.
>>>On something like TURBOchannel, the state is visible on the bus (the main
>>>exception being DMA burst word count; that's, well, different).
Of course, Roger's outfit has done a number of TURBOchannel options. And I
would hazard that they've also won the prize of simplest desing interface for
the interconnect as well (if I recall correctly Roger, don't you have a PIO
option that uses just a single PAL and some drivers?).
I guess I not as upset by the concept of using an ASIC. Of course, I'm not
talking about respinning a full custom ASIC for each new design either. I'm
talking about something like the current TcIA (TURBOchannel Interface ASIC)
design from Siemens. I think their volume price is under $30 US for a device
that is capable of driving the entire TURBOchannel interface. That includes:
* No need for separate driver componenets
* No additional logic to the TURBOchannel interface
* Both PIO and DMA capability
* 160 pin PQFP (Plastic Quad Flat Pack) package
* Supports the full clock range of 12.5MHz to 25MHz
* Implements a scatter-gather logic for long transfers
* A 24 bit word counter that could allow up to a 64MB transaction
* Separate receive and transmit FIFOs (15 words deep)
* The ability to set a DMA burst size
* 8 general purpose output signals (programmable for the option end)
* 4 general purpose interrupt signals
A preliminary version of the specification is available on line for anonymous
ftp at(compressed postscript file):
gatekeeper: 16.1.0.2 gatekeeper:pub/DEC/TriAdd/tci_spec06.ps.Z
But my view is that the use of such an ASIC (although it came along too late
for most of DAA's designs...the company Roger works for) is not an outrageous
price to pay for a complete interface that will run at over 80MB/s. Do you? And
it saves you more real-estate over the use of programmable logic. And actually,
a lot of option card vendors seem to prefer a "cut and paste" solution such as
this for the interface to the I/O interconnect since it gives them a "known
good" interface and allows them to concentrate their design efforts on the back
end of the card design. And isn't that what you'd like them to do? Focus on the
option logic which is their value added to the product? I also believe that it
drastically reduces the Time To Market of such designs.
In any case, I would recommend that COMPAQ consider such an ASIC design for
this interconnect at some point. Just MHO, of course.
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.92Dec19132456@thendara.pa.dec.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!decuac!pa.dec.com!granite.pa.dec.com!ajcReferences:
<AJC.92Dec16112232@thendara.pa.dec.com> <1992Dec16.235011.17202@twisto.eng.hou.compaq.com> <1992Dec17.100528.62134@cc.usu.edu> <1992Dec17.190553.17417@twisto.eng.hou.compaq.com> <1992Dec18.100700.62150@cc.usu.edu>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: 19 Dec 92 13:24:56 Organization: Digital Equipment Corporation Lines: 83 Message-ID: <AJC.92Dec19132456@thendara.pa.dec.com> References: <AJC.92Dec16112232@thendara.pa.dec.com> <1992Dec16.235011.17202@twisto.eng.hou.compaq.com> <1992Dec17.100528.62134@cc.usu.edu> <1992Dec17.190553.17417@twisto.eng.hou.compaq.com> <1992Dec18.100700.62150@cc.usu.edu> NNTP-Posting-Host: thendara.pa.dec.com In-reply-to: ivie@cc.usu.edu's message of 18 Dec 92 10:07:00 MDT