[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-Y8AkfeFAbhsH6_n-aEwE9mOjvenCdskqdgBxG6OHTpYg@mail.gmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
