[Cryptech Tech] STM32 FMC problem

Павел Шатов meisterpaul1 at yandex.ru
Tue Aug 18 21:04:28 UTC 2015


On 18.08.2015 16:51, Joachim Strömbergson wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA256
 >
 > Aloha!
 >
 > Pavel Shatov wrote:
 >> Well, the problem as I see it, is that STM32 doesn't handle
 >> variable-latency transfers over FMC very well. This variable latency
 >> arises, because data transfer over FMC runs at its own frequency,
 >> while cores in FPGA can work at some another frequency. One possible
 >> solution is to clock cores in FPGA using FMC_CLK. This will make
 >> whole system synchronous. This was actually not possible with iMX6Q,
 >> because it could only generate EIM_BCLK during read/write
 >> transactions. STM32 on the other hand can generate FMC_CLK
 >> continuously.
 >
 > (The FMC_CLK can be set to only run during accesses too!
 >
 > Running the FPGA and CPU synchronous would make life much easier. The
 > question is what useful values one can get FMC_CLK to. The STM32 we want
 > to use is driven by a 25 MHz clock source which is then used to generate
 > the 180 MHz core clock.

Well, I think, Fredrik used 25 MHz crystal, because it is the highest 
frequency, that our particular STM32 supports for HSE, seems like an 
obvious choice for me. Note, that he could use, for example, 20 MHz 
crystal and still have core running at 180 MHz by configuring PLL in a 
different way.

 >
 > 180/4 = 45 MHz would be possible to use in the FPGA, but then the cores
 > would be running fairly slow. Esp the RSA and (and possibly EC)
 > performance will be affected. But timing margin in the FPGA will be
 > awesome. In the Alpha board drawing we have stated that the FPGA
 > should be fed with a 50 MHz clock (same as the FPGA on the Novena). So
 > the difference in performance would be 10% lower.

I suggested adding this generator, because it is a generally accepted 
design practice to provide dedicated clock generator for FPGA. This 
generator will be necessary, if people want FPGA to do something useful 
even when STM32 is not supplying any clock signal. Our cores can be 
clocked not only at 50 MHz, we can use DCM_SP or PLL_BASE primitives 
(they are in fact PLLs) to generate some other frequency out of this 50 
MHz reference clock. That's how it is done in current version of clock 
manager module, btw.

 >
 > 180/2 = 90 MHz _could_ work for all cores (based on my test
 > implementations). But the timing margin for several of the cores will be
 > low and getting timing closure will become harder. The performance of
 > the cores will be good though.
 >
 > Looking at chapter 37.5.5, the FMC_CLK will be either /4 or /2 of HCLK
 > depending on the width of the bus. In the Alpha drawing we have stated
 > that the width is 32 bits so FMC_CLK should be 45 MHz, correct?

Yeah, I've also spent some time trying to guess what "MWID(AHB data 
size)" means After I failed to decipher the formula, I simply tried 
setting DIVCLK to 1 (overall division ratio is 2) and got 90 MHz on 
FMC_CLK. I also tried setting DIVLK to 2 and 3 and got 60 MHz and 45 MHz 
respectively, as expected.

 > I would suggest trying to run some simple design with a single core
 > block (for example SHA256) in synchronous mode and see if you can get it
 > to work without errors over the FMC interface.

Synchronous mode is attractive, because it simplifies the system, but we 
lose flexibility, i.e. we will no longer be able to run data transfer at 
one frequency and clock cores at some other frequency.

The good news is, that I actually ditched DMA engine idea from the 
errata and adapted what Peter suggested earlier, namely configuring 
NWAIT pin as GPIO and polling it manually after reading or writing. This 
seems to be stable, I tried leaving my demo program running at 90 MHz 
for more than an hour yesterday and didn't get any data transfer errors. 
The code needs a bit of polishing, I think, I will upload it during the 
weekend. It would be great, if you and Fredrik could test it then.

 > BTW: Do you have a serial port or similar connected to the STM32 on the
 > bridge board for debugging? What does you setup look like?

My setup looks like the attached picture I downloaded 32KB-limited free 
version of IAR Embedded Workbench IDE, it offers a feature called 
"semihosting". I can printf() some text from my demo program and it will 
show up in the console output tab.

-- 
With best regards,
Pavel Shatov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hardcore.jpg
Type: image/jpeg
Size: 672777 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20150819/9f34b614/attachment-0001.jpg>


More information about the Tech mailing list