Re: Fully unrolled RC5 on FPGA

I think it is critical that we build something that is small and works
stand alone as well as something that can be clustered.  The design laid
out in the paper requires both the back plan and the cards.  If we were
building a single system that would be fine, but for flexibility I think
we need a board that can work both ways.  I had been thinking of
clustering, but on a somewhat small scale.  Specifically, with a USB
device we could hook several to a single PC.  However you could quickly
get far too many USB hubs and cables to make the system manageable and
of course there is a physical limit to how many devices can be connects
(I forget what the number is).  

But maybe we could build a small board that had a daisy chaining
capability.  So the first node would be the master node and it would be
connected via USB to the PC.  Each board would have a in and out
connection for daisy chaining.  This would be some type of short range
serial or parallel bus.  We'd probably have to limit the number of nodes
in a chain to keep the bandwidth required simple.  This would allow us
to get several nodes on a single USB connection.  

I've been thinking that very small bandwidth but that depends on how
flexible we want this platform to be.  It sounds like at the rates that
Guerric is getting we'd need about 1 block of keys per second to a node.
Since a block of keys is just the first key and the length this is very
low bandwidth.  However I'm thinking that we should plan for something
like 20-50 k bits/s, so that we have flexibility.  I'm hoping to hear
comments on this assumption.    

If we use a PIC micro controller on each board all of the USB and
chaining communication could be dealt with in the PIC.  There are a few
benefits to this approach.  First we can get cheap dev board from
Microchip and others, to prototype all the communication.  Second we
don't take up area on the FPGA for communication (I'm guessing that this
might actually reduce cost at the volume levels that this project would
see).  I've built several hobby projects with these chips and could work
on this part of the project if there is interest in this approach. 

Also to comment on Guerric question about USB, keep in mind that a PIC
micro controller can only handle about 20 Mbps over the USB 2.0
interface.  After all it is a microcontroller :).  

-> Ben

-----Original Message-----
From: hardware-bounces-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
[mailto:hardware-bounces-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, November 14, 2006 8:56 AM
To: hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
Subject: Re: [Hardware] Fully unrolled RC5 on FPGA

Hello,

I think the best thing to do is to wait for partially unrolled results.
This could make possible the use of cheaper FPGA. 
The aim is of course to look at the performances/cost ratio: the fully
unrolled is the most efficient but maybe a less efficient one can fit
on a cheap fpga. In particular, I would like to look at a 1/13
unrolled design (6 Keyschedule module + 1 encrypt module) and a half
fully unrolled design

Probably building boards with cheap spartan3E can lead to an efficient
solution. I think a fully unrolled design is a good point of
comparison, but maybe not the best choice.

A previous work about building clusters of FPGA is available here.
http://www.crypto.ruhr-uni-bochum.de/imperia/md/content/texte/publicatio
ns/conferences/ches2006_copa.pdf

Their solution is interesting but there is two issues:
- They have power problem (to feed all the fpga through the "lane" (or
wire, not sure of the word) of the PCB)
- I think FPGAs are too close in the cluster. As a result, heat
dissipation is not really good and the clock frequency have to be
lowered (they should probably add dissipators and/or fans)

For a homemade board, it is probably better to limit the extra
features in order to limit the cost. If many features are required, it
is probably better to buy a board already available (to limit the risk
and development costs). If the board is too generic, it is required to
provide support softwares for communications, and why not reference
designs, ... (probably not our job).

So what's the best solution?
- building its own small board
- building a kind of cluster (copacobana-like)
- to buy boards from company (I can't find LX40 boards :( )

By the way, a rate of (theoretically) 480Mbps for the USB 2.0 is not
fast enough for general purpose applications ?

PS: I currently can provide the .bit file for devices not available
with the webpack.

-- 
Guerric


_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware
_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware