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

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

Yann Guidon wrote:
Yann Guidon wrote:
Random pattern test will hardly give you 99% at short test times but you can always prove me wrong ;P
it's not a matter of proving, 99% is here to show that it is never perfect.
it could be 95 or 90%, what the heck ? it's just a boot-time test
that supplements the factory test which is meant to be 101%.

OK. I see. even 98% on a production test is a lot these days.

But this LFSR business has also another function :
reset ALL the registers and other memories
to a known state (usually 0).

that's why the coverage is not so important for the FSM/LFSR.
A multi-cycle approach spares a lot of silicon compared to a huge
RESET signal all over the die.
Plus, we can pre-compute the coverage and the signature
of the BIST on a computer (takes a while, but worth it).

:) good idea.

Oh I even foresee chips testing themselves continuously during operation.
hmmm you want to run zOS on top of that ? :-P

sure :-P

well, it's a stress-test too, right ? ;-)
and if it runs for 100K cycles, it's just a fraction of second
at real speed, so the "total" quantity of heat can be negligible
(particularly if the test is running at power-up, when the chip is cold).
no worries here.

Well your power supply has to be dimensioned for this worst case as well. Makes it more expensive for no good reason.

I want to get rid of random tests but as written above it's a avlid compromise for now.
at school, i have learnt to make boundary-scan BISTs.
this is a 10 years old technology that consumes space and time
(particularly annoying because FC0 has very short pipeline stages
so adding boundary scan would drop the clock frequency).
So i came up with the current method, built on the existing
POPCOUNT and free-wheel LFSR. They were optional
because it's only a security feature, but they are now necessary
for BIST. This may change if we find something better for FC1
but a freewheel LFSR as well as hamming distance is going to
make F-CPU really attractive to some people so i don't expect
these features to disappear soon...

BTW, how many pipeline stages are there currently? And how much delay in the slowest path?

nice :)
Why not on the same die?
it's a matter of separating unrelated functions.
VSP is designed for slow stuffs, while FC0 is for bandwidth.
so a FC0 chip will contain its private memory interface,
a front-side bus for communicating with other CPUs (think
of a single hypertransport-like) and a dedicated function
(might be 1000BaseT MACs, PATA/SATA, SCSI,
a PCI bridge, a video framebuffer, etc.).
All these work at high speed.

Now, if something slow must be interfaced
(keybord ? mouse ?) there is no reason to let
that interfere with the FC0 directly. So the VSP
handles that (sparing a costly spurious context switch to the FC0)
and enqueues a message to the CPU that will deal with
user interaction. Keymaps and all these stuffs can be processed
in the VSP and message-passing is more suitable than interrupts
for such things.

So it is a IOE (Interrupt Offload Engine) to coin a new term for it. SCNR :>

I said high performance and I mean it. 1000 pins + >10GB BW.
hmmm the price of a 1K pins FPGA is out of reach of many's pockets.
AMD and Intel can drive that low thanks to huuuge volumes and
integrated fabs. If you're rich, no problem.

I'm not rich but I have quite nice FPGAs at work.

however, as you have seen, FC0 and F-CPU in general is just a core.
you can use this to build more complex chips, as long as you provide
a specific set of signals to its interfaces (clock, power, and data/addresses to the bus).

That's good to know...

but you know how things go : look at the Alpha.
I believe that the FC0 can reach success because
we hit a price/complexity/performance point that
is on par with other proprietary "embedded processors"
(made of ARM (there are 64-bit versions), MIPS,
SH-x or others). These chips sell for 5 to 10$.

OK. So FC0 competes with embedded chips. Fine with me.

simple, given the constraints :
- maximize die utilization despite fab defects
- one SRAM array is used or provided by the fab (more could cost more in royalties)

So the idea is to reuse the L1 arrays (there are data and instructions caches already).

* These arrays are connected to several busses, in case one branch of one bus is defect.

* Several buses signifies : multiple simultaneous paths to multiple memories,
so the architecture looks as a multiport array from the outside.

* in the fab, the tests will check which array is defect. when one array is found faulty,
a fuse will remove Vcc to avoid shorts and reduce consumption. The bus driver for this
block is also disabled to avoid troubles.

* This also lets us "optimize" the L2 quantity depending on the fundry parameters.
we're not bound to 2^N architectures, but simply multiples of the L1 array size
(so the die surface is optimally filled).

* from there, we can also tune power consumption with software-accessible
bits to turn power on/off for each L2 sub-block.

It is certainly going to be less efficient than specific L2 SRAM cells
(which are designed for power efficiency and compactness). But it's an interesting
thing to try anyway.

yup. :-)

yup, but the memory speed does not increase as fast as CPU speed.

Bandwidth (almost) does.

"latency tolerance"... tell that to end users ;-P
and you ALWAYS need bandwidth
(even, and particularly, when you try to hide latency).
"You can't fake bandwidth" (Seymour C.)

nice one.

FC0 (the current core) is designed for simplicity and raw computations.
FC1 may be more subtle than that (i have some ideas).

Looking forward to FC1. :-D

But it is SIMPLE. And that's good. A very good test case for free HW development.
test case ? it's not a test IMHO....
particularly because we have to reinvent everything from scratch.

I meant there haven't yet been many distributed free HW projects. Some one-man shows and some licence changes of commercial products.

bis besser,

I'm going away for the next days, have fun !
have fun!
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/