[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] F-CPU SoC





2015-04-01 13:30 GMT+02:00 Kim Enkovaara <embo@xxxxxxxx>:
On Wed, 1 Apr 2015, whygee@xxxxxxxxx wrote:

ÂSo I'm proposing for the following - let's think about how a F-CPU-based
ÂSoC should look like.
The trick is : it will look like what is needed in each specific case.
There will be no "one true" F-CPU SoC, but adaptations of a generic model...

The SoC aspect is the most important one. In the embedded market the chip peripherials have been the most important thing to sell the design. Intel has been the only succesful one to make chips with very bare bones peripherials (Atom has them for some markets).

And the future looks like the switch fabric between the cores/chips is a major competition area. There are already chips under work with hunderds of cores which have cache coherent memory and very low latencies inside the chip, and also possibility to connect multiple chips together. And those cores usually have zero latency thread switching so the parallelism is exploding. Of course I'm looking this from networking side, but the designs also aim to other areas like datacenters.

So the current innovation is in the switch fabrick, memory hierarchies, thread switch latencies etc. The core instruction set is not that interesting. I would even say that ARM and x86 instruction sets will kill all others quite quickly, it is already visible (PPC is slowly dying, MIPS is not doing that well, FPGAs get ARM hard cores and their soft cores become less important etc.).

ÂI'm totally convinced that a single design won't
Âbe able to answer all needs, so probably the most logical approach is to
Âdefine several different SoC types and then discuss each F-CPU feature
Âand how it can fits into each specific context.
So more or less it's about creating a catalogue of blocks and units
that work along/with the CPU. Users will pick the ones they need...
Users would even want to chose the units and configure them
with an interactive graphic tool, no ? :-)

The bus structure for that is critical and that is not simple thing to solve. Many companies have poured a lot of money into this. Single core is not interecting anymore even for very low end.

Multi core are often under used after 4 cores maximum. It's easy to put 4 or 8 core, when you have done the job for 2. But, it's very hard for a programm to correctly use it. Good isa could avoid to use complexe technique to have out of order cost for performance.

In the futur, the way to go, i think is buldozer like technologies, it's like intel multithreading but with more ALU. You could imagine a see of operators, how many register bank than there is cores, and one big memory controller.

Â

ÂIn addition to the SoC topic - I personally think that a CPU design is
Âless and less important only by itself,
I agree. The tools are critical.
in F-CPU, the tools are not just critical, but they must also be free.

I also agree, as I see many vendors ditching their own architectures.

Maybe we should start with a github repository and a list of tools.
Â

Âand there are tons of other
Âblocks that need to orchestrate perfectly with the CPU in order to
Âachieve a usable performance out of the system. So would be great if we
Âconsider touching the SoC topic sooner than later.
I agree, so let's move on to the F-GPU implementation.

Or F-NPU, as network processing is also quite hot topic ;) And the interactions are pretty similar as GPU can also be used for network acceleration.

--Kim
ps. still the same e-mail address, but not that involced in cpu designs anymore, currently chief architect for terabit level routers ;)

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