[Gllug] re: SCSI vs SATA

[Tom Fairbairn]

Well, yes you can embed the clock with data on a parallel bus, but you then end
up with the same clock arriving at different times (even if you're very careful
with PCB/chip layout), which is just as difficult to deal with as multiple
different clocks coming in off separate serial lines.  And it means your data
receivers are no longer in the same clock domain, even though the drivers are,
which means that strictly speaking you no longer have a parallel protocol.
Having multiple sources of the same clock is a bad idea.

Given that there are plenty of standard high-speed serial protocols for the
designer to pick from, it's easier to use multiple serial lines than trying to
define a synchronous send, asynchrous receive and re-synchronise system.

Not sure I explained that too well!





Nix <nix at esperi.org.uk>@gllug.org.uk on 06/12/2004 01:11:07 AM

Please respond to Greater London Linux Users Group <gllug at gllug.org.uk>

Sent by:  gllug-bounces at gllug.org.uk


To:   Greater London Linux Users Group <gllug at gllug.org.uk>
cc:
Subject:  Re: [Gllug] re: SCSI vs SATA


On Wed, 9 Jun 2004, Tom Fairbairn mused:
> With a serial protocol, you can embed the clock in the data signal.

But, er, you can do exactly the same with a parallel protocol: you just
need to have (multi-bit) clock pulses every n-bits-per-wire and buffer
at both ends, syncing on the clock pulses. Unless the individual lines
get seriously out of sync, you'll win.

This is *old*, obvious stuff, so obviously it's been considered and
rejected. What am I missing?




-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug