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