I'm using a freescale PowerPC microcontroller. In the flash memory module in the datasheet, the number of "wait states of the flash memory access" is configurable.

The following is the part of the datasheet raised my question, it's taken from the register description of the PFlash module registers :

This field must be set to a value corresponding to the operating frequency of the PFlash and the actual read access time of the PFlash. Higher operating frequencies require non-zero settings for this field for proper Flash operation.
0 MHz, < 23 MHz, wait states required = 0 ---
23 MHz, < 45 MHz, wait states required = 1 ---
45 MHz, < 68 MHz, wait states required = 2 ---
68 MHz, < 90 MHz, wait states required = 3 ---

(PFlash is Platform Flash controller module)

I understand that the processor is faster than the flash, that's why wait states are introduced. What I don't understand, is : if processor is faster than flash, then the processor is the one that needs to be slowed down not the flash, but the paragraph above says the opposite (or did I not understand this?), it says that in case the Pflash is operated with high frequencies, then we need to slow it down by adding to it additional wait states !!

What's wrong with my understanding ?


  • 1
    \$\begingroup\$ If I understood correctly, is the controller that can be set to different speeds; so it has to wait that the actual Flash memory has the data available. \$\endgroup\$
    – clabacchio
    Commented Feb 27, 2012 at 14:34

3 Answers 3


To amplify stevenvh's answer, any type of logic, when given an input signal, will take some time to produce an output signal; memory is often very slow compared with other logic. Often, there will be a guarantee that the output signal will become valid within a certain amount of time, but that's it. In particular, it's possible that the signal might change several times within that interval, and there will be no indication, prior to the end of that interval, that the signal has achieved its final "correct" value.

When a typical microcontroller or microprocessor reads a byte (or word, or whatever unit) of memory, it generates an address and, some time later, looks at the value output by the memory and acts upon it. Between the time the controller generates the address and the time it looks at the value from memory, it doesn't care when or whether the output signals from the memory change. On the other hand, if the signal from memory hasn't stabilized to its final value by the time the controller looks at it, the controller will misread the memory as having held whatever value was being output at the moment it looked. Normally the controller would look at the value from memory as soon as it was ready to do something with it, but if the memory's value wouldn't be ready then, that might not work. Consequently, many controllers have an option to wait a bit longer after they're ready to process data from memory, to ensure that the output from memory is actually valid. Note that adding such delay will slow things down (the controller would have been happy to act on the data from memory sooner), but will not affect correctness of operation (unless things are slowed down so much that other timing obligations cannot be met).

  • \$\begingroup\$ Nice! Thank you for the helpful details you explained ! \$\endgroup\$
    – MohamedEzz
    Commented Feb 27, 2012 at 17:09
  • 2
    \$\begingroup\$ @MemoryLeaks: My pleasure. An important thing to note is that reducing wait states below the specified limits will cause the system to run faster, but reads from memory may arbitrarily yield incorrect data; further, "arbitrarily yield incorrect data" may mean "yield correct data until the device you've designed is in your customer's hands, and then start yielding incorrect data often enough to get the customer very mad at you." \$\endgroup\$
    – supercat
    Commented Feb 27, 2012 at 17:49
  • 1
    \$\begingroup\$ This seems to very closely parallel overclocking, but more of a configurable option thereof. Interesting way to overclock an MCU perhaps. \$\endgroup\$
    – sherrellbc
    Commented Jul 2, 2014 at 20:47
  • 1
    \$\begingroup\$ @supercat, One question what's meant by controller is it the processor or the memory controller ? \$\endgroup\$
    – Mouin
    Commented Apr 15, 2018 at 20:24
  • 1
    \$\begingroup\$ @Mouin: The memory controller if there is one, or the processor if there isn't. \$\endgroup\$
    – supercat
    Commented Apr 16, 2018 at 15:04

Wait states are added to the memory access cycle initiated by the CPU. So it's indeed the CPU which has to wait for the slower Flash. The memory controller signals "not ready" to the CPU for a number of cycles (0 to 3), and while it does so the CPU remains in its current state, i.e. having written the Flash address, but not yet reading the data. Only when the memory controller signals "data ready" the CPU will read from the data bus and continue its instruction (latching the data into a register or into RAM).

  • 1
    \$\begingroup\$ So by configuring that setting, I'm telling the memory controller when to exactly signal "data ready". Can't I just tell the memory to signal "data ready" when it actually is ready ? \$\endgroup\$
    – MohamedEzz
    Commented Feb 27, 2012 at 16:08
  • 1
    \$\begingroup\$ @MemoryLeaks - That's possible, and it's done by asynchronous processors, which are rare. It's more common, and more predictable, to synchronize everything using a clock. So it's either a clock cycle delay (or 2 or 3) or nothing. \$\endgroup\$
    – stevenvh
    Commented Feb 27, 2012 at 16:14
  • \$\begingroup\$ Thanks for your answer :) So to sum up : the description in my question above means it will delay the "CPU" and not the Flash controller \$\endgroup\$
    – MohamedEzz
    Commented Feb 27, 2012 at 17:07
  • 1
    \$\begingroup\$ @stevenvh does the processor literally hang up this it receives the data from memory, I mean does it completely stop execution or would it execute other instructions in case of a pipelined CPU. What about interrupts I guess they would be serviced while the CPU is waiting for the memory to be ready? \$\endgroup\$ Commented Oct 26, 2016 at 7:02

The processor might need to stall on memory, but a clever design wouldn't need to.

I think the key technology you're not aware of is burst/page mode access. That allows the bandwidth of memory accesses to be very close to the processor speed (but probably Flash is still the bottleneck since I've never seen a Flash based MCU that runs at > 200MhZ)

However, the latency stays the same. For example, for the STM32F4 MCUs that I'm using, #wait states = floor(clockSpeed / 30MhZ). That means the latency is always 33ns, regardless of clock speed. There's a saying, "Money can buy bandwidth, but latency is forever..."

Even if the Flash bandwidth wasn't sufficient to keep the CPU busy, you can easily design a code cache that stores and prefetches instructions that are expected to execute. ST has a hint about this for their STM32F4 MCUs (168 MhZ):

Thanks to the ART accelerator and the 128-bit Flash memory, the number of wait states given here does not impact the execution speed from Flash memory since the ART accelerator allows to achieve a performance equivalent to 0 wait state program execution.

Actually, the statement also suggests that burst mode isn't necessary and that a very wide memory interface is also sufficient. But the idea is the same (using parallelism to hide latency). On chip, wires are free, so a 128bit memory would make sense.

  • \$\begingroup\$ Wires are far from "free" on a chip, generally speaking, but increasing the bus width between a memory array and a set of latches doesn't add wires. If a chip has a 256kbit flash array organized as a 512x512 grid, the wiring and logic to condense 512 columns to a 32 bit bus is going to be necessary whether one places a 512-bit-wide latch before the "condensing" wires and logic or a 32-bit wide latch after them. \$\endgroup\$
    – supercat
    Commented Jul 2, 2014 at 19:18
  • 1
    \$\begingroup\$ I mean they're "free" compared to external pins. I'm know that wire energy dominates these days and that locality is important, so let me qualify that statement. They're free to make, but not free to turn on! \$\endgroup\$
    – Yale Zhang
    Commented Jul 2, 2014 at 19:57
  • 1
    \$\begingroup\$ I'm not sure what you mean by "wire energy", but even from a space perspective, large buses are expensive, but if doubling the width of a bus cuts its roughly in length in half the overall cost will remain about the same. \$\endgroup\$
    – supercat
    Commented Jul 2, 2014 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.