Re: [f-cpu] X-Bar replacement and PoC of massiv-parallel-computing, hint

[Yann Guidon <whygee@f-cpu.org>]

hi !

Marco Al wrote:
> 
> From: <whygee@club-internet.fr>
> 
> >  - i don't think that internal databuses can use LVDS :-)
> 
> For what its worth the Russians (Elbrus) were going to use it for the E2K :)
> (And although I cant find it right now I distinctly remember someone
> knowledgable downplay that fact on Ace's by pointing out it had been done
> before.)
> 
> "Circuit Design
> Advanced circuit design has been developed in Elbrus project to support ex-
> tremely high clock frequency implementation.It introduces two new basic
> logic elements (besides traditional ones):
> 
> - universal self-reset logic with the following outstanding features
> . No losses for latches
> . No losses for clock skew
> . Time borrowing
> . Low power dissipation
> 
> - differential logic for high speed long distance signal transfer
> 
> This logic supports 25-30%better clock frequency compared to existing most
> advanced microprocessors."

BTW i still have to see one to be convinced :-PP </troll>

> Personally I think it might be well suited for a large X-bar, would require
> simulation to find it out for sure one way or the other, but you probably
> need to design your own cell's (standard I/O LVDS cell's wont do ... you
> dont need most of the signal conditioning and it doesnt need to drive nearly
> as much current as for an external connection Id guess). But for a high
> performance processor some custom work will always be necessary.

in the frame of the F-CPU, i don't think that we can develop this.
First because the application range is too wide : sae-of-gates,
FPGA, full-custom or cell library-based... we have to design
one-fits-all source files in as high a description level as possible
(Nico made this remark again recently to me ;-D).
Second because it requires very high skills and technology-dependent
ressources : it wouldn't be done and would not be portable.
Unless a genius comes and provides them. If we can't get them,
there's no time to loose on annex problems (we design a CPU, not
a silicon process ...) : there are already too many things to do
and too few people who "really" work :-(
Third, the "Xbar" is implemented in FC0 as a 2-level MUX.

However, there would be one solution to speed up this critical part :
use 3.3V locally (if we use ie a 2.8 or 2.5V technology).
I have "learnt" this morning that the rising/failing time of CMOS
gates that load capacitive/resistive depends on the Vdd.
The buses of the "Xbar" are long and very resistive : high current
and high(er) voltage (than "core logic") is probably necessary
to compensate...
Of course this is not possible in FPGA or precharacterised sea-of-gates.
I don't even think that we can use this with Alliance (at least without
seriously hacking into the netlists :-(). 

ok i gotta sleep ... i can't answer everything tonight or i'll never
wake up early enough tomorrow :-/ we will "synthesise" an Am2901
4-bit slice EU with alliance. a real mess but i have to go through that...


> Marco
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/