Re: Article on the 8088 bus cycle

On 5/15/2024 6:37 AM, Terje Mathisen wrote:

Thomas Koenig wrote:

For anybody who ever wondered what exactly the 8088 was doing
while it was wast^H^H^H^Husing four cycles per memory access,
here's an interesting article:
>
http://www.righto.com/2024/04/intel-8088-bus-state-machine.html
>

I always thought the 4 cycles was inherited from the 8080/Z80 cpus and their support chips which the PC was going to use.
 

Though, does seem like that era of RAM is easier to deal with than more modern RAM (such as DDR2/DDR3), where one needs to deal with opening/closing rows and using burst transfers to send/receive data, ...
Though, 4 cycles per byte would not be fast, particularly at low clock-speeds.
Still kinda interesting in a way.
Seems like probably in a similar area as QSPI RAM.
Quick skim, looks like QSPI RAM access looks something like:
   Pull CS low;
   Send command byte;
   Send address bytes (4);
   Send/receive data bytes;
   CS goes high when transfer is done;
     CS going high apparently puts the chip back in its idle state.
If you do a 16-byte burst, this would be ~ 1.4 cycles (DDR) per data byte, or 2.8 cycles if driving it from a faster SDR clock. A datasheet for a random QSPI RAM chip I found suggests it has a maximum operating frequency of around 54 MHz (so, a little lower than the DDR chips), and a lot are apparently "pseudo static" (they are DRAM internally, but also perform their own RAM refresh, appearing as SRAM from the POV of the external bus interface).
Apparently also if the 4 IO lines are pulled high, and it is then given 8 clock cycles with CS pulled low, the chips will go into SPI mode and expect plain SPI signaling from then on (seems to be similar to how it works with SDcards, *). Similarly, QSPI Flash seems like an intermediate between the SRAM interface and an SDcard.
*: But makes me wonder if the reverse is true:
If the 4-bit DDR signaling for SDcards basically the same protocol that one uses over SPI, just sent 4 bits at a time on the rising/falling clock edges?... (Effectively following a similar pattern to the QSPI RAM and Flash modules).
In my case, I hadn't found much information about accessing SDcards in anything other than SPI mode, but I guess if it turns out it is basically just QSPI and the same byte-oriented protocol as before, that would be useful to know.
Though, not of much immediate relevance:
Would still need to design a more efficient MMIO interface or a DMA mechanism or similar before I could gain much additional bandwidth from such a thing.
The original 8-bit MMIO interface hitting a wall at around 600K/s, and the current 64-bit MMIO interface having a hard-limit of ~ 4MB/s; vs ~ 20-50 MB/s which could theoretically be usable in a QSPI like mode, provided there is a way to access it. Reading to/from an MMIO buffer would still be a bottleneck, would need some way to initiate a block-transfer to/from the L2 cache.
I guess, could theoretically hack it onto my existing MMIO interface, just beyond just the EMIT and EMIX8X flags, there could be an EMITDMA_R/EMITDMA_W flags or similar, where the 64-bit SPI_QDATA register is instead used to encode a memory address and a block size, and the SPI module will read/write the requested block (then maybe add other flag for SPI vs QSPI/SDR and QSPI/DDR operation, ...).

Terje