[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hints?
On Wed, Oct 10, 2001 at 05:10:36PM +0200, Andreas Romeyke wrote:
[...]
> Hmmh, If we cannot use 4b3t, because ternary logic with CMOS is
> impossible, what are the args against a highspeed serial bus with 2 wires?
We won't get the transfer clock far beyond 1 GHz, and it takes 64 clocks
to move a single operand to/from an EU. That's 128ns of additional
latency for *every* operation (assuming that multiple operands/results
use separate buses), and 64ns before we can issue another instruction
for the same EU.
> On every lecture about hf-technology or highspeed-data-transmissions you
> find a lot of problems with wider bus-topologies and the problems with
> "uebersprechen" and capacity on bus will increase if number of lines and
> frequency increase, and we want use a very wide bus aka x-bar...
"crosstalk" is the word you were looking for :)
You forgot another important factor: bus length.
> You know about impulses -> system -> reaction chain?
I guess I should ;)
> > >> 2-wired bus with +high, low and -high levels are very fast, because we
> > >> have signals like this:
> > >> a: +high low -high +high -high low
> > >> b: -high low +high -high +high low
> > >> so the sum of levels on a and b are always zero.
> > so what ?
>
> There are less interaction with noises and less iradiation.
>
> > >> size_of_register
> > >> - ---------------- * 3 => bits/1ms + overhead_of_headers
> > >> 4 * (sum of EUs)
> > >
> > >That's 6 times the EU clock if there are 8 EUs... and if an EU runs at
> > >1 GHz, your serial bus will run at 6 GHz?!
>
> 1GHz on X-Bar is more complicated than 10 GHz on a serial bus.
If the serial line is point-to-point, well-terminated (with a well-known,
fixed impedance) and uses low-swing differential signalling with pulse
shaping (to remove the higher-level harmonics of the digital signal).
> > we can't do that. F-CPU is meant to work at the maximum clock speed
> > already. The logic behind that is : if one part of the device runs faster
> > than the rest, why can't the others run faster ? Furthermore, having
>
> There are advantages, IMHO:
> - - more robustness than x-bar against noises and iradiation
> - - less logiccells
> - - less routing-problems
> - - less floor space
> - - easier to extend, if number of units wil grow or if registersize
> increase
>
> > everything fully synchronous and with one clock only is so much easier
> > to debug and understand.
>
> The serial protocol can be used to synchronize units too.
> To understand the protocol/serial bus, you need only a timing diagramm.
> To debug a serial bus, you must only add a serial/parallel-converter or
> use a logic-analyzer/protokoll-analyzer...
>
> Also if there is no need to use a serial bus between units, it could be a
> good way to interact with f-cpu, IMHO.
I proposed a differential, unidirectional, point-to-point serial link
(transputer-style) for the F-BUS interface months ago. And my arguments
were very similar.
> > >> Remember, a parallel bus is a capacity and frequency-sensitive and costs
> > >> many of logic (see X-bar or Shifting-unit).
> > >Buses are evil anyway, whether they have 2 lines or 200 ;)
> > like evils, they are unfortunately necessary ...
> > "il faut de tout pour faire un monde"...
>
> Your/MRs opinion is not substantiated. Also remember serial bus in
> Firewire, USB, Serial-ATA, Maple-Protokoll (Dreamcast) and so on...
That's an *external* serial "bus" (actually a point-to-point link, IIRC).
I could also add Fiber Channel, Twisted Pair Ethernet, RS-232 and many
others to that list. The only internal, serial, *real* bus (with an
arbitrary number of members connected to the same wires) I remember is
I²C, and it's pretty slow.
Buses suffer from lots of problems, no matter whether they're serial or
parallel. Pairs of unidirectional point-to-point links are much better,
but you'll need hubs/switches/crossbars to connect more than two units.
Anyway... I like your new architecture (if you remove the S/P and P/S
converters and perform the operations on-the-fly ;), but it's unlikely
to be used in the F-CPU. It just doesn't fit into the Grand Plan(tm).
--
Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
"All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/