[Cryptech Tech] Alpha Platform Upgrade

[Pavel Shatov]

26.02.2020 8:44, Paul Selkirk пишет:
> Well, try as I might, I can't get the design to build with ModExpNG at
> 180MHz. It consistently fails with 2 timing errors on
> TS_clkmgr_mmcm_inst_mmcm_clkout2 (the 180MHz clock line). I sent Pavel
> the timing report last week, but I've attached it here in case anyone
> else has some other insight.

Ehm, I believe I did answer that mail you sent me last week. Maybe it 
ended up in your spam folder or something? Anyways, I'll just forward it 
to the list after I finish writing this one.

> OTOH, cutting ModExpNG back to 90MHz, I was able to build and test.
> Overall it ran faster than the previous test, because cores were clocked
> at 90MHz vs 60MHz.
> 
> The only place it ran slower was in hal_ks_fetch, because the FMC bus is
> now clocked at 45MHz vs. 60MHz previously, and hal_aes_keyunwrap spends
> most of its time sending data back and forth over the FMC bus. This may
> be a good time to integrate Joachim's keywrap core into the mainline.
> 
>                                          modexpa7        modexpng
> hal_rpc_pkey_sign                       104.947          79.515
>    hal_ks_fetch                           19.089          19.089
>    pkey_local_sign_rsa                    85.778          60.344
>      hal_rsa_decrypt                      85.078          59.641
>        rsa_crt                            81.328          55.897
>          modexp2/ng                       55.007          44.409
>            hal_modexp2/ng                 44.497          17.557
> 
> I don't understand why the FMC bus can't be clocked at 90MHz, since
> that's its documented max.

Yes, but there's errata, see the first bullet under item 2.3.14:

https://www.st.com/content/ccc/resource/technical/document/errata_sheet/38/e6/37/64/08/38/45/67/DM00068628.pdf/files/DM00068628.pdf/jcr:content/translations/en.DM00068628.pdf

When the FMC clock divider is 2, the clock itself only becomes active 
when you read or write something over the FMC, and then stops after a 
very short period of time. This manifests itself in a very weird way: if 
you constantly read/write over FMC, everything seems to work fine, 
because the clock either doesn't stop at all or only stops for very 
short periods of time (the PLL in the FPGA can tolerate short intervals 
of missing reference clock and not lose lock, but that's unreliable and 
must not be used in production). Whenever you break STM32 and start 
debugging, everything inside of the FPGA gets reset, since the FMC clock 
stops, the clock manager detects this and asserts sys_rst_n. I did 
initially try 90 MHz FMC, of course, and spent quite some time banging 
against the wall to figure out, wht it was not workable for our design.

> Alternately, is it possible to clock the cores at 120MHz, and FMC at
> 60MHz? I remember we did some work on the cores at some point, but I'm
> really not the FPGA guy.

The ultimate restriction is that the system clock must be an integer 
multiple of the FMC clock, so say 60/90 doesn't work, but 45/90 and 
60/120 are feasible. I'm not sure all the cores can meet timing at 120 
MHz though, this would need further investigation.

> 
> 				paul
> 
> 
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech
> 


-- 
With best regards,
Pavel Shatov