[Cryptech Tech] Fwd: Second hash via EIM

[Paul Selkirk]

On 02/08/2015 06:56 PM, Шатов Павел wrote:
> I've attached a modified version of coretest_hashes branch of the
> test/novena_base repository.

Thank you. I've merged it and pushed the changes. Since it seems to be
stable, I'm going to merge it to the master branch next.

> 3. I've figured out why you guys could not use read and write signals
> from the arbiter the way they were supposed to be used. I was wrong when
> I expected Joachim's cores to have registered outputs. They have a
> combinatorial output in fact. EIM arbiter's minimum latency is 1 cycle,
> so we have to register data coming out of cores. I've added these three
> lines to every core wrapper (sha1.v, sha256.v and sha512.v):
>   reg [31 : 0]   tmp_read_data_reg;
>   always @(posedge clk) tmp_read_data_reg <= tmp_read_data;
>   assign read_data = tmp_read_data_reg;

Ah, okay, that makes sense. OTOH, adding that extra delay makes the
wrappers not work for I2C (I read all zeros), so I added the SHA
wrappers to the local verilog directory. In the long run, we may want to
change the coretest_hashes mux to match this design.

Since I was messing around with wrappers anyway, I changed them to use
Variable Part Select for the block and digest, as Bernd suggested a
while back. Joachim and/or Pavel, please check and see if this makes
sense to you.

> 4a. Core number 0 was added. It is not an actual HASH core, but a set of
> global (board-level) registers. I've added three registers so far: board
> type, bitstream version and one writeable dummy general-purpose register.

That makes sense and costs almost nothing.

> 4b. Core instantiation was made conditional to allow selecting of what
> cores to actually implement. We can have a project that offers a large
> number of cores, so people can disable unnecessary cores to speed up
> compile time and to save some slices for something else.

Also makes sense.

> 4c. I have disconnected .error() output from cores. As far as I
> understand it gets asserted when some non-existent register is being
> addressed. In most projects that I've seen writes to empty regions of
> memory are discarded and reads return zeroes. If you really need this
> kind of error checking, please re-connect this output as needed.

I'm all for simplifying the design.

> 5. TC11() was added to hash_tester.c to check that we can read global
> board-level registers and that we have access to segments other than
> HASH. The last check reads dummy registers from RNG and CIPHER segments
> (which are just templates now), this effectively tests the 3 new added
> address bits.

I moved/renamed this to TC0, since it's a basic sanity test.

> Joachim and Paul, last time we agreed that I don't need write access to
> the repository right now. Could you please evaluate my changes and
> upload them if you agree with them. Thank you.

If you continue on the project, you should have write access. That was a
large chunk to digest as a single commit.

				paul