[Cryptech Tech] Fwd: Re: [Cryptech Core] Fwd: EIM Problems

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

Шатов Павел wrote:
> Hello!
> 
> The question is what the design actually is - What is the actual
> clock speed on the real EIM bus on the Novena.
> 
> This can be easily checked by routing BCLK to some unused pin inside
> an FPGA, which drivers either as a pushbutton or a LED, and then
> attaching a scope to this pin and measuring the frequency. Basically
> you need to add another top-level output port to the FPGA design and
> instantiate ODDR primitive, which is driven by BCLK and connected to
> this new pin. I don't have a copy of Novena board so far, so I can't
> do this myself right now.

Yes, that is a good suggestion. I think there are also test pins
available. I've gotten some good feedback from Bunnie and he suggest
that we adjust the EIM_BCLK to (for example) 66 MHz. That would not only
relax the constraints for the EIM and also allow us to drive the
Cryptech cores with the same clock thus eliminating the need for
handling clock domain boundary issues.

According to Bunnie, changing the clock divisor here from one to two
should change EIM_BCLK to 66 MHz. But we need to verify it.

https://github.com/bunnie/novena-gpbb-example/blob/master/eim.c#L142

Basically we want to take the Bunnie ROMulator design and test that it
works at 133 MHz. Then update the design to expose the EIM_BCLK to an
external pin as you are suggesting.

Then try to adjust the EIM_BCKL to 66 MHz, update the ROMulator design
to match this frequency and verify that the design still works. And
measure the clock.

Then we can move forward to connect coretest + SHA-1 (for example) to
the EIM, rebuild and start testing to see that we have a stable
solution. Reading core IDs, reading and writing data registers and then
start doing lots of hashing.


> Speaking of frequency, I have another question. As far as I
> understand, you want to use the on-board FPGA as a cryptographic
> co-processor, so that the CPU could offload time-consuming hash
> calculations. EIM frequency will obviously limit the maximum
> achievable data throughput. Have you estimated what throughput you 
> actually need? Is it critical to run the bus at 133 MHz or will 100
> MHz be enough?

66 MHz would be more than enough for us at the moment. Getting some of
the cores to meet fmax at 100 MHz requires some reworking. 66 MHz would
give us good timing margin.

As Randy wrote in his response right now we only have the I2C interface,
which is dog slow.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJUqmLcAAoJEF3cfFQkIuyNIPgP/2RwdMlNhAfS9hhDgxmGtr5+
GKo/olNwQVa/rp4P9e4eRrUbIGSYsZIW4Aq/TBfdv9U+2jcBIdrzjSaCer5NaEy9
2pghqv93GTiFOmtVaSwq3Qm7xKFpJOEkbtkWKyeuIGWgBdRebjXGut6e/CGCQZ2b
BElAQTLNXfh2ijHeBgzbNGmprL8j8F7RkNlkUs505h88vEBQIzr1uah5weF3YHjT
9YUUc5O0ytVxNBodVpKW+6+x3c9iXdKBBdVEgxV3KkDDdUbvpn3qGFZr2Zqbr3te
MnaWgtulDY1LqJpEHkkyH/+hmqAHjy7HUX4NBEU45Li4SkY2C2+18HBXqH2MCV+q
k3Wp0wL/M+1f8J3pXv8FVjSDLQL9i1sMOhFO0qOcqwA7zDLYl1p2uKyiPpmoJ7JZ
6YX7daNQQIj70yhcqtXhYphkbCl+xfch8D2lVFUe4YNu0iFIt9DPibFrMpRp63uG
1+LlGFaJeLri4WYrJwRO9U7FV+QNLi49d0ezC8XBy5z0PLVbWmNvKhZRQBcy9g7+
6iZVO7zvCS2gTBRmbDqnNkoRChzPheM4wu8pedy1B4w3AGTbFojDcwpMqHqf+g7V
2vdPjpjMZYFXT+B+D20NK/qkluWtz3itFy4H34kqmkglTrJ7r4upMZL85pG6AwqE
+DGCAWcnok09c6VJDKhM
=rOg7
-----END PGP SIGNATURE-----