[Cryptech Tech] Status of RSA timing tests etc

[Peter Stuge]

Rob Austein wrote:
> * Several of us are still suspicious of FMC I/O here

It seems quite likely. Busywaiting is never good for performance.


> * Paul (re-)raised an interesting question about whether we could
>   clock the FPGA from the 90MHz FMC bus and make this a synchronous
>   interface, which at least in theory might significantly increase
>   throughput on the bus.

It will for sure, if it works.


> Might at least be worth the experiment, particularly if it:
> 
>   * Lets us get rid of the double read in fmc_read() and

This depends on the STM hardware. Maybe the errata says yes or no.


>   * Lets us stop having to spin wait polling the FMC NWAIT GPIO pin
>     after every 32 bit word we transfer(!).

It will.


>   Assuming this change is workable, if we were to combine it with the
>   trivial hack to move the bytes wapping to Verilog, we'd finally have
>   an interface which looks relatively sane in terms of the number of
>   ARM instructions involved in moving data between ARM and FPGA.
> 
>   Paul and I don't know enough about the FMC bus to know whether this
>   is plausible.

Yes, I think it is.


> * I noticed a few more minor things we could do with the current FMC
>   I/O code which might squeeze a few more cycles out of it, will try
>   them at some point, but as long as we have the NWAIT poll after
>   every word I would not expect this to make much difference.

Someone with access to an oscilloscope or logic analyzer could take a
look at the FMC sync signals to find out how long data transfer
takes.

And/or probe an STM32 IO (e.g. PA14 also used for SWDCLK) and make
software set that high before start of transfer and back low when done.


//Peter