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.