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

Text File | 1992-12-20 | 10.4 KB | 199 lines

Newsgroups: comp.arch
Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!unixhub!kfp-slac-mac.slac.stanford.edu!user
From: [e-mail] (David Gustavson)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Message-ID: <[e-mail]>
Followup-To: comp.arch
Sender: [e-mail]
Organization: SLAC
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 18 Dec 1992 04:09:54 GMT
Lines: 186

In article <[e-mail]>,
[e-mail] (Chris Simonich) wrote:
>
> In article <[e-mail]> [e-mail] (Ronald G Minnich) writes:
> >
> >Actually, seems to me they could look at SCI. Except they want low cost.
> >But if the CMOS chips for SCI pan out, maybe they will meet the cost
> >range.
>
> We have received this response from several people.  We
> disagree.  For one SCI had a physical topology (a ring) that
> is not suitable for expansion I/O.  Yes, we know you can run
> the ring to and from the same board and create a topology
> that looks like the Anet (Compaq Proposal) topology but then
> you begin to loose much of the cost advantages.  We took a
> long look at SCI before we created our proposal.  We ran
> into lots of problems trying to allow different speed rings
> to work together and the biggest problem was that we didn't
> like having to have bi-polar transceivers.  When we started
> to recast the thing for CMOS implementation we ran into
> protocol inefficiencies and, well, it just didn't seem to
> work out the way we need it to.  The major thing turned out
> to be that SCI and the Compaq proposal (we call it Anet
> around here) were trying to solve different problems with
> cost, not bandwidth, being the major one.  The fact that the
> 'C' in SCI stands for coherent I think brings out one of the
> differences in approach.  We needed an I/O interface and
> coherency in the I/O subsystem was something that we were
> trying to eliminate.  The address bandwidth required to
> maintain coherency in the I/O subsystem is prohibitive.

1) Coherency in SCI costs you about 2 bits in the packet header, to allow
for more command codes. Otherwise, it costs you nothing if you don't use
it.

The SCI spec spends a lot of space on coherence, and the designers spent a
lot of time in verification and simulation to make sure it works, but you
don't have to use it just because it's available. In fact, the LSI Logic
Coreware implementation of SCI will (according to rumors, it isn't
announced yet) explicitly let you omit all coherence stuff if you wish--and
yet, if you change your mind later, you can still use the chip to do
coherence!!

Coherence in SCI just involves sending ordinary packets, except they have
different command codes. So a chip that sends/receives packets can do
coherence, as long as something (e.g., the cache controller) tells it what
packets to send. The Dolphin/Vitesse GaAs SCI chip does more than this
minimum, however, in order to improve efficiency in high-end coherent
systems. Namely, that chip can do by itself those state-change sequences
that don't require further interaction with its local cache controller,
like following a linked list of caches that need invalidation, and
invalidating them. That task could as easily be handled by the cache
controller instead, but this would increase the traffic on the back end of
the interface chip. In many cases that wouldn't be a problem.

The goal of SCI was to scale all the way from low-end high-volume
low-priced systems to the very high-end low-volume high-priced systems.
It's not reasonable to reject it just because it does more than you want,
if the existence of that capability doesn't cost you much. (It's worth it
to you to pay for the two bits in the command code, because the increased
versatility increases the chip volumes and drops the prices.)

2) SCI isn't a ring unless you want it to be. It's two unidirectional
links. We added some stuff to the SCI spec to make it possible to connect
these links into a ring if you want (address decoding, bypass FIFO), but
all SCI needs is to be able to send packets and receive packets. Again, the
spec talks a lot about how SCI acts in the ring connection, because it was
tricky to find a mechanism that was simple yet high performance, but you
don't have to use it. On the other hand, of course, rings are awfully
inexpensive and it may well be a good idea to think of ways to take
advantage of them. There are ways. For inspiration, I know a company that
plans to build a non-stop computer with triply redundant processors on each
board, using a pair of rings on the backplane....

3) You don't have to use bipolar transceivers. The initial SCI spec does
use differential ECL signals, but that was for expedience in getting the
first high-end chips out. There is a follow-on standard called LVDS (Low
Voltage Differential Signals, P1596.3) that is nearly finished with
defining signals that are more appropriate for CMOS. It is also defining
4-bit (6 signal) and 8-bit (10 signal) links for low-end applications.
Eventually these signals will be able to go faster than the ECL ones,
because they only have to slew 0.25 volt instead of 1 volt, but the chips
you see in the next 6 months will probably be slower than the ECL ones.
They will be plenty fast enough for your application, though...

>
> Don't get me wrong, we think that from a technical point of
> view SCI is neat.

Thanks!

> It just seems to be intended for a
> different part of the system architecture.

Yes, but for that part AS WELL AS the part you want right now--they aren't
mutually exclusive.

Furthermore, you will quickly find reasons to expand the functionality of
your Anet to support multiprocessing (e.g. [e-mail]'s (James
G. Landowski's) request in this thread), and multiprocessing works a LOT
better if you design it in from the start rather than paste it on
afterward. SCI was designed from the ground up to do multiprocessing, and
there are subtle issues there that took a lot of effort to get right.

There was also a suggestion in this thread (from [e-mail]
(Yamanari)) to use QuickRing. I think there are a lot of nice ideas in
QuickRing, especially the packaging and interconnect physical stuff. But it
is more suited to be a bulk data mover than a general purpose
(multiprocessor or I/O) communication system.

I should also point out that SCI's signaling is distance-independent, so
you can put long cables in if you like, with signal regenerators as needed,
without breaking any buffer-size assumptions (like reverse flow-control
wire schemes do), and it works over fiber optics too. The SCI serial
interface chips (HP's G-Link) have been working at speeds up to 1.5 Gbit/s
for a year, commercially available since summer, and now are in several
products on the market. They are easy to use, which is unusual for high
speed serial chips...

> We would welcome
> any comments you have to the contrary.  When/if you respond,
> tell us how we can make an SCI, I/O subsystem as cheap as an
> Anet, I/O subsystem.
> --
> ======================================================
> Christopher Simonich        [e-mail]
> Compaq Computer Corp.       [713] 374-1898
> ======================================================

The answer depends on your time scale, budget, etc.

Since you are in an extremely high volume business, you can ignore the
1-time personpower costs of developing your own protocols, interface chips,
verification suites, test equipment, documentation, service tech training
etc.

And because you are so dominant in your market, you can make something an
industry standard by just printing it and declaring it a standard. But if
you wanted it to be a recognized authentic open standard, you'd have to
allow a few years to establish consensus, go through the formal balloting
process, and get the result certified by ANSI, then start on the
international scene.

But most other companies will save both money and time by using standards
everywhere they can, and only custom-designing those features that are
essential to the value-added of their product.

I claim that the extreme versatility of SCI (it turned out much better than
we initially dared hope), combined with its support by multiple competing
vendors (we added LSI Logic this month, and there will be more
announcements coming soon) will result in cost-effective high-volume parts
that span the applications spectrum from PCs to supercomputers.

And all you need to do to ride this curve is to stop reading the parts of
the SCI spec that you don't need! In reality, of course, very few people
will need to understand the spec. Since SCI is a 1-chip interface, you just
buy it from some IC vendor whose engineers understood the spec, and you
read their datasheet to learn how to get data into and out of that chip. In
most cases, the user side of the chip will look like a simple bus, very
familiar territory. You generally won't need to know that there are really
little packets running around the links, much less care whether you could
have saved two bits in the command field in your particular application....

There's no reason the SCI chips should be expensive (once the novelty wears
off). They are somewhere between 70K and 100K gates, most of which are used
to implement fast 2-port memory cells! For lower-speed CMOS versions, the
memory cells will be more efficient and the effective gate count should
drop. Sun figures $0.90/kgate now, and Apple figures its SerialBus
interface at around 50K gates will cost well under $15 (along with
connector and cable!) So these ought to be suitable jelly-beans in the
90's.

The strategy is to get the volume up by making a versatile chip, so that
users are still ahead to use it even if they don't use every feature,
because the costs are low. It has worked before--hardly anyone designs
their own UART anymore!

Of course, all this advice assumes you have some time. If you need working
CMOS parts before March 93, you'll probably have to make your own.

--------------------------------------------------------------
-- David B. Gustavson, Computation Research Group, SLAC, POB 4349 MS 88,
    Stanford, CA 94309   tel [phone]  fax [phone]
-- What the world needs next is a Scalable Coherent Interface!
-- Any opinions expressed are mine and not necessarily those
   of the Stanford Linear Accelerator Center, the University, or the DOE.