Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Nov 2013 17:06:07 +0100
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: ZedBoard: bcrypt

On Wed, Oct 30, 2013 at 7:07 PM, Solar Designer <solar@...nwall.com> wrote:

> On Wed, Oct 30, 2013 at 06:55:10PM +0100, Katja Malvoni wrote:
> > With only one core utilization is:
> > Register: 5%
> > LUT: 15%
> > Slice: 25%
> > RAMB36E1: 6%
> > RAMB18E1: 1%
> > BUFG: 3%
>
> Thanks for this utilization data.  Note that there's probably quite some
> per-core overhead, including in Slice utilization, for the initialization
> of the per-core BRAMs from the BRAM that you use for data transfer from
> host.  You probably have mux'es in each core, since you're already using
> all of the per-core BRAMs' ports for computation.  ... or are there
> write ports separate from the read ports that you use for computation?
>
> > Two AXI buses and DMA take away some space (I think around 20% of Slice
> > utilization). I'll try to think about other possible ways of host FPGA
> > communication.
>
> OK, but:
>
> I am not concerned about the 25% Slice utilization above as much as I am
> about how much of the remaining 75% is possibly consumed by the overhead
> needed to initialize the per-core BRAMs.  I wouldn't be surprised if
> e.g. one third of the remaining 75% is consumed by such overhead.
>

If I generate bitstream for only one core with bcrypt logic only (without
BRAM initialization and storing results) utilization is:

Register: 4%
LUT: 9%
Slice: 11%
RAMB36E1: 6%
BUFG: 3%

Katja

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ