Flash clock and wait states

[richardeoin]

To calculate the number of wait states for the flash, we use RM0433 Rev 7. Table 17

This table implies the calculation should be based on the AXI Interface clock (= rcc_hclk). However the text immediately above it says it should be based on sys_ck. Indeed the block diagram (Fig. 5) shows only sys_ck entering the flash sub-system.

Which clock should we use for this calculation? (see Figure 49.)

• sys_ck
• sys_d1cpre_ck ( = sys_ck / 1)
• rcc_hclk ( = sys_d1cpre / 2 by default)

Currently we use sys_d1cpre_ck, so the flash is always set to 7 wait states for sys_d1cpre_ck > 225MHz.

TODO:

• Decide and use correct clock
• Add flash wait state table for VOS0

[richardeoin]

Ping @ryan-summers perhaps, who has done some high-performance/speed things with the H7

[jordens]

When I did the analysis and wrote the bootstrap code (taking inspiration from the cubemx hal), these were the correct settings in our case:
https://github.com/quartiq/stabilizer/blob/507b721c4e4d539e4d9d6bb2430318afcf3cf5c4/src/board.rs#L128-L137

[richardeoin]

Ok, thanks for the link @jordens. Good to know that example works, although sadly I don't think it tells us anything because it has sys_ck, sys_d1cpre_ck and rcc_hclk all = 200MHz afaict.

The implication from the numbers in the table is that the clock used is rcc_hclk, so I'm inclined to go with that. At least for me on a STM32H747XIH, setting WS=2 works for sys_ck = 400MHz, rcc_hclk = 200MHz.

[ryan-summers]

Alright, here's my opinion on the subject.

It most likely is not rcc_hclk, as rcc_hclk is the bus frequency of the AHB port, which is the (slow) bus interface to the configuration registers for flash. Typical flash read/write operations go through the high-performance AXI port (which has way higher throughput than the AHB port). As such, I think we can safely eliminate rcc_hclk.

sys_d1cpre_ck is the clock used to power the CPU and D1 AXI bus matrix according to page 347. Take specific note of the second paragraph where it indicates this clock is provided to the bus matrix:

Below the FLASH functional block diagram, it provides definitions of the signals shown:

Based on this, it appears the sys_ck that the flash peripheral is referring to is actually the bus frequency clock, not the actual sys_ck generated by the RCC. Instead, I think we can interpret this sys_ck as equivalent to sys_d1cpre_ck, since sys_d1cpre_ck is the clock used for the AXI bus matrix in the D1 domain, as noted above.

Conclusion: sys_d1cpre_ck is the correct clock to use to determine flash wait states.

[richardeoin]

@ryan-summers Thanks for that, it's great to have more people look at this. I think the naming of rcc_hclk has sent you in the wrong direction, so I'll try to explain that more.

The names in src/rcc/mod.rs come from Figure 49.

rcc_pclk1, rcc_pclk2.. and so on map directly to the diagram. rcc_hclk covers rcc_hclk[1-4], but also rcc_aclk because this is the same frequency. I collected these under one name when writing the initial rcc implementation for brevity (freeze() is already quite long), but there is an alias in the public API. I would support breaking rcc_hclk into its parts at some point, especially if we add any functions for clock gating.

I agree that flash operations (always?) go through the AXI port, so it is likely this clock that matters. AXI is higher bandwidth than AHB (64-bit vs 32-bit, multi-channel/multi-master vs single-channel), but I think the clock speeds are equal on the H7.

The D1CPRE divider is upstream of sys_d1cpre_ck and all the bus matrix clocks, so changing it will affect the bus matrix clocks. I don't think it means that the bus clock must be sys_d1cpre_ck itself. Actually it make more sense that it's rcc_hclk, or really rcc_aclk (the AXI bus clock) although we don't have a variable with that name.

[ryan-summers]

I see what you're saying. After that, I think you're right in that the clock labelled rcc_aclk would be the relevant clock (since it quite clearly states that it's the AXI bus matrix clock)

Edit: If you look in my previous message, it also states In the same way, HPRE divider can be used to adjust the clock for D1 domain bus matrix, but this also impacts the clock frequency of bus matrix of D2 and D3 domains.

This is telling us that the bus matrix clocks are downstream of the HPRE divider, which eliminates sys_d1cpre_ck from consideration.