[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Oct 2013 19:23:15 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt
On Wed, Oct 30, 2013 at 02:07:28PM +0100, Katja Malvoni wrote:
> On Wed, Oct 30, 2013 at 10:17 AM, Solar Designer <solar@...nwall.com> wrote:
> > On Tue, Oct 29, 2013 at 07:48:35PM +0100, Katja Malvoni wrote:
> > > At the moment performance is 602 c/s, maximum frequency is 100 MHz.
> >
> > What has contributed to doubling the performance (since your previous
> > report)? I guess it could be performing the 4 S-box lookups all at
> > once, but then you're giving high numbers of cycles per round anyway:
>
> That is correct, since most of the RAM is unused I'm storing each S-box
> twice.
Now I am confused. Why would you need to store each S-box twice in
order to perform all four lookups at once? I think it'd be sufficient
for you to allocate no more than two S-boxes per BRAM (since you have at
most two ports per BRAM, at least physical), but I don't see any need
for data duplication.
Also, weren't you already at 3 cycles per Blowfish round before this
change? If not, then how many cycles per Blowfish round did you have in
the revision that achieved ~300 c/s using 14 cores at 100 MHz? You
still have 14 cores now, right?
Yet another thing I found confusing is you mentioning some high offsets
into a (logical) 64 KB BRAM. Is this some extra BRAM you're using for
host to FPGA transfer only?
Can you explain these things?
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.
