[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] RC5, F-CPU and srotl



On Sat, Apr 13, 2002 at 05:03:10AM +0200, Yann Guidon wrote:
[...]
> I read articles about RSA accelerators in ASICs or full-custom designs.
> DES or RC5 cores might be available but not much else.

I guess AES (Rijndael) will follow soon.

> > > > What's a 64-bit CPU good for, compared to a 32-bit one? It's not
> > > > necessarily faster,
> > > it can be, as it treats wider data.
> > That's wrong in many cases. Wider data types don't buy you anything if
> > the range or precision of your numbers doesn't grow. But you need more
> > memory to store a variable (which will slow down the program), or you'll
> > have to work with partial registers (which may slow down the CPU). In some
> > cases, SIMD can make the CPU perform better (numeric kernels, multimedia
> > stuff), but a more general application with lots of (integer) add, shift,
> > compare and pointer operations won't run faster on a 64-bit machine.
> 
> then, computation time can be reduced by grouping CPUs.

In the general case, no -- because you can't parallelize most of these
applications. Grouping works fine only if you can divide a problem in
`partitions' that can be solved independently (like rc5, seti, rendering
and the like).

[...]
> > > > > The case of dnet is looking different but i can't involve myself
> > > > > in this now. The case of the SIMD shift has been proved and there
> > > > > does not seem to be any difficulty in implementing it with F-CPU,
> > > > > we simply disagree on a "small" implementation detail :-)
> > > > Huh? No difficulty?
> > > huh, i'll try to make my own shifter... whenever i can :-)
> > With all operations performed in one cycle? I already violated the
> > 6G/10T rule in my design.
> if you can't fit, just pipeline. SHL has some pretty long wires and they
> get longer as the register width increases : you can't stand the frequency
> if the shifting distance is too long.

I know. But my first (two-stage) shifter version had more and even
longer lines, and more crossings. The omega shifter is more regular,
and it will scale much better.

> Maybe a 2-speed shifter is possible ? below 32 bits, it will work in 1 cycle,
> and need 2 cycles for 32 and 64 bits ? this will obviously depend on the
> SIMD+SIZE bits, so it is deterministic at decode time and possible (like the
> add and multiply instructions).

The omega net can be pipelined, but I dont think that adding a `tap'
output is a good idea. It will duplicate the amount of postprocessing
logic, and spoil the regular structure.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/