STM32H75x max. Clock for SPI Read Timing

[regjoe]

Hello,

I'm trying to figure out the max. reliable clock frequency for NOR flash connected via SPI or QSPI interface.

I've read here or here  that there are custom board and evaluation board designs which are reading data at single transfer rate up to 120MHz.

I wonder how this is possible regarding the timing parameters in the data sheet.

For example, the MICRON MT25QL flash, which is equipped on some ST evaluation boards e.g. STM32H750_DK and STM32H753_EVAL, puts data at falling clock to IO after 5-6ns as shown here (tCLQV).

In SPI or QSPI SDR mode the H75x latches data at rising edge which must be valid at least 2ns.

Same for QSPI SDR

Timing parameters seem to use the middle of the clock edge for reference. At higher frequency the rise and fall time of clock and IO lines must therefore be added to the timing calculation.

I checked the clock and IO signals on various boards at different GPIO and flash drive strength and series resistors and measured min. 2ns rise/fall time. So the maxium possible clock frequency for SDR calculates IMHO in the ideal case as

tCLK/2 = tFALL/2 + tCLQV + tSU + tRISE/2 = 1ns + 5ns + 2ns + 1ns = 9ns

This examples calculates a maximum SPI clock of 1/(2x9ns) =  55MHz

To my surprise for example the H750-DK can run up to 100MHz without read error. Am I wrong?

I know there are Cortex M7 MCUs which delay sampling at the next falling Clock edge, but it seems this is not the case for H75x, at least not for SPI.

And idea?

[TDK]

tCLV is between middle of clock edge and data valid.

tSIN is between when data must be valid and the middle of the next clock edge.

Rise/fall time doesn't enter in to it here, it's already baked into those constants.

There is no doubt another section that specifies rise time requirements directly or indirectly through high/low clock durations.

[regjoe]

Hi @TDK 

Regarding "data valid": this is IMHO related to the "IO switch voltage" of the SPI device, e.g. for H75x 

IMHO the H75x "sees" low level if the input voltage goes below 0.4*3.3V-0.1V = 1.2V and high level if above 0.47*3.3V + 0.25V = 1.8V. The MICRON differs here, the device seems to be more "CMOS compliant".

So IMHO the timing constants are not constant because it depend somewhat on the voltage level of the connected device a bit.

If I get you right, the timing constants are specified for rise/fall time which is specified in the data sheets? 

Regarding the "minimum rise time", for H75x I found these clock requirements here: 

IMHO this specifies the "duty cycle variation" of the SPI clock but maybe also the maximum rise/fall time? Do you think this contants imply a maximum rise/fall time of 2ns here?

Nevertheless, even if we can rule out the rise/fall times in the calculation, running these devices at 100MHz or higher seems questionable.

[TDK]

> IMHO the H75x "sees" low level if the input voltage goes below 0.4*3.3V-0.1V = 1.2V and high level if above 0.47*3.3V + 0.25V = 1.8V. The MICRON differs here, the device seems to be more "CMOS compliant".

Input levels on the STM32 chip are CMOS compliant. 1.2V/1.8V are certainly within the allowable cutoff thresholds. Is the MICRON not CMOS-compliant? That doesn't sound right.

I'm not seeing a contradiction here that indicates running the chip at 100 MHz is bad or questionable. It's certainly nearing the maximum speed, but timing specifications look to be compatible, so behavior is guaranteed.

[regjoe]

Hi @TDK 

what I wanted to say, to me, the threshold values in table 156, noted as "guaranteed by design", are not exactly CMOS compliant, but the MICRON thresholds seem CMOS compliant. But this seem to be less important here.

Can you please share information to what makes you sure that "timing specifications look to be compatible".

IMHO, only considering tOV and tSU, the maximum clock frequency calculates as

tCLK/2 = tCLQV + tSU = 5ns + 2ns = 7ns -> 1/(2x7ns) =  71MHz

What is wrong in my calculation?

[TDK]

> IMHO the H75x "sees" low level if the input voltage goes below 0.4*3.3V-0.1V = 1.2V and high level if above 0.47*3.3V + 0.25V = 1.8V.

> the threshold values in table 156, noted as "guaranteed by design", are not exactly CMOS compliant, but the MICRON thresholds seem CMOS compliant.

In what way are they not exactly CMOS compliant? The datasheet goes into detail on how they are CMOS compliant and shows the levels vs CMOS thresholds. Thresholds of 1.2V and 1.8 V are sufficient here.

> IMHO, only considering tOV and tSU, the maximum clock frequency calculates as

> tCLK/2 = tCLQV + tSU = 5ns + 2ns = 7ns -> 1/(2x7ns) =  71MHz

You're right, my math was off.

At 100 MHz, it's not guaranteed to work based on those timings. However, "overclocking" does appear to work in this case. Up to you if you want to trust it or not. Typically, the temperature extremes will be the limiting case. When operating at ambient you have more margin.

[regjoe]

Hi @TDK 

maybe I'm reading between the lines but simply telling from the notes to table 156, the H7 thresholds "Guaranteed by design", are calculated as 1.2V/1.8V at VCC=3.3V. In opposite to that, the CMOS thresholds are 1.0/2.3V, which are labeled as "Compliant with CMOS requirements". 

This tells me that the H7 thresholds differ from "CMOS standard". No clue if this means that the H7 is "CMOS compliant" or not.

But this has some effect on timing calculation e.g. a rising signal at H7 input is earlier recognized as HIGH (1.8V) as in standard CMOS (2.3V). Same on falling edge. This may have a positive effect to H7 setup time in our timing calculation example because IMHO it extends the setup time at H7 read a bit.

[regjoe]

Regarding QSPI SDR, 100MHz are allowed, because according to RM0433 data sheet, the QSPI peripheral has a "sample shift feature" which does data sampling at the falling clock at H7 read.

Regarding flash connected to SPI, although tests at 100MHz seem to work, I'd prefer 50MHz unless I get further information.

[regjoe]

Regarding QSPI DTR, I've tested MT25QL01G, MX66L1G45G and MX25L12845G flash. I played with "worse" combinations of H7 GPIO and flash drive strength. Both 1Gbit flash work reliable up to 50MHz.

In some combinations 66MHz can be achieved, especially with MX6601G, but this works only for some well tuned drive strength combinations and violates my timing calulations.

The MX25L12845G drives me crazy. It seems this device is not "H7 compatible", probably because of the shorter output hold time of 1ns. I get read errors no matter if running at 40 or 50MHz, so this is not a setup timing problem.

If using low driver strength the MX25 works too but I do not trust this device anymore. The MX66 has is specified with 1ns in its datasheet too but I've measured both devices and the hold time of the MX66 is ca. 1ns longer.