I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in
standard 8 pin package.

I'm not sure I correctly understood the quad mode. It appears to me two
quad modes are supported: SPI Quad mode (IOC=1 in Configuration
Register) and SQI mode (after sending Enable Quad I/O command).

For example, after setting IOC bit in Configuration Register I can use
SQOR command (SPI Quad Output Read) to output data from SIO[3:0] pins.

A similar behaviour can be obtained after enabling SQI mode (sending
EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B).

What is the difference? I think the difference is only in the data
transmitted by the SPI master: opcode byte, address bytes and dummy
bytes. In the first case, they are transmitted serially on a single
signal (SI/SIO0); in SQI mode, they are transmitted serially on 4
signals (SIO[3-0]). The behaviour on data transmitted by the serial
Flash should be exactly the same: they are transmitted on the 4 signals
SIO[3-0].

Is my understanding correct?

I think the penalty of the first Quad mode respect the SQI mode is very
small.

On 2023-04-04, pozz <pozzugno@gmail.com> wrote:
> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in
> standard 8 pin package.
>
> I'm not sure I correctly understood the quad mode. It appears to me
> two quad modes are supported: SPI Quad mode (IOC=1 in Configuration
> Register) and SQI mode (after sending Enable Quad I/O command).
>
> [...]
>
> [...] I think the difference is only in the data transmitted by the
> SPI master: opcode byte, address bytes and dummy bytes. In the first
> case, they are transmitted serially on a single signal (SI/SIO0); in
> SQI mode, they are transmitted serially on 4 signals (SIO[3-0]).

That sounds right -- that's how I remember it.

> The behaviour on data transmitted by the serial Flash should be
> exactly the same: they are transmitted on the 4 signals SIO[3-0].
>
> Is my understanding correct?

I think so.

> I think the penalty of the first Quad mode respect the SQI mode is
> very small.

For things like a bootloader which sends one read command and then
shifts out many KB of data, the difference is not noticable. You might
be able to see a difference if you do a lot of large writes. or a lot
of very small reads.

--
Grant

On 04/04/2023 22:57, pozz wrote:
> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in
> standard 8 pin package.
>
> I'm not sure I correctly understood the quad mode. It appears to me two
> quad modes are supported: SPI Quad mode (IOC=1 in Configuration
> Register) and SQI mode (after sending Enable Quad I/O command).
>
> For example, after setting IOC bit in Configuration Register I can use
> SQOR command (SPI Quad Output Read) to output data from SIO[3:0] pins.
>
> A similar behaviour can be obtained after enabling SQI mode (sending
> EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B).
>
> What is the difference? I think the difference is only in the data
> transmitted by the SPI master: opcode byte, address bytes and dummy
> bytes. In the first case, they are transmitted serially on a single
> signal (SI/SIO0); in SQI mode, they are transmitted serially on 4
> signals (SIO[3-0]). The behaviour on data transmitted by the serial
> Flash should be exactly the same: they are transmitted on the 4 signals
> SIO[3-0].
>
> Is my understanding correct?

Yes.

In SPI Quad mode, /data/ is send 4 bits per clock (or twice that, for
double data rate pins). In SQI mode, /everything/ is sent 4 bits at a time.

>
> I think the penalty of the first Quad mode respect the SQI mode is very
> small.

It all depends on your clock speeds, your mix of reads and writes, your
wait states, the length of your transfers, etc. If you are doing big
transfers then there will be little difference since most clocks are
data anyway. For lots of small transfers with few wait states, SQI will
make a bigger difference.

(And if you are doing big data transfers, you might also want to enable
double data rate on the pins, if your hardware supports it.)

Il 05/04/2023 17:52, David Brown ha scritto:
> On 04/04/2023 22:57, pozz wrote:
>> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory in
>> standard 8 pin package.
>>
>> I'm not sure I correctly understood the quad mode. It appears to me
>> two quad modes are supported: SPI Quad mode (IOC=1 in Configuration
>> Register) and SQI mode (after sending Enable Quad I/O command).
>>
>> For example, after setting IOC bit in Configuration Register I can use
>> SQOR command (SPI Quad Output Read) to output data from SIO[3:0] pins.
>>
>> A similar behaviour can be obtained after enabling SQI mode (sending
>> EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B).
>>
>> What is the difference? I think the difference is only in the data
>> transmitted by the SPI master: opcode byte, address bytes and dummy
>> bytes. In the first case, they are transmitted serially on a single
>> signal (SI/SIO0); in SQI mode, they are transmitted serially on 4
>> signals (SIO[3-0]). The behaviour on data transmitted by the serial
>> Flash should be exactly the same: they are transmitted on the 4
>> signals SIO[3-0].
>>
>> Is my understanding correct?
>
> Yes.
>
> In SPI Quad mode, /data/ is send 4 bits per clock (or twice that, for
> double data rate pins).  In SQI mode, /everything/ is sent 4 bits at a
> time.

Ok, now suppose you would like to work in SQI mode. During startup you
send the Enable SQI command over a single data line (MOSI). From now on,
you can send SQI commands using 4 data lines even for command code byte
(two clocks).

However you can't be sure at startup the Flash is in normal SPI mode.
This happens when you power up the board, but it's not true when the MCU
resets itself (for example, for watchdog).

What could be the initialization process to bring the SPI Flash in SQI
mode at startup, without knowing if it is already in SQI mode or not?

>> I think the penalty of the first Quad mode respect the SQI mode is
>> very small.
>
> It all depends on your clock speeds, your mix of reads and writes, your
> wait states, the length of your transfers, etc.  If you are doing big
> transfers then there will be little difference since most clocks are
> data anyway.  For lots of small transfers with few wait states, SQI will
> make a bigger difference.
>
> (And if you are doing big data transfers, you might also want to enable
> double data rate on the pins, if your hardware supports it.)

What do you mean with DDR here?

On 11/04/2023 08:46, pozz wrote:
> Il 05/04/2023 17:52, David Brown ha scritto:
>> On 04/04/2023 22:57, pozz wrote:
>>> I'm studying datasheet of SST26VF080A. It's a SPI Quad Flash memory
>>> in standard 8 pin package.
>>>
>>> I'm not sure I correctly understood the quad mode. It appears to me
>>> two quad modes are supported: SPI Quad mode (IOC=1 in Configuration
>>> Register) and SQI mode (after sending Enable Quad I/O command).
>>>
>>> For example, after setting IOC bit in Configuration Register I can
>>> use SQOR command (SPI Quad Output Read) to output data from SIO[3:0]
>>> pins.
>>>
>>> A similar behaviour can be obtained after enabling SQI mode (sending
>>> EQIO=Enable Quad I/O mode) and using High-Speed Read command (0x0B).
>>>
>>> What is the difference? I think the difference is only in the data
>>> transmitted by the SPI master: opcode byte, address bytes and dummy
>>> bytes. In the first case, they are transmitted serially on a single
>>> signal (SI/SIO0); in SQI mode, they are transmitted serially on 4
>>> signals (SIO[3-0]). The behaviour on data transmitted by the serial
>>> Flash should be exactly the same: they are transmitted on the 4
>>> signals SIO[3-0].
>>>
>>> Is my understanding correct?
>>
>> Yes.
>>
>> In SPI Quad mode, /data/ is send 4 bits per clock (or twice that, for
>> double data rate pins).  In SQI mode, /everything/ is sent 4 bits at a
>> time.
>
> Ok, now suppose you would like to work in SQI mode. During startup you
> send the Enable SQI command over a single data line (MOSI). From now on,
> you can send SQI commands using 4 data lines even for command code byte
> (two clocks).
>
> However you can't be sure at startup the Flash is in normal SPI mode.
> This happens when you power up the board, but it's not true when the MCU
> resets itself (for example, for watchdog).
>
> What could be the initialization process to bring the SPI Flash in SQI
> mode at startup, without knowing if it is already in SQI mode or not?

Connect the processor reset and the Flash reset.

Failing that, I suspect you'll find that if you try to send the SPI code
for enable SQI mode while you are already in SQI mode, you'll not do any
harm.

>
>
>>> I think the penalty of the first Quad mode respect the SQI mode is
>>> very small.
>>
>> It all depends on your clock speeds, your mix of reads and writes,
>> your wait states, the length of your transfers, etc.  If you are doing
>> big transfers then there will be little difference since most clocks
>> are data anyway.  For lots of small transfers with few wait states,
>> SQI will make a bigger difference.
>>
>> (And if you are doing big data transfers, you might also want to
>> enable double data rate on the pins, if your hardware supports it.)
>
> What do you mean with DDR here?

Double data rate - data pin changes on both rising and falling edges of
the clock. Many QSPI flash chips support it.

On 4/10/2023 11:46 PM, pozz wrote:
> Ok, now suppose you would like to work in SQI mode. During startup you send the
> Enable SQI command over a single data line (MOSI). From now on, you can send
> SQI commands using 4 data lines even for command code byte (two clocks).
>
> However you can't be sure at startup the Flash is in normal SPI mode. This
> happens when you power up the board, but it's not true when the MCU resets
> itself (for example, for watchdog).

This is the bane of all devices that have "modes"; how do you know that the
I/O pins that you've "programmed" to be outputs are actually outputs, NOW?
Or, that any device requiring a multicycle transaction is in the state
where it is expecting the first of those cycles to be issued, next, in time?

I've found it prudent to have an entry point in the code (called "RESET")
that is treated as an adjective and verb:
- the system is *in* the reset state
- reset the system *to* that state

This ensures that any assumptions one can make for a *device* coming out of
(hardware) RESET apply any time the code executes from that point.

The device can reach that point:
- through the normal PoR process
- through a watchdog or other sentinel
- through a random crash
- as a result of panic()

I usually (start) write this as one of the first pieces of production
code as it gives me a chance to think about how the hardware "comes up"
(you have to think about EVERYTHING, not just the CPU/MCU itself) and
whether or not that can pose problems after deployment (e.g., what if
the motors aren't guaranteed to be stopped, at this point in time?)

It also gives you an idea of those parts of your hardware interface
that need to be atomic, accessed via monitors, etc. Esp if two
different active entities (e.g., two threads, a thread and an ISR, etc.)
can compete for the device "in some yet unforeseen scenario".

> What could be the initialization process to bring the SPI Flash in SQI mode at
> startup, without knowing if it is already in SQI mode or not?

Again, applies to every aspect of a system that has modes (embedded state).

You look at the device and posit the different possible "states" that
the interface may be in; then figure out which assumptions can allow you
to unambiguously drive the interface to a particular state from which
behavior is reliable. E.g., you may opt to put the device in the
"wrong" state (temporarily) if only because getting it *there* may be
easier to guarantee... then, deliberately transitioning from "there"
to wherever you'd ultimately like it to be.

E.g., multicycle interfaces often abort their sequences if a read occurs
when a write is expected (or, might be encountered). So, assuming a
read to be "safe" (for that particular device/situation), you do one or
more reads (discarding the data, if necessary) before you start the
multicycle *write* sequence.

Consider a video LUT. Often, you have to write the address of the
location of interest *within* the LUT to the device before you can
read or write. If you think the device is waiting for this "specify
address" portion of its interface cycle and send "0x44" to it
(because you want to access the 0x44th entry) but, instead, it was
already in the "address specified, waiting for read/write" mode,
then your 0x44 will clobber some "random" (as in, "location that you
can't predict" because you don't know what address had been specified
prior to your barging in on the interaction) location.

And, your subsequent "here's the data that I want to write" will,
instead, be interpreted as the next *address* that you want to access
thereby perpetuating the dyssynchrony.

OTOH, if you had done a *read* operation and knew that this would
reset the little state machine inside the LUT to "waiting for
next address", then that throw-away action can serve to get the
interface back into lock-step with the code (assuming you don't wedge
it later).

The pisser is that you have to come up with a strategy that will
work for any device that might be placed in that role (as the
design evolves).

>>> I think the penalty of the first Quad mode respect the SQI mode is very small.
>>
>> It all depends on your clock speeds, your mix of reads and writes, your wait
>> states, the length of your transfers, etc.  If you are doing big transfers
>> then there will be little difference since most clocks are data anyway.  For
>> lots of small transfers with few wait states, SQI will make a bigger difference.
>>
>> (And if you are doing big data transfers, you might also want to enable
>> double data rate on the pins, if your hardware supports it.)
>
> What do you mean with DDR here?

Instead of a cycle being defined by a rising (falling) "clock" edge, it is
defined by rising *and* falling edges. So, you get twice the throughput
for a given "cycle" (without having to double the "clock" frequency).