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
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
Thomas Koenig wrote:
For anybody who ever wondered what exactly the 8088 was doingI always thought the 4 cycles was inherited from the 8080/Z80 cpus and
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
their support chips which the PC was going to use.
Terje
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).
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.
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.
On 5/15/24 3:30 PM, BGB wrote:
In my case, I hadn't found much information about accessing SDcards inThe SD card specification covers both in detail.
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.
But the 4 bit wide SD access will depend a lot on what hardware support
you have. I used an ARM (in a Teensy 3.2) to do the job. Mostly quite similar to SPI access.
When looking around before, I generally only found people talking about
the SPI interfaces. Granted, I didn't have the official specifications (which seemed to be paywalled and not generally available otherwise). I mostly implemented stuff based on information I found on various websites.
We are talking about 1978 here. Back then, it was 7-bit raw addres
and 7-bit column addresss. I don't know how they applied address bits
above A13. Later on there were chip select and/or output enable signals,
but circa-1978 16-bit DRAM had neither of those. So, it seems, if one
wanted to put more than 16 KB on 8-bit bus, one had to generated
multiple sets of RAS# and CAS# signals.
On 5/15/24 6:48 PM, BGB wrote:
When looking around before, I generally only found people talkingParts of it are/were paywalled but the interesting bit hasn't been. At
about the SPI interfaces. Granted, I didn't have the official
specifications (which seemed to be paywalled and not generally
available otherwise). I mostly implemented stuff based on information
I found on various websites.
least as far back as SD 1.0.
https://www.sdcard.org/downloads/pls/
I am not sure which one of those is the one to look at. Probably the one with the 9.1 revision level.
Seems I was wrong about something before:
The combination of CMD0+CS is what selects SPI mode (for normal SD mode,
the CS signal would not be asserted).
I was mistaken in thinking that it was the stream of FF bytes and then asserting CS near the end (say, the init procedure for the SDcard
involving sending a large number of FF bytes at a fairly low speed, then sending some other commands and boosting the speed to the intended
operating speed).
On 5/16/24 4:21 PM, BGB-Alt wrote:
Seems I was wrong about something before:The low speed was a holdover from its previous life as the MMC card standard. (I still have a 64MB MMC card.) Which were intended to be a multi-drop solution. As such some of the signal lines were open-drain/collector so the speed was limited by the pullup resistor and parasitic capacitance.
The combination of CMD0+CS is what selects SPI mode (for normal SD
mode, the CS signal would not be asserted).
I was mistaken in thinking that it was the stream of FF bytes and then
asserting CS near the end (say, the init procedure for the SDcard
involving sending a large number of FF bytes at a fairly low speed,
then sending some other commands and boosting the speed to the
intended operating speed).
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 762 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 103:24:01 |
| Calls: | 12,295 |
| Calls today: | 1 |
| Files: | 186,558 |
| Messages: | 2,254,824 |