The Cryptech Alpha Board

Title: AlphaBoardStrategy Date: 2016-12-15 22:43

The Cryptech Alpha Board

Goal

Develop a first, custom HSM board that can be used to support a first set of applications as well as being used for further development of new functionality as well as security mechanisms such as tamper detection and protection, key storage etc. Deadline is to produce palpable results before summer, 2015.

The use cases and requirements for the alpha board are specified on the Dashboard.
The basic blocks of the Alpha board is "shown here".
The "BOM and component requirements".
The detailed "Alpha board functional drawing".

Plan

Choose FPGA and ARM (done)
Develop BOM, requirements and functional diagram (done-ish).
Develop complete "schematics" (almost done).
Develop dev-board ouorselves to connect chosen ARM to FPGA on Novena, to do some early development and testing in parallell with step 5.
Get professional designer to do many-layer PCB from schematics.
Manufacture a couple of boards (~10).
Bug fix hardware+software.
Make beta design.
Manufacture more boards (~50).

Way forward

We currently use the Novena as a dev-board. It has a "Freescale i.MX6 CPU (ARM Cortex A9)", and a Xilinx Spartan-6 LX45 CSG324-packaged FPGA.

We want to over-size rather than under-size the FPGA on the Alpha board. The biggest FPGA from Xilinx/Altera that does not require tools with a commercial license that we've found is the Xilinx Artix-7 XC7A200T FBG484.

We've only considered ARM CPUs. Either about the size of Cortex M3 / M4 (or future M7) or Cortex A8 / A9.

A design with an A8/A9 turned out to be unattractive from a complexity and price point of view, so we're going to use one of the biggest M4 we could find. STM32F429.

We are currently using a Freescale proprietary interface called EIM between the ARM and the FPGA on the Novena. EIM is not available with microcontrollers from ST, so we will use a similar interface made for connecting the ARM to external memory (called FMC). This interface runs at speeds up to 90 MHz, which is more than we are going to be using with our current FPGA cores.

Risks at this point

Taking too long deciding on what the Alpha board should contain.
Ordering PCB design and manufacturing boards that just does not work for our purposes.
Getting Alpha boards that require too much time to get working.

Conclusion

Use a high-end Cortex-M4 ARM.

There is a huge difference in complexity between M4 and A9, mainly because of the DDR3 memory used with A9. An M4 design will both be easier to design, cheaper to both design and build and will be fast enough for all our early use cases anyways.

Do not use the exact same FPGA, as it is too small to fit everything we need.

Develop full schematics in-house.

It turned out to be hard, costly or both, to outsource this part. We will probably spend less time developing the schematics ourselves than we would spend explaining what to develop to a third party.

Age	Commit message (Collapse)	Author
2016-07-05	Attempt to add resource management, for multiple cores of the same type.	Paul Selkirk
	Find a suitable core, and mark it busy. Don't forget to release it as soon as you're done. This has a knock-on effect of un-const'ing core arguments and struct fields in a lot of places, and it moves some core checks around.
2016-05-24	This should have been in commit 7f38fc4.	Paul Selkirk