Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131030152315.GC28785@openwall.com>
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.