[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Jun 2011 21:02:48 +0400
From: Solar Designer <solar@...nwall.com>
To: crypt-dev@...ts.openwall.com
Subject: Re: EskBlowFish with RAM results
Yuri -
On Sun, Jun 05, 2011 at 02:21:33AM +0400, Solar Designer wrote:
> Oh, perhaps you're using a 16+2 Kbit BlockRAM per S-box in order to have
> enough read ports for the four S-box lookups to occur in parallel. Right?
I am now looking at these "lite" guides for Virtex-6 and Spartan-6:
http://www.eetimes.com/design/programmable-logic/4015235/Xilinx-Virtex-6-FPGA-User-Guide-Lite?pageNumber=2
http://www.eetimes.com/design/programmable-logic/4015237/Xilinx-Spartan-6-FPGA-User-Guide-Lite?pageNumber=3
It appears that in both cases it should be possible to do all four
Blowfish S-box lookups in parallel, without wasting any RAM. Initially,
I thought that we only had two read ports with Virtex-6's 36 Kbit
BlockRAMs, and that this was reduced to one read port when we choose to
have 18 Kbit BlockRAM "halves" instead. However, these "lite" guides
suggest that we have two read ports per 18 Kbit BlockRAMs as well.
Well, the Virtex-6 one is somewhat unclear on that. With Spartan-6,
everything is twice smaller, whereas the port count stays the same, so
it is more obvious that we can do it on Spartan-6.
You have:
module RAM
#(parameter DATA_WIDTH=32, parameter ADDR_WIDTH=10)
Maybe you can try ADDR_WIDTH=9 and try to have dual read ports for that?
Then try to synthesize for Spartan-6 (must work) and Virtex-6 (might work).
Another curious detail:
"An optional output data pipeline register allows higher clock rates at
the cost of an extra cycle of latency."
I think we'll need to make use of this, by including at least two
EksBlowfish instances per state machine.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
