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
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
