[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-ZThWx5o39HoGKZ7VDY=XYwbnbJs-kanA6g5KVzE6BQLw@mail.gmail.com>
Date: Sun, 6 Jul 2014 16:01:43 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt
ᐧ
On 6 July 2014 14:16, Solar Designer <solar@...nwall.com> wrote:
> On Sun, Jul 06, 2014 at 01:20:20PM +0200, Katja Malvoni wrote:
> > On 6 July 2014 12:55, Solar Designer <solar@...nwall.com> 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.
Katja
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.
