Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Parallel vs Serial speed



On Wed, Feb 07, 2007 at 10:31:52AM -0500, Matthew Gillen wrote:
> markw at mohawksoft.com wrote:
> > It has nothing to do with synchronization, if anything, serial is a harder
> > interface because it requires circuitry or software to convert it to
> > parallel data from serial data.
> 
> I'm sure you're correct about all the voltage analysis, except that "harder"
> from the above must not equate to "cheaper", since you don't see any computers
> with Universal Parallel Bus ports...
> 
> /Something/ about parallel interfaces obviously makes them more expensive than
> serial for the same speed, and I didn't see anything in your post that
> explained /why/ "High speed drivers are expensive" compared to serial ones.

It's the wheel of reincarnation.

Start with a new interface. We'll call it "World Data
Interface", or WDI. WDI is supposed to connect a host and a
peripheral at speed 10, bidirectionally. It uses, let's say,
7 conductors. One for power, one for clock, two for data,
and three grounds.

A generation later there's sufficient market success to justify
upgrading WDI to WDI2. WDI2 needs to operate at speed 100, or
else it's not worthwhile. And it should be at least reasonably
backwards-compatible with WDI.

So the clockrate is pushed by a factor of 5, that being all that
can really be handled right now, and the data path is extended
to four conductors on half-size pads, so that a new device
drives them independently but an old device drives two sets of
xmit and listens to two sets of receive. WDI2 devices are now 10
times faster than WDI devices.

Next generation, everybody wants a speed 1000 device. WDI3 adds
another conductor to the clock, and changes the data path and
the clock so that they now run 20 times faster than WDI2, but
use inverted signals on the secondary pads so that the trace
length can exceed the six inches it would otherwise be limited
to. And the conductive path requirements are tightened, too.

Next generation, we try for WDI4. Now no one needs WDI compatibility,
but we still need to support WDI2 and WDI3 devices. WDI4 has a host
implementation that can sense when a WDI2 device is connected (clock
limited to 5x) and when a WDI3 device is connected (driving xmit1
without an inversion on xmit2 doesn't work). WDI4 splits and hijacks
two of the grounds to add two more recv, two more recv-inverted, and
the same for xmit. Clock is pushed by another factor of 4, and
so WDI4 is at speed 12000 with clock 400x WDI. There are length
limitations and probably termination issues.

While WDI6 is being designed, backwards compatibility is tossed
out and the name is changed to SteamStream. SteamStream uses a
packetized protocol with built-in error correction and requires
a new connector... power is dropped off the spec, and the system 
is now self-clocking at clock 20000x WDI, but only on one pair
of xmit/recv, and overhead reduces effective data rates to
14000x WDI.

Next generation parallelizes SteamStream into FireHose, carrying
16 bits in each direction on a 40-conductor path, dropping
overhead but keeping the same clock rate for an effective speed
of 252000x WDI...

-dsr-


-- 
_.. ___ . ...   _ .... .   _. ... ._   ._. . ._ _..   _.__ ___ .._ ._.
__ ._ .. ._.. ..__..   _ .... .   .._. _... .. ..__..
http://tao.merseine.nu/~dsr/eula.html is hereby incorporated by reference.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org