Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 22 Apr 2014 02:02:48 +0400
From: Solar Designer <>
Subject: Re: ZedBoard: bcrypt

Hi Katja,

On Mon, Apr 21, 2014 at 11:46:35PM +0200, Katja Malvoni wrote:
> During last weak I had some other obligations but today I finally found
> time to implement this: 28 cores fit (112 instances), limited by BRAMs.
> Utilisation is:
> Number of Slice Registers:                        13,445 out of 106,400
> 12%
> Number of Slice LUTs:                              47,953 out of  53,200
> 90%
> Number of occupied Slices:                       13,066 out of  13,300   98%
> Number of RAMB36E1/FIFO36E1s:           140 out of     140  100%


Meanwhile, I got another idea for the instances/cores/cycles layout
today - will describe it separately.

> On my ZedBoard, I get performance of 1855 c/s on self test - lower than 70
> cores because of data transfers.

And it's unreliable during actual cracking, right?

> I'm not able to test this on the Zed
> system. I think that system reboots when I try to run self test. Connection
> is closed and when I ssh again, there is no /dev/xdevcfg file and I have to
> reload the bitstream.
> When I try other tests on my ZedBoard it locks-up.

Yes, "zed" does reboot.  You can check the output of "uptime" to make
sure (it shows, naturally, how long the system has been up for).

> I think it's reasonable to stop optimising at this point. Having 6
> instances/7 BRAMs per core would allow to fit 120 instances but since 112
> instances draw too much power, 120 won't work properly either. But I'll try
> to generate bitstreams for lower number of cores, I hope it will work for a
> number larger than 70.

Yes, you may.  And the data transfers may be optimized to regain the
speed.  However, you're right: this is one of the many dead-ends, albeit
a nice one. ;-)  We need this stuff on ztex boards.

Oh, in those tweets you couldn't read (sorry!), Sylvain suggested that
we measure Zynq core voltage via its built-in ADC.  Can you try to
include this in a bitstream?  Is this voltage directly available as ADC
input or do we need to connect it physically?  (We can ask Sylvain to
clarify whether he meant a purely software thing or also an added wire.)
I think this isn't worth much of your time, given that you need to
refocus on ztex anyway, but it's a nice experiment and a useful tool for
when we return to Zynq just to include "final" speeds for it on a
presentation slide or whatever.



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.