Re: Article on the 8088 bus cycle

On 5/15/2024 4:41 PM, MitchAlsup1 wrote:

BGB wrote:
 

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).

 You are forgetting that DRAM RAS occurs after the first 2 address bytes
are latched, and that CAS occurs after the second 2 address bits are latched {and that you are in a deRAS deCAS state already.}
 QSPI at 54 Mhz is just under 20ns per DRAM address/command event not that
much different than current DDRs
 But what current DDRs can do is to partially overlap address/command with
data transfer--I would suspect QSPI could do this too.

I suspect QSPI could not do this, as it does not have separate pins for command and data.
IOW:
   CS, CLK, D0..D3
Seemingly, it seems to be using linear addresses rather than row/column (so, unlike DDRx); seemingly with 32-bit addresses despite most of the chips probably would be able to get by with 24 (maybe it was "less bad" to waste an extra byte on the address than to have separate versions of the messaging protocol, or separate 24/32-bit command variants?...).
Though, SDcard has separate command and data pins in SD mode, I guess this leaves open whether one can send commands in the middle of a block read/write. Probably not worth it though as with 512 byte blocks, it probably wouldn't make much difference (unless the SDcard had a fairly large internal access latency or something).
...