[Cryptech Tech] status alpha board designers

[Павел Шатов]

On 25.04.2015 17:05, Jacob wrote:
>
>> What seems clear is that we need to get a much more complete schematic
>> done
>> first.
>
> Is there a writeup that shows the expected crypto ops throughput rate of
> the alpha board? Is there an arbiter in the uC that prioritizes requests
> to the FPGA?
>
> --- thinking aloud ---
> Since the FPGA is not connected to an external memory, I surmise that
> all  requests are queued at the uC and then scheduled along the 66MHz
> bus to the FPGA after the latter finishes each crypto op processing.
> This may be OK since the I/F to the board is through a relatively slow
> PKCS#11 protocol - hence low request rates - and not through a network
> connection.
>
> Also, is a graceful restart necessary (maybe already designed in?) to
> reschedule users' crypto ops requests in the queue after a possible
> board power failure?

Jacob, thank you very much for your feedback!

We are not very much concerned about throughput right now, what we want 
in the first place, is a board that can actually do something. I think, 
we can sacrifice some secondary features, if it will cut development 
time, but that needs to be discussed with the rest of our team.

Our external interface is going to be through USB-to-serial converter. 
UART is limited to 4 Mbps in i.MX6Q processor, so we are not going to 
have very much bandwidth anyway.

I believe, we do not need graceful restart, at least not in the first 
version of Alpha board. We want FPGA and CPU to be connected via EIM 
bus, this way FPGA will look like a set of registers mapped into CPU 
address space. We already have working EIM arbiter design for FPGA and 
some demo programs that communicate over this bus from the CPU.

Jacob, we understand, that Alpha board is going to be complex, that's 
why we want to reuse as much as possible. One of ways forward we are 
considering, is using this CPU+RAM module: http://www.imx6rex.com/
Could you please have a look at it? The only problem with this module, 
is that it has lots of unnecessary interfaces (audio, video, ethernet, 
etc) and doesn't have EIM. I think, that it will be easy to adapt this 
module to our needs by removing unneeded signal traces and then routing 
EIM signals instead. Is this possible? I can provide detailed list of 
CPU pins, that we don't need, along with a list of new pins, that should 
be exposed from this module.

After this modification it will only be necessary to develop FPGA 
baseboard for this module. They offer their own baseboard, but it 
doesn't suit our needs, because it has a lot of "household" stuff. But 
we still can reuse power supply design from it. I believe, that 
development of FPGA baseboard will be much faster, because it will not 
involve CPU and DDR3 memory layout. The only problem with this idea, is 
that we prefer Alpha to be single-board. Could you please give us an 
estimate of how long it will take to modify that module and then design 
FPGA-based carrier board for it? Maybe we can make Alpha two-board, and 
once it's ready, we will start working towards single-board Beta.

--
With best regards,
Pavel Shatov