Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Jul 2014 18:17:52 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt

Katja,

On Sun, Jul 20, 2014 at 04:10:01PM +0200, Katja Malvoni wrote:
> I'll go for 5 BRAMs/instance with storing initial S-box values across
> unused halves of 4 BRAMs holding S-boxes. This way, initialization will
> require 256 clock cycles. I'm storing 2 S-boxes in higher half of each of 4
> BRAMs. Initialization data is stored twice but I can copy it in parallel
> for both instances. I don't use additional BRAMs and although utilization
> will be higher, it won't impact max core count (wider buses were used in
> 112 instances approach and core count was limited by available BRAM).

Sounds fine.  Let's see what clock rate you achieve in this way, and at
a later time(*) you may try the 10 BRAMs/core approach as well, to see
if you can achieve a higher clock rate with twice more instances.

(*) Perhaps after porting to ZTEX, which will be a higher priority for
us (than even further tweaks on ZedBoard) at that point.

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.