UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor berryjatsc
Visitor
3,459 Views
Registered: ‎02-14-2017

Zynq SDIO peripheral detailed information

Is there a detailed datasheet for the SDIO peripheral in the Zynq-7000 chip? I have looked through the SDIO section of the Technical Reference Manual, but I would like to see more information about registers and the DMA engine. I am trying to implement some data logging to an SD card and need as much performance as I can squeeze out. I am seeing how fast I can make it go and trying to understand where the bottlenecks are. The driver source code (I am using the standalone BSP) gives me some insights, but without other documentation, it is hard to determine why they did some things.

Tags (3)
0 Kudos
4 Replies
Scholar ericv
Scholar
3,439 Views
Registered: ‎04-13-2015

Re: Zynq SDIO peripheral detailed information

To give you an idea of the kind of performance you may be able to get with the SDIO, with our own DMA based driver (not using any BSP resources) we typically get between 500 to 1000Kbyte/s sustained write transfers and 3 Mbyte/s to 8 Mbyte/s sustain reads. The high variability is due to the specific SD/MMC card used. Some are much faster than others
These measurements are done writing and reading files going through the FatFS stack. Doing raw transfers will definitely show a higher throughput.
If you want to have a look at our driver code to better understand how to use the peripheral, you can request a free standalone version at:
code-time.com
Regards
0 Kudos
Visitor berryjatsc
Visitor
3,413 Views
Registered: ‎02-14-2017

Re: Zynq SDIO peripheral detailed information

@ericv thanks. I requested access to the driver code, I believe. I filled out the form on the website and then it created an email, which I sent. Is that correct? Do you know what documentation was used to develop the driver code?

 

0.5-1.0 MBps write is not fast enough for what we need. I am hoping to be able to use a more raw write strategy and then shoe-horn filesystem data around that. We only need the SD card to log data, so I think that should work. I have been able to get write speeds up around 12-13MBps using a Sandisk Ultra 32GB card. That's still only about half of the 25MBps signaling rate. We were hoping to use the card in an UHS mode, but from what I can tell the host controller does not support that (probably mostly due to the fact that it has to switch to 1.8V signalling for that). It is confusing that the driver code has support for it.

0 Kudos
1,722 Views
Registered: ‎03-05-2015

Re: Zynq SDIO peripheral detailed information

How did you get the 12-13 MB / s speed. Are you using xilffs. For my application, I need around 12 MB / s but xilffs functions (f_write) are toooo slow. 

Can you please give me any pointers to increase the speed. 

0 Kudos
Visitor berryjatsc
Visitor
1,710 Views
Registered: ‎02-14-2017

Re: Zynq SDIO peripheral detailed information

@roberfrenanc091 I am using a copy of xilffs that I have modified. These are the things I have found that are important for writing quickly to the SD card:

  • Write speed is largely dependent on the amount of data you write at once to the SD card. Data transfer is done by DMA and supports up to 32 descriptors which support up to 64kB each. This means you can transfer up to 2MB of data in a single DMA transfer. The closer you can get to that, the better shape you will be in.
  • You want to try to minimize the FS overhead. If you are not familiar with how the FAT32 filesystem works, I recommend reading up on it. Wikipedia is a good place to start. You need to understand things like FAT entries, clusters, directory entries, sectors.
  • Formatting the SD card with the largest cluster size possible (64kB) will help with speed. This means you only have to allocate one FAT entry for each 64kB block you want to write. The downside is that if you want to write a small file, the minimum amount of space it will take up is 64kB. But if you are concerned with speed, you should not be writing small files.
  • Only write one file at a time. Less FS overhead that way.

 

Here are some of the changes I made to the code:

  • I created a new create_chain() function that will allocate some number of contiguous FAT entries. The one in xilffs only allocates one at a time. This allows me to write data to multiple, contiguous clusters at once.
  • I ensure that I always write a multiple of the cluster size. This simplified my logic and ensured I was writing a large amount of data at once and did not need to do any read-modify-write cycles (technically, I could have just limited it to writing a multiple of the sector size, 512bytes, at a time).
  • For my application, I needed to start the write process and do other things while the write happened over DMA. So I split out the write process into a write start and check for finished. If your software does not need to do anything else while writing, this may not benefit you.
  • I only write one file at a time and always write them to the root directory of the card. This helps keep things simple and ensures I can write contiguous clusters when writing my file data. Again, the more you can write to the card at once, the better off you will be.

I recommend testing things out at first without regard to the file system. Use the low-level SD write functions to just write data somewhere on the disk and see how fast you can get it to go. If you cannot get the speed you need doing that, then you won't be able to do better once you have to deal with the filesystem. I also recommend the hex editor HxD. It can open disks so you can look at the raw data on the disk to be able to see the FAT entries and actual file data blocks.

0 Kudos