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

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

hi,

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.
>  
Certainly.

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.

YG

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