[Cryptech Tech] EIM: mostly working

Joachim Strömbergson joachim at secworks.se
Thu Nov 6 08:27:40 UTC 2014


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

Aloha!

First, thanks for status update and great work on the EIM interfacce.
See comments below.

Paul Selkirk wrote:
> "Mostly working" means it passes most of the test cases most of the 
> time. It fails the 1000-block sha256 test case 75% of the time, and
> very occasionally fails one of the other test cases. (Of course,
> unless it works 100.0% of the time, it's completely broken, so
> "mostly working" is a hand-wave.) The usual failure mode is that it
> returns a random digest, not just a few bits or bytes that might
> indicate an error reading the digest from the core.

Sounds like either bit conversion or more probably timing issues.


> A note about timing: Mostly I've been clocking the coretest cores at 
> 133MHz, because that's what the rest of novena_fpga uses. At that
> speed, it consistently passes the sha1 tests, but consistently fails
> all the sha256 and sha512 tests, again with random digests. It's as
> if it was hitting the 'next' control rather than the 'init'. When I
> dialed coretest back to 50MHz or even 25MHz (leaving the EIM circuit
> at 133MHz), it started passing the sha256 and sha512 one-block and 
> two-block tests (mostly), but still failed the sha256 1000-block
> tests.

But do you get timing closure for these cores @133 MHz. I would have
excected them to not be able to be clocked that high in the Spartan-6.
What does the timing report says?


> Yesterday's commit contains a pre-built bitfile. If you want to build
> it yourself, I've included a Makefile (for Rob) and a .xise file
> (for Joachim). Be warned that it takes longer to build than the i2c
> versions, and it's not predictable. Command-line builds generally
> take 15-20 minutes on my machine, but can go to 30 minutes, and I
> even had one run that took an hour. ISE builds tend to be a bit
> longer, and I had one run that took 2 hours. Seemingly trivial
> changes can lead to dramatically different run times. Most of the
> time is spent in PAR (place and route). Joachim may have some ideas
> why.

Placement is done by different strategies and rules, for example
closeness between producer and consumer. If the device is heavily
constrained (a lot of of available pins are assigned for example) and
the device utilization is high),  small changes in the design might
force the tool to select placement that is very different from before
simply because there is no place left at a good spot. And this means
that closely related functions needs to be separated with wires in-between.

Also, at least some of these tools also do semi-non-deterministic (prng
based) initial placements which means that two builds does not achieve
the exakt same placement and design. The functionality will be the same
and the timing will be met, but routing and placement might differ at
bit and thus also take a bit different time.

Tryggve Mathiesen who reads this list is the real expert on the inner
workings of ISE and can do a much better explanation (and correct my
mistakes).


> Anyway, I'd appreciate any ideas about what might be wrong, or things
> to

There are several issues we need to look at.

(1) Ensure that all important timings are met. If not, signals will not
have the correct, expected values. Can you extract the final timimg report?

(2) Ensure that the 16-32 bit and big endian-little endian-converion
works as expected. How about adding a 32-bit register, write to it from
EIM and the extract it via I2C. Since you have I2C access working you
should be able to see if the conversion works as expected. That is we
end up with the expected values in the FPGA.


(3) Properly debug the EIM interface and the SW interface including
setup with something simple. Possible a single hash core or something
even simpler. An adder, multiplier etc with extra ports for debugging.
Then we add one of the hash cores and then move towards the complete
shebang.

- -- 
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.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJUWzD8AAoJEF3cfFQkIuyNsgMP/ii8O/ho1IjY73s3B4jXBx52
e5ujr0YvgiFcuerq4MtmUS6P3dehEEnZ0+t9N8yx1voRYlfoifT5cDInmQNT35zG
o6pKWK/OTrmrYkzzGogSfl5JyQT4XKDUxEUpPreZSdG5E+v0kDmIt2Jk+9j2sem+
KemPI6lkMj1tUJO/+7mgFNbJ6pbu+EeJzmpfeT4h4fwLqSAIK2FEjnV8yKy1qHhk
6/U52FWdO+pQUhPMQlsZIOtVMB4hk7NR9oME3Of8RDd74g4C6DWwNym7ETPB2Uex
Opn+LEQzOpLo8MV1KjPelMm43jUSb2sz2L6/KR9GwSfGMgFO473UP6w7Fs1/U4Hd
xLodG9EbeC33zOurWxUIf7nhWlp0ITC06KNBBYeYlgl7X5NvXqHmo+HSVVPhfl7r
6m9Jp3QBvped5uus8sE/Fc55ApDREnsfs220aEnVEa8oIUUZNEQphJhVtnsrr2Ll
U+Inm1qSQAVey5fwijua8K6s3VzFG1jTD/bqkvp7fJVSXxMr2ftvxP2OGSRQcrfF
PGMxKSQyU4pCn78d1bSAK7BgM+ALeJg20/W61tbbfdxtFq5ay/MC/zMpIXToJ2cn
LGVgL+KBBrxuS9LXdPS9kSBQhUSOwy6EKo2tUdjwE7yyDVkcmu+Z7SCwBTBH0ugi
TDqL5SAHTLyp1H/41kZs
=KiAN
-----END PGP SIGNATURE-----


More information about the Tech mailing list