[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?
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 10 Oct 2001 email@example.com wrote:
> on top of all that, ternary coding is not suitable for CMOS.
> read some electrical/electronical books about this subject
> (i have some courses about it currently) : it is not possible
> to have a third stable electrical level in complementary
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?
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...
You know about impulses -> system -> reaction chain?
> >> 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.
> 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
> 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.
> >> 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...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/