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

Re: [f-cpu] I'm still in the warmup phase ;-)


i'm back from Köln :-)

Michael Riepe wrote:

Hi Guys,

On Thu, Nov 13, 2003 at 12:13:00PM +0100, Beat Steiner wrote:

The manual has such a nice increment unit. It would be almost a pity to replace it by add units.
But two add units may be better than one add and one increment unit. Is the find-first-lsb relevant
to any software? Hash/compression algos or such?

A second adder could be added :) But since FC0 will be a single-issue
core, that doesn't make much sense at the moment.


however, if one wants a simultaneous add/sub unit (useful in Fourier transforms,
to name an obvious application), it is possible to implement a second ASU in parallel
with the first one.


What about a GREP engine? Suggested operands: byte to match, mask of bits to match, register to search.
Could find the character "p" in the 8 char string "f000-cpu" in some clock cycles. Hmm. Was just an idea. We first
should get a simple design running before adding fancy engines.

we've been there before :-)

We already have such an engine, sort of:

# load parameters...
loadcons $0x7770632d30303066, r1 # that's "f000-cpu"
loadcons $0x7070707070707070, r2 # that's 8 times a 'p'
# and here we go:
xnor.and.b r1, r2, r3
# matching bytes are 0xff, others 0x00

notice the single-cycle operation :-P

Was there already an attempt to implement an f-cpu with CPLDs (complex programmable logic devices)?
If we could couple maybe some 100 CPLDs (FPGAs or whatever), the design could be easily tuned,
debugged and corrected, without carving anything into silicon.
We won't be faster than a pentium pro (clock freq about 33 to >100 MHz?), but the design process
is significantly simplified. Simulation software is nice, but I prefer HW -- its somehow more fun :-).

If you have the hardware and would help testing, that would be great.

however, the portability problem is very critical.

let's imagine for example that someone implements a version of FC0 in one of the boards
sold by http://www.burched.biz/
It's nice, it's cheap and it's fast.
But the entry point for the software is quite high and the written VHDL code
will need many modifications before running on another board, let
alone another family of FPGA, and not even considering another brand.

The best way would be to have one board from different manufacturers...
but that's even more expensive. I wish that this situation will unfold soon.


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