This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SK-AM64B: Question about SDHC transfer

Part Number: SK-AM64B

Hello
I am currently measuring timestamps as shown in the diagram.
Host                     SD Card
 |                               |
 |--CMD24/25------>|   <===send command
 |                               |
 |<------R1b---------|   <====wait for response from card
 |                               |
 |--DATA----------->|   <====transfer data to card(DMA/PIO)
 |                              |
 |<------DONE------|   <====data written done

For the start time of the data transfer (DMA/PIO), I added a timestamp right before the following line in the sdhci_send_command()(in sdhci.c) function:

sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);

My question is: Does the measured time include the processing time for DMA setup, register configuration, and other host-side overhead that occurs after this timestamp?

When continuously writing 16 KiB blocks to the SD card, the measured time from “start of transfer” to “data written done” is approximately 860 µs.

What I want to understand is:
How much of that 860 µs is due to the SD card’s internal processing (FTL, etc...), and how much is host-side overhead?

Should I exclude host-side processing time (such as DMA setup) from the overhead when analyzing the FTL time?
Any advice would be appreciated.
Best Regars,

H.Wad

  • Hi Wada,

    My question is: Does the measured time include the processing time for DMA setup, register configuration, and other host-side overhead that occurs after this timestamp?

    From a software perspective, the DMA (specifically the controller's internal DMA) and any other necessary register configurations would have been done before initiating the command by writing to the COMMAND register. Once this register is written, it's all hardware internal logic from actually initiating to completing the command.

    Regards,

    Prashant

  • Hello Prashant-san,

  • Hello Prashant-san,

    Thank you so much!!

    I am clear.

  • Hi Wada-san,

    Does my previous response really answer your query?

    I clarified from the software perspective only. The time 860 µs you observe should definitely include an overhead from the host controller's and the SD card's internal logic but I can't comment on the overhead numbers.

    If you would like to inquire further, I can loop in our hardware expert for further clarifications.

    Regards,

    Prashant

  • Hello Prashant-san,

    Thank you very much for your response.
    Regarding the observed 860 µs, I had assumed that this duration mainly corresponded to the SD card write time. If possible, I would appreciate it if you could provide more details on the specific amount of overhead involved.
    For your reference, the conditions under which the 860 µs was observed are as follows:
        -16 KiB of data was written to an SDR104-compliant SD card
        -The write operation was performed in O_DIRECT mode
        -Continuous 16 KiB write operations were executed for 10 seconds

    Thank you in advance for your kind support.
    Best regards,
    Wada

  • Hello Wada Hiroshi-san,

    Thank you for your additional questions !

    Prashant will be able to answer tomorrow or early next week.

    Thank you 

    Best Regards

    Anastas Yordanov

  • Hello Anastas-san,

    Thank you for the update.

    I look forward to Prashant-san's response.

    Best regards,
    Wada

  • Hello Wada,

    I understand that you need more information on the AM64B SDHC hardware caused delay (out of the total 860us) in the CMD 24/25 request / response interaction. We may need to internally discuss with the AM64x SDCard host design / integration team.

    Please expect our response on your hardware related question early next week.

    Thank you

    Kind Regards,

    Anastas Yordanov

  • Hello Wada Hiroshi,

    Would you please specify the type of the SDR104-compliant SD Card  that you use ?

    Thank you !

    Best Regards

    Anastas Yordanov

  • Hell Anastas-san,

    The SD card we are using has the following specifications:
        Manufacturer: SanDisk
        Capacity: 256 GB
        Class: UHS-I Class 3
        Model number: SDSQXFN-256G-GN4NN

    Best regards,
    Hiroshi Wada

  • Hello Wada Hiroshi,

    Your SanDisk® microSDTm Express Card class-III 256GB is UHS-I compliant and should be able to operate with the AM64x SDHC at the UHS-I write speed supported by the card. The AM64x SDHC host does NOT support the microSD Express mode hence it does NOT support the Express mode write speeds, listed below. 

     I am not able to find a complete specification of  the SanDisk MicroSD Card. Can you please provide data about the supported continuous write speed in UHS-I mode (SDR104) or the complete specification itself. Please provide in private E2E chat in case this is a SanDisk sensitive data. For your microSD Card we shall expect that it supports write speeds to be less than 104 MBytes / sec. The card supported read speed is max 104 MBytes/sec. According the AM64x TRM, the AM64x SDHC  supports 100 MBytes/sec bus in SDR104 for reading and writing accesses. 

     

    Q1. What is the average nominal duration in [uS] that you expect since "start of a 16 KiB sized block transfer" from the SDHC to the SD Card until "Data written done" response in the specified scenario (continuous transfer of 16 KB blocks) ?

    Q2. Is SDHC configured to operate in SDR104 during the observation ? If this is the case, please confirm whether a 200 MHz SDMMC1_CLK is observed with an oscilloscope probe at the SD Card CLK pin.

    Q3. To enable the SDR104, have you performed the ultimate sampling clock tuning ? 

    Q3. What is the identical duration time in a single 16 KB block write transfer scenario ? What are the fastest microSD write rates that you have achieved on the SK-AM64B EVM ?

    Thanks for the clarification !

    Kind Regards

    Anastas Yordanov

  • Hello Anastas-san,

    Q1. What is the average nominal duration in [uS] that you expect since "start of a 16 KiB sized block transfer" from the SDHC to the SD Card until "Data written done" response in the specified scenario (continuous transfer of 16 KB blocks) ?

      ->The average duration was 929 µs.

    Q2. Is SDHC configured to operate in SDR104 during the observation ? If this is the case, please confirm whether a 200 MHz SDMMC1_CLK is observed with an oscilloscope probe at the SD Card CLK pin.

      ->According to the kernel log, the clock frequency was 200 MHz and it indicated that SDR104 mode was configured. Based on this, we concluded that the SDHC was operating in SDR104 mode.
    We did not observe the 200 MHz clock using an oscilloscope probe. Unfortunately, we are currently using the board for another purpose, so we are unable to verify this at the moment.

    Q3. To enable the SDR104, have you performed the ultimate sampling clock tuning ?

      ->No. We believe that the ultimate sampling clock tuning was performed by the SDHCI driver.

        We were not aware of the ultimate sampling clock tuning at the time.

    Q4. What is the identical duration time in a single 16 KB block write transfer scenario ? What are the fastest microSD write rates that you have achieved on the SK-AM64B EVM ?

      ->The required duration for a single 16 KB block write transfer scenario was 1070 µs.
    The fastest microSD write rate achieved on the SK-AM64B EVM was 60 MB/s.

    Best Regards,

    Hiroshi Wada

  • Hello Wada Hiroshi,

    Thank you for your prompt updates.

    A simple theoretical calculation (disregarding any CMD and Resp overhead)  shows that  the actual Data block write time is 16KB / 60 MBytes/sec = 16 KB / 60*1024 KB/sec ~ 260 uS  

    I need to check how to simply verify whether ultimate sampling clock tuning is made by the SDHC driver. This is highlighted to be important to enable operation in the SDR104 mode.

    Would you be able to capture some oscillograms of the SDMMC1_CLK, SDMMC1_DAT0, SDMMC1_CMD with the scope as well. 

    I am looking forward to your inputs.

    Thanks

    Kind Regards

    Anastas Yordanov

  • Hello Anastas-san,
    Due to current circumstances, the board is not available for use, so we are unable to capture the waveforms of the SDMMC1_CLK, SDMMC1_DAT0, and SDMMC1_CMD signals.
    If we encounter a similar issue in the future, we will consult with you again at that time.

    However, the information regarding the ultimate sampling clock tuning was very helpful.
    Going forward, when operating in SDR104 mode, we will pay close attention to the ultimate sampling clock tuning.
    Thank you very much for your continued support.

    Best Regards,
    Hiroshi Wada

  • Hello Wada Hiroshi,

    I am glad this was helpful. 

    I am going to close the thread now.

    In case you have new concerns, please create a new thread.

    Thank you !

    Best Regards,

    Anastas Yordanov