Date: Sun, 20 Jul 2014 22:33:11 +0200 From: Katja Malvoni <kmalvoni@...il.com> To: john-dev@...ts.openwall.com Subject: Re: ZedBoard: bcrypt ᐧ On 20 July 2014 19:08, Solar Designer <solar@...nwall.com> wrote: > > > > I'll go for 5 BRAMs/instance with storing initial S-box values across > > > unused halves of 4 BRAMs holding S-boxes. This way, initialization will > > > require 256 clock cycles. I'm storing 2 S-boxes in higher half of each > of 4 > > > BRAMs. Initialization data is stored twice but I can copy it in > parallel > > > for both instances. I don't use additional BRAMs and although > utilization > > > will be higher, it won't impact max core count (wider buses were used > in > > > 112 instances approach and core count was limited by available BRAM). > > > > This is harder than it looks like... The first time I run john, first > hash > > is computed correctly and the next one is wrong (fails on get_hash(1). > > After that, it fails on get_hash(0) and computed hash is different > every > > next run. If I reload the bitstream, computed hashes follow the same > > pattern as in previous runs so it seems as initial S-box values have been > > changed. However, in simulation initial values do not change during > > computation and every time I store something to BRAM, I set only address > > bits 8 to 0 to make sure only lower half is modified. Also, before > anything > > is assigned to address bus, it's set to 0 so bit 9 is zero anytime I > write > > to BRAM. I tried two approaches - using readmemh function with my code > > which infers BRAM and using Coregen to generate IP cores with initial > BRAM > > values. > > Weird. Are you sure you're not leaving bit 9 floating at any time that > you access BRAM? "before anything is assigned to address bus, it's set > to 0" doesn't feel like necessarily implying "so bit 9 is zero anytime I > write to BRAM". > I am. That code is implemented as combinatorial logic and looks like this: always @(*) begin ... addra_S1 <= 0; addrb_S1 <= 0; addra_S2 <= 0; addrb_S2 <= 0; addra_S3 <= 0; addrb_S3 <= 0; addra_S4 <= 0; addrb_S4 <= 0; ... else if(state == STORE_L_R) begin if(ptr < 'd18) begin ... end else if (ptr >= 'd18 && ptr < 'd1042) begin if((ptr - 'd18) < 'd512) begin ... addra_S1[8:0] <= ptr - 'd18; addrb_S1[8:0] <= ptr - 'd17; addra_S3[8:0] <= ptr - 'd18; addrb_S3[8:0] <= ptr - 'd17; end else begin ... addra_S2[8:0] <= ptr - 'd530; addrb_S2[8:0] <= ptr - 'd529; addra_S4[8:0] <= ptr - 'd530; addrb_S4[8:0] <= ptr - 'd529; end end end end These assignments before if statement are replacing default statement. Otherwise the tool would complain there exist undefined states in the process. 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.