Re: [f-cpu] F-CPU architecture...

[Yann Guidon <whygee@xxxxxxxxx>]

hi !

Tobias Bergmann wrote:

> Yann Guidon wrote:
>
> > First reason : FC0 will certainly "live" as a FPGA in the beginning,
> > so no need to make exhaustive failure verification.
>
> Do not skip testability issues just because your prototype stage will 
> be FPGA! The LEON made this mistake and was hard to port to ASIC!

don't worry, the BIST is an integral part of the architecture.
it's just that we need to find a way to verify the chip "when" in ASIC form,
so it does not use any gate in FPGA. A flag in the config file does this.
The other trouble is that, knowing how the SW world works,
ROM space will never be enough (who remembers the Xbox
fiasco ?). So to avoid bloat, the idea is to create a kind of LFSR
that sends pseudo-random signals to all units,
and reuse the integrated POPCOUNT unit to create a "signature"
that will be checked at the end. That's simple, fast, rather efficient
but the problem is to generate a LFSR that will give 99% coverage.

So, in production, we can resort to a second level of checks,
using specific code loaded from outside in the cache.
but no need to do these extensive checks at every reset, right ?
Once a chip is considered "good", it usually remains so for a long while.


> > Second reason : i had found, years ago, how to create the BIST
> > using a FMS (some hundred thousand cycles are enough, the key 
read : FSM (sorry)

> > is to find in which order to send signals through the pipeline).
>
>
> My collegue develops a technique to test a processor via a Software 
> Based Self Test that yields very high fault coverages at low power and 
> short test times.
> It will be general enough to apply to F-CPU in about a year. She's 
> currently working with a simple RISC and the LEON2.

i've read some papers about it, years ago.
Some even proposed to include specific instructions
to help "boost" the coverage.
Anyway, the POPCOUNT unit is an integral part
of the system. It is not only useful for crypto, it also
help in signature compression (it takes 2 operands
from the data bus, XORs them together, yields a 6-bit
result, and this goes to "disturb" a "freewheel" 64-bit LFSR
(which can also serve as a weak pseudo-random generator
in practice).

> > Third reason : RAM is better and cheaper. 
hence resorting to the SW mode that you mention, but in production only.

> > And I think that bootstrapping the CPU with the help of an external,
> > cheap microcontroller is a good help.
>
> I'm even thinking about putting a simple RISC like a LEON on die as 
> well and let it handle the I/O and selftest. If done it switches to 
> I/O pass through mode :)

i'm working on http://f-cpu.seul.org/whygee/VSP/
which can do exactly that. But not on the same die.

> And don't tell me: "OMG. So much die space wasted!" If F-CPU is to be 
> high end then the size of a wasted LEON is almost 0 in comparison!

it's not a matter of dies space. F-CPU is not /that/ large compared
to today's cores. It's a matter of I/O.
Multicore dies are fun as long as one is not limited by memory bandwidth
and pin count. F-CPU is meant to be cheap, so this matters a lot.

If you can afford only 250 or 300 pins for the package,
what is better ? A large die with several cores (expensive
because exponentially more prone to defects) which compete
to access external memory ? Or a cheaper, smaller die (well,
it's just a consequence of only one core) with all the memory
bandwidth for itself alone ? If one is going multi-core,
the second solution looks better to me : cheaper, more scalable
(you can tune how many CPUs you want), and all the cores have
their 'private' memory bandwidths, which becomes scalable
(just add modules containing CPU+memory).
If you have spare die space, just boost the L2 :-)
(i have an idea about how to make this scalable, fast, multiport
and more importantly : fault and fault tolerant :-P)

You know that the largest bottleneck in recent CPUs
is the external memory bandwidth. If you add more cores
on die, you better have to execute CPU-bound code.
but most today's codes are memory-bound.

However, nobody will come after you if you put
X FC0s and Y LEONs on the same die/FPGA
(whatever X and Y). I simply wonder how you will feed
them with instructions and data without resorting to
expensive multi-chip modules :-P

> bis besser,
> Tobias 

YG

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