Some comments, based on the SPI bus protocol defined for SD and MMC cards (note that I have not reviewed or analysed the SPIMASTER core)...

For a fixed-length block read (e.g. 512 bytes), the sequence is as follows:

1. Single block read command (CMD17) is sent, along with 32-bit address. (note: in setup, the SET_BLOCKLEN command sets the block size, unless the SD card is an SDHC card. SDHC cards have fixed block length of 512 bytes).

2. wait for the first '0' bit from the slave. This '0' will be the MSB of an 8-bit response byte. Following this response byte, the MISO line will revert to '1' until the read data is ready for transmission from the SD card.

3. wait for the next '0' bit on the MISO line. This is a single-cycle start bit, and the next 512 bytes received from the SD card will be the requested block of data.

If my reading of the SD card SPI protocol is correct, there is no need for any 'timing' loops for normal operation. The communication between the SD card and the host controller is self-synchronising, using 'start' bits to mark the beginning of commands, response tokens, and data.

You should be able to measure the access time of the SD card. It is the delay from host writing the block read command to the SD card to the 2nd 'start bit' from the SD card to the host. By measuring this access time, the effective read bandwidth of your SD card should be pretty simple to calculate -- and you can separate what the SPI interface and SD card can support separately from what the SPIMASTER core currently allows. It could very well be that the data transfer bottleneck is the SPIMASTER code, in which case you are at liberty to optimise the code and post the improvements to the opencores forum :)

- Bob Elkind

A few corrections/additions - Bob


My original description is very poor, even misleading. Here is a better wording:

3. Wait for the next non-zero byte on the MISO line. A value of 8'hFE represents the beginning of data transmission from the SD card. A value of 8'b000xxxxx signifies an error condition ("data error token").

Also I omitted any references to CRC-16 value following the 512 bytes of data.

In order to read a 512-byte block, a minimum of 522 bytes must be transferred between the host and SD card:

6 bytes: CMD (1) + address (4) + CRC (1)
1 byte: Command response from SD card
513 bytes: data block header (1) + data (512) + CRC-16 (2)

Any additional time is the read access time of the SD card (plus overhead in the host controller design).

Hi Bob !
I was able to read the time between the send command to read a token and it's response (although it is every eight bits read), and this is about 480nSec,it's similar the time as the code send the FIFO WE pulse, it is so difficult to get the time between the send command pulse and the first bit.
Would be great to know, what it that loop for, that I mentioned before in the original code.
Cheers.
Alberto.

Hi all !!
I'm back again.
Last days I was doing a research of what is happening with this code, and I found another "issue".
The spimaster code works only in single write/read blocks, that is so slow for the cards too, so I've decided to write a code in "C language" using a setup in NIOS II of my DE2 board.
What I get is the following:
Using SPI mode, single block reads, I get about 265KB/sec speed, then using multiple block reads, I get 765KB/sec !!... (After that I've decided to try the card in 4bit SD Mode).
First I've modified my DE2 hardware to let connect all the DAT pins of the card to some I/Os.
Then I've tried an SD Mode in NIOS II succesufully, and I get it works !!!!
I've get 1.5MB/sec in single block reads, and then my best speed until now of 2.85MB/sec reads in multiple blocks read, that is great !! and think ...that is using NIOS processor...so....

I've decided to write a 4bit SD Card Mode core, just I'm doing that, but it will take me a bit of time to get it work, anyway I will post again when it's finished.

Thank you so much Bob, for all you teach me, answering questions in this thread.

That is very good news. Congratulations on your breakthroughs.

I would be very interested in seeing your updates to spimaster code, supporting multi-block reads, etc. This would be useful and interesting to a number of people.

It's interesting that the 756KBytes/sec throughput in SPI mode is still well short of the theoretical maximum 1.5MBytes/sec achievable with a 25MHz SPI clock.

For your native-mode SD (4-bit) design, I'm not sure that you should post the code. Native SD interface is covered by non-disclosure and license fees through the SD Card consortium. As this information is legally confidential, posting the code might be a legal liability issue for you, or for the 3rd party who delivered confidential information to you, or to opencores.org for hosting a retrieval site for such information.

The rights protections for SD card information is probably the primary reason you don't see open source SD card host controller cores on the web.

Again, you have won a hard-fought battle and learned much along the way. Well done!

Regards,
Bob Elkind

Thank you Bob !!
But I think you misunderstanding what I mean.. I've get the multi block reads with my C code in NIOS II, not in spimaster (or maybe I explained it bad).
About to post the 4 bit Mode code, I forget it... Could be dangerous for me :)
Anyway I will comment my progress when ready, just for get fun.
Cheers.
Alberto.

Hi everyone!

I just found this thread and it was very useful for me, thank you all. However, I found out the SPImaster Core has one big weakness. I'm unable to get/read the size of the SDcard. The only functionalities are init/read/write (single block only).

Is there any way to extend the Core functionality to read the size of the SDcard or to read the CSD Register (Card Specific Data) via CMD9? If yes - how?

Thanks and greetings from germany

Christian

The answer is simple: supporting CMD9 function is a mandatory requirement of the SD Card spec and the MMC card spec (v4.2 and earlier). The MMC card spec version 4.2 is freely available. The SD card spec (level 2 and level 3) are available for download to SD Card licensees.

If you are moderately proficient at reading specification docs and writing (and debugging) Verilog code, and if you also have SPIMASTER up and running in your design, it should be quite simple for you to either add CMD9 function to the existing SPIMASTER code or use CMD9 function with the existing code.

I'm not familiar with SPIMASTER code, my assertions are based on a reading of the specification documents.

It may well be that SPIMASTER code already supports CMD9 function, or someone has already added CMD9 function to SPIMASTER code base. If neither of these is true, perhaps you have the time, skills, and inclination to answer your own question. It may be easier to start solving your needs on your own, and then solicit help from this forum if or when you run into roadblocks. This approach is more likely to be successful for you than waiting.

-- Bob Elkind

Yep, thank you. You're completly right. As you mentioned, I just asked in hope that maybe someone already included the CMD9 function. For this doesn't seem to be the case, I'll try it on my own an post my solution here as soon as I think it's ready.

I already read the CSD Register with the Altera SPI-Core (3-Wire) so im familiar with the Command and Response structures. Unfortunatly the Altera SPI Core didn't work out quite well with some SD-Card manufacturers so I switched to the SPImaster Core. Well, let's see how it works :)

Questions which may be interesting {and not to just me}:

1. Who/what is the supplier of the Altera SPI-Core? Is this an Altera freebie core or something else?

2. Any details on why the "Altera SPI-Core" 'didn't work out quite well' ? The mandatory SPI functions which work with one MFR's SD card should work with all MFR's (and all models) of SD card, with the following "exceptions":

a. 4GB and larger SD cards are SDHC, and this affects block size and functions which depend on block size.

b. MMC cards and SD/SDHC cards are initialised differently, perhaps one case is not handled properly.

c. MMC and SD/SDHC cards power up in non-SPI mode. If the core is a generic "SPI" core without the proper initialisation routine for MMC/SD/SDHC cards, this may be an issue.

So... for my knowledge and edification, I'm interested in whatever insight you can "spill" on the subject... as long as the information is not protected by a confidentiality agreement.

-- Bob Elkind

Hi Bob,

1. the Altera SPI (3-Wire) Core is supplied by Altera for free, you should be able to find it in the SOPC Builder. More information can be found here: http://www.altera.co.jp/literature/hb/nios2/n2cpu_nii51011.pdf

2. Yep, they SHOULD, but in my case they didnt. I wrote some code to Init/Read/Write (single block) via the Altera SPI Core. I used the exact same code on a Transcend 1GB miniSD, and two SanDisk MicroSD's. Init and Read worked well on all of them, but when writing a block i got some weird 3Bit Offset for the miniSD's. Basicly the whole Block was right shifted by 3Bits. I fixed the problem by adding some wait time, but then the MicroSD's got problems with writing. That's were it got frustrating. I tried reducing the SCLK and also played around with the phase and polarity - no success.

Another big problem of the Altera Core is, that it only provides one function to write and read Byte to/from the SD-Card: alt_avalon_spi_command();

Also, you're completly unable to change the clock on the fly with this function, which could be annoying since some SD-Cards should be initialized with 400KHz and can then be kicked up to 25MHz again.

And yep, you're right. There are some differents when working with SDHC's but I didnt use any.

Greetings

--Chris

Hi Bob,

1. the Altera SPI (3-Wire) Core is supplied by Altera for free, you should be able to find it in the SOPC Builder. More information can be found here: http://www.altera.co.jp/literature/hb/nios2/n2cpu_nii51011.pdf

2. Yep, they SHOULD, but in my case they didnt. I wrote some code to Init/Read/Write (single block) via the Altera SPI Core. I used the exact same code on a Transcend 1GB miniSD, and two SanDisk MicroSD's. Init and Read worked well on all of them, but when writing a block i got some weird 3Bit Offset for the miniSD's. Basicly the whole Block was right shifted by 3Bits. I fixed the problem by adding some wait time, but then the MicroSD's got problems with writing. That's were it got frustrating. I tried reducing the SCLK and also played around with the phase and polarity - no success.

Another big problem of the Altera Core is, that it only provides one function to write and read Bytes to/from the SD-Card: alt_avalon_spi_command();

Also, you're completly unable to change the clock on the fly with this function, which could be annoying since some SD-Cards should be initialized with 400KHz and can then be kicked up to 25MHz again.

And yep, you're right. There are some differents when working with SDHC's but I didnt use any.

Greetings

--Chris

Hi all.
Good news !!
I've done a SD controller doing a mix between NIOS II and HDL.
What I've get until now is about 9.6MBytes/sec reading a file in multiblock mode.
Obviously, the loop part of the code, where the data is read, is in hardware, while the commands send , Ncc, and Ncr, are in software (C code in NIOS II).

The results are impressive for me, more than I expected, although the poor card that I've in my hands was read at 8.0MBytes/sec. This is amazing !!

Hi all.
If somebody try to contact me, please enter to my site, and you'll get my email.
The site is my nick plus .ar
Cheers.
Alberto.

PS: Sorry but I know that some guy is trying to contact me and he can't get my info, why not to google btxsistemas ?