I've gotten a SAM E70 XPlaind developer board in the mail today. I need to figure out what to do with regards to a development environment still. I am strongly inclined to use an ARM compiler for Mac and the command line, as it's where I'm most comfortable. But the weight does seem to be behind running Atmel studio on a Windows VM.

Meanwhile, some of the nice things about potentially using an ATSAMS70E19 for this is that it has a TRNG built-in. That means that the whole boost converter and avalanche transistor can go away.

But to make up for that, I need to figure out some way to multiplex the HSMCI port, since the S70 only supports a single SD slot. What really complicates the hell out of things is that there are 6 pins of the HSMCI interface for an SD card: data lines 0-3, a command line, and a clock line (along with that is the power and ground).

All of the data signals except the clock are bidirectional.

My fervent hope is that all of the data lines can be shared and that just the clock line can be switched back and forth with a simple pair of gates. If that isn't going to fly, then the only choice is foregoing the HSMCI interface and just using SPI. We already know that works from the current generation of Orthrus. 

In theory, a 25 MHz single-bit SPI system could transfer around 3 MB/sec, so having to start from a place of such low throughput would make it hard for the rest of the system to not make it worse, particularly given that there isn't (so far as I am aware) any support for pipelined or multiplexed I/O over USB. A 25 MHz 4 bit setup could do 12 MB/sec, which is much more in line with expectations. The only thing that would really get in the way is the fact that we need to intersperse the AES computations in every 16 bytes of I/O.

Going to a faster ARM processor would let us go from 16 MHz SPI to 25 MHz as well as going to 480 mb/sec USB. But I'm dubious that those changes and the faster AES engine by themselves will be enough for us to crack the 1 MB/sec barrier.