[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, 10 Oct 2001, 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?
Everything is possible, but making those Serdes blocks is not a trivial
task (read: full custom layout task). You do not just drop them to the
silicon, also they are not trivial to design. There are all kinds of
problems related to very high speed design.
> 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...
Also routing of those high speed serial links is very difficult. You
should sometimes ask from a backplane designer about all the nice problems
of high speed serial links. Same problems will be inside the ASIC also.
> 1GHz on X-Bar is more complicated than 10 GHz on a serial bus.
I'm not so sure. In fully synchonous logic the state of the art layout
tools will automatically do all kinds of balancing. For example they can
do rough P&R runs, add cells to buffer things and to slow them down, then
do routing again and iterate that until the timing is correct. Think that
as static timing analysis during P&R. Of course the busses are not easy to
design at those speeds, but they are doable.
> 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...
How do you by the way sychonize the byte alignment in the serial link.
That needs some nice overhead to the protocol. I have seen serial
protocols designed and they are nothing but trivial, especially the byte
and frame alignment. 8b/10b coding is one nice solution but not the most
> 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.
Good luck with 10GHz signal in FR4 substrate. I think the upper limits of
that material is in the ballpark on 3.125GHz. You have better luck with
teflon or ceramics. And when the data is splitted to many serial links
the problem of byte alignment becomes even more difficult (each link have
to be synchonized by itself and then all of the links bundled in correct
Mr. Kim Enkovaara | email@example.com | Microelectronic Riemannian
Vasamatie 1 C 16 | IRC: embo | curved-space fault in
02630 Espoo | | write-only file system
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/