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.