The Flash A25L032 has a normal read mode and a fast read mode. It also has dual and quad read modes that are self-explanatory. However, the difference between the normal and fast modes is not at all clear.
What makes fast mode fast? since they both use a single MISO of SPI anyway? Their timing diagrams are below:
Fast read:
What makes fast mode fast?
The difference is certainly well-hidden :-) Look at the AC Characteristics table in the datasheet. It says that the normal READ command (03h) has a maximum clock frequency of 65 MHz. Whereas all other commands, therefore including the FAST_READ command (0Bh), have a maximum clock frequency of 100 MHz:
This is why FAST_READ can be faster, depending on the actual clock frequency chosen.
However due to the dummy byte required when using the FAST_READ command (but not when using the normal READ command), then if both commands are used for many small reads with a clock frequency of <=65 MHz, then the data throughput would actually be slower when using FAST_READ commands, compared to using READ commands, due to the overhead of all the dummy bytes (one per FAST_READ command sent to the device).
If a faster (>65 MHz) clock frequency is used, and if fewer but larger FAST_READ commands were used (because the dummy byte overhead is "per command"), then the greater throughput would start to outweigh the overhead of the dummy bytes.
Why not just have a single mode that can work upto 100MHz?
This is getting into the realm of speculation - I suspect that there is an internal minimum latency required to start the data read process (perhaps charging the internal charge pump?).
My hypothesis is that the latency could be "hidden" behind the time required to receive the READ command at <=65 MHz (i.e. relatively slower speeds), but the required latency (before starting to read) is longer than the time taken to receive a READ command at >65 Mhz (i.e. relatively faster speeds). That could explain why a different command protocol (which adds an extra byte before the data read phase starts) is needed for faster speed reading. A dummy byte is required for the FAST_READ and FAST_READ_DUAL_OUTPUT commands, and a mode byte is required for the FAST_READ_DUAL_INPUT_OUTPUT command. These bytes all serve to delay the start of the data output phase, which suggests to me a fixed internal latency requirement - something which I have seen before with other devices. Of course the real answer would need to come from the manufacturer :-)
FAST_READ commands benefit the most, and could approach the improvement in throughput based just on the increase in FAST_READ clock speed above 65 MHz, compared to READ commands at 65 MHz (e.g. if the whole device is read in one command, then the overhead is just one dummy byte!).
\$\endgroup\$
After a certain number of address bits have been received, a flash chip can initiate the process of reading a row. That process can be accomplished concurrently with receipt of the next bits of the address. If the master manages to finish sending the address and start clocking out data before the device is ready, the device would be unable to clock out valid data (since it wouldn't be available at the output logic) and would instead clock out possibly-erroneous data.
If the master were to pause sufficiently between sending the rising edge for the last bit of the address and the falling edge to read the first word of the data, the device probably wouldn't care if the address and data were clocked the 100MHz rate or the slower 65MHz rate. In many cases, however, it's easier for a bus master to clock out an extra word than to delay for a short measured amount of time, so specifying two ways of reading out data (use a data rate that's slow enough to eliminate the need for a pause, or insert dummy byte to effectively generate an 80ns pause) which can both be accomplished with uniform-speed clocks made the spec simpler than it would have been if it had to include a minimum time between the receipt of particular address bit and the read-out of the first bit of data. In most cases where a system would be able to receive data faster than 65MHz, it would be able to send the high-speed read command complete with extra byte in less time than would be required to send the slow-speed command at 65Mhz. While there are a few cases where the hardware to send a command would be limited to 65MHz but the hardware to clock out data could do 100Mhz(*), and while it might have been useful if the spec provided for that scenario by saying that either command could clock data at 100Mhz once the command itself was fully transmitted, I wouldn't think having to clock the extra dummy would be a hardship even in that case.
(*) This scenario would mainly be relevant in cases where the data was being fed directly to some other device. As a simple example, a device to output static composite video displays stored in ROM might use data stored as six bits packed samples to be clocked at a rate of four samples per 3,579,545.45Hz chroma cycle (a data rate of about 85,909,090.9 bit/sec--faster than 65Mhz). If the microcontroller were running at that clock speed, its SPI port may only be able to run at half that speed but it might be able to switch the flash chip's clock source between SPI clock and the raw 85.9MHz clock.
Internal sense circuit takes around 15~20ns(1~1.5 cycles) to distinguish data. With word data sense, internal circuit uses the A0 input cycle to sense the core data and then clock out what A0 point to. Therefore, <65MHz doesn't need dummy cycles. If go beyond 65MHz, internal circuit needs exta clock to prepare data.
If that chip design with double word sense, then you can try READ with faster clock.
