Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Jul 2014 16:01:43 +0200
From: Katja Malvoni <>
Subject: Re: ZedBoard: bcrypt

On 6 July 2014 14:16, Solar Designer <> wrote:

> On Sun, Jul 06, 2014 at 01:20:20PM +0200, Katja Malvoni wrote:
> > On 6 July 2014 12:55, Solar Designer <> wrote:
> > Perhaps you can achieve a higher clock rate by introducing an extra
> > > cycle of latency per data transfer during initialization and maybe
> > > during transfer of hashes to host as well?  Anyway, maybe it's better
> > > to consider that after you've implemented initialization within each
> > > core as I suggested.  It depends on which of these things you feel
> > > you'll have ready before your trip to the US.
> >
> > I'm not sure that would help. Routing delay is 90.4% of longest path
> delay
> > and I can't use any frequency, just ones that can be derived from PS. So
> > the next one after 71.4 MHz is 76.9 MHz. With 90% of delay being routing
> I
> > don't think it is possible to improve logic to achieve 76.9 MHz.
> I don't understand your line of thinking here.  It feels wrong to me.

It is wrong. Adding extra cycle of latency during data transfers means
introducing registers which will "cut" the routing at some point so it
should reduce delay.
In the above statement, I was talking about reducing delay in logic (not
affecting routing) in which case it wouldn't have big impact on the longest
path delay (13.879ns (1.332ns logic, 12.547ns route)(9.6% logic, 90.4%
route)). But this doesn't apply to your suggestion.


Content of type "text/html" skipped

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.