[Cryptech Tech] Alpha board strategy

[Rob Austein]

At Wed, 18 Feb 2015 20:27:24 +0900, Randy Bush wrote:
> 
>   o the soc/cpu code is being done by paul and rob.  they are capable of
>     speaking for themselves (when they wake and dig out of the boston
>     snow).  but my guess is the bigger chunk of soc dependency is the
>     library environment.  unless the compiler is really weak.  my guess
>     is they would be unhappy if gcc did not support the chip.

GCC is nice, because we sort of understand it, although something like
Clang would probably be OK too.  Have worked with other compilers
(some fairly sick).

Availability of compiler source code for review is a tinfoil issue.

Debugging environment may be more of an issue: debugging complex code
via printf() is not fun.

So yes, while we could do other things, the comfort zone is probably
GCC and GDB, with GDB remote debugging support.  This covers a lot of
ground, given that companies like Wind River built their entire
development environment around this tool chain for a long time (and
perhaps still).  Paul may be able to speak more to this point.

Libraries...yeah, that can be an issue.  Depending on how deeply one
wants to dive down the embedded rabbit hole, one might want to avoid
depending even on fprintf(), but eventually one gets down to utilities
like malloc() and memset() which one can of course re-implement but
would really rather not.

My general impression of Cryptlib is that it's pretty careful about
dependencies and fairly well self-contained, but I can't claim to have
explored every corner, and of course what it requires depends on what
features one chooses to enable.  Documentation on building Cryptlib
for embedded systems all seemed to make sense when I read it a month
or two ago, but of course the real test would be seeing what (if
anything) breaks when dropped into a new target environment.

Soft cores (whether the ones we discussed last year or ones like
CHERI) are interesting for various reasons, but, gate count/cost
issues aside, my main issue with them from a practical standpoint is
that the likelyhood of running into obscure "hardware" bugs is higher
(hard to quantify by how much) than with a chip that's shipped
zillions of units.  Not such much that a hard CPU is any less likely
to have bugs, but if there are any, zillions of units shipped means
it's more likely that somebody else has already run into those bugs.

Bottom line: At least for the Alpha board, I'd stick with a
well-understood conventional CPU like the i.MX unless we want to sink
a lot of time into reinventing wheels not core to this project.