Sujet : Re: Article on the 8088 bus cycle
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.archDate : 17. May 2024, 03:10:05
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v26ea5$1vr1g$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 5/16/2024 6:05 PM, David Schultz wrote:
On 5/16/24 4:21 PM, BGB-Alt wrote:
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).
>
>
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.
Yeah.
Set to 400kHz, send ~ 8K or so worth of FF bytes, send CMD0, etc, then boost up to 12.5 MHz or similar.
Originally, I was using 5 MHz, but did speed things up. I ended up using LZ compression on lots of stuff, as 5MHz was fairly slow (and LZ compression made it faster).
Initially, going beyond 5MHz wasn't done also as this was basically the same as the bottleneck for the original MMIO interface (so I went to a higher speed around the same time that I widened transfers on the MMIO interface from 8 bits to 64 bits).
Theoretically, stuff should work at 25MHz, but generally I had not found operation much over 12.5 MHz to be reliable, 16.7 MHz tended to be unreliable, and 25 MHz didn't work.
Divider logic also limits things, say:
50MHz base clock allows for:
25MHz, 16.7MHz, 12.5MHz, 10MHz, 8.3MHz, ...
DDR operation will not currently be possible over 12.5 MHz.
Here, we need at least 4 cycles for the state-machine logic to do its thing for DDR to work.
Granted, there was some uncertainty as I also tended to use a microSD to full-size SD adapter cable, using the full-size SD cards for testing (where potentially the adapter cable could be reducing what clock-speeds are usable). These adaptors use a small PCB that plugs into the microSD slot, a piece of flat-flex ribbon cable extending from this PCB (~ 8 inches long), and a full-size SDcard interface on the other end, with in this case the flat-flex seemingly soldered directly to the PCBs.
Mostly this was because microSD cards are too small to handle effectively (say, if you drop a full size SDcard, it doesn't just disappear in the carpet or similar).
But, the FPGA boards generally only come with MicroSD cards for whatever reason.
Mostly using 16GB UHS-I cards, as IIRC they were fairly affordable on Amazon at the time (and didn't need much bigger for my projects).
Originally I went for SPI as it was free to use, but the native ("Default Speed" / SDR) mode should now be OK as any patents on this will have presumably expired (and the 4x faster speeds could be worthwhile).