Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Nov 2013 17:06:07 +0100
From: Katja Malvoni <>
Subject: Re: ZedBoard: bcrypt

On Wed, Oct 30, 2013 at 7:07 PM, Solar Designer <> 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%


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.