|
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.