NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/arch/11765

Internet Message Format | 1992-12-21 | 1.8 KB

Path: sparky!uunet!caen!hellgate.utah.edu!cc.usu.edu!ivie
From: [e-mail] (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Message-ID: <[e-mail]>
Date: 18 Dec 92 10:07:00 MDT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Utah State University
Lines: 24

In article <[e-mail]>, [e-mail] (Chris Simonich) writes:
> In article <[e-mail]> [e-mail] (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).

--

Roger Ivie                      "My God! That computer is full of Pentium!
[e-mail]                  It's a wonder that you haven't been turned
                                 into mutants!"