[Cryptech Tech] Status of RSA timing tests etc

[Pavel Shatov]

26.05.2018 20:30, Rob Austein пишет:
> 
> * 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.  Might at least be worth the experiment,
>    particularly if it:
> 
>    * Lets us get rid of the double read in fmc_read() and
>    
>    * Lets us stop having to spin wait polling the FMC NWAIT GPIO pin
>      after every 32 bit word we transfer(!).
> 
>    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.  Pavel?  You're our FMC expert.  Opinions?

The upper limit of FMC interface speed is 90 MHz. The FPGA has its own 
independent 50 MHz clock source. It also has an internal clock 
synthesizer, so it can generate a different frequency inside to clock 
the cores. We're just not doing that right now (we multiply and divide 
those 50 MHz by the same factor).

Now there are two reasons for having a separate clock source for the cores:

1) We may want to run the cores slower or faster than the FMC interface 
speed. As far as I remember, the plan was to start with a pretty low 
speed like 50 MHz and then gradually increase it in steps.

2) FPGA may need an independent clock source. In case the FMC clock is 
stopped for whatever reason, the FPGA won't be able to do anything 
(react to sensors, wipe the master key, generate more random bits, etc) 
without a different clock source.

Now Paul's idea to run the cores at FMC clock is very interesting, and I 
believe it's viable. It needs a minor bit of investigation with a scope, 
which I'm going to do next week.

As far as I understand, all the cores we currently have can now run at 
least at 100 MHz, so there should be no problem running them at 90 MHz, 
and there's no reason to clock them slower than that. The only 
implication is that in case we want to further increase the clock 
frequency for the cores, we'll have to use 90*2 = 180 MHz which may be a 
pretty large jump. For synchronous FMC interface the speed of the cores 
must be an integer multiple of the FMC speed.

Speaking of the aforementioned reason 2), is there anything that we want 
be clocked by a dedicated always present 50 MHz clock, not FMC_CLK?

The byteswap issue is straightforward to fix. From my experience the 
real problem is to not forget to simultaneously do it in two places 
(remove from STM32, add to FPGA at the same time :)


-- 
With best regards,
Pavel Shatov