SD card emulation

Emulating an SD card in FPGA - with ?data? stored over USB on host PC. I?m testing single board computers and wearing out SD card by const antly flashing them with different builds, not to mention it tiring to keep swapping cards in & out. So I?d like to emulate and SD card and ?store? the data on a host pc connected via USB. Diagram: microSD interface USB Host computer with SSD storage I will be using the SD 4-bit interface and would like to hit transfer speed s > 50MB/s, the clock should be ~100Mhz. Is it possible to do this with the Arty-7 kit? Or Zynq-7010? I have those r ight now, something more purpose specific and cheaper would be helpful to k now as well.

Reply to
Sri G
Loading thread data ...

I did a little search and found a hackaday page on this by antti.lukats. I have seen him around here before talking about his interesting projects. The hackaday page doesn't seem to include files or even any detail, just a photo. If you can get in touch with him, I expect he could share his HDL and maybe some of his thoughts.

Interesting project. Is an SD card dimensions compatible with a standard 0.062 inch thick PCB? I can find that the SD card is 0.083 inches thick (2.1 mm) I believe the pins are recessed with raised sections between them making the contact area a different thickness.

On the other hand, SD is not really an open spec. Can you use USB flash memory instead? That should be a lot easier to interface to.

--

Rick C
Reply to
rickman

Forgot the link...

formatting link

--

Rick C
Reply to
rickman

I suspect it's just SPI mode, but you never know.

It's possible to make something - you may have to pad the topside of a 1.6mm PCB with some material, or just fab a 2mm PCB. MicroSD is 1mm which is a common PCB thickness.

It is, as long as you aren't interested in the 'Secure' part of it that nobody uses.

formatting link

Emulating an SD card is doable, but tedious. The interface is designed to be driven at both ends by software, so there's lots of state machines you have to implement.

Also if you want 50MB/s then that's 50MHz DDR - that might be in the part that needs switching signalling down to 1.8v (I can't remember the cutoff). The higher speeds are more complex to work with.

Something I've scoped out but not actually built is a double-ended SD card. One end goes in the system under test, the other end goes in a USB SD reader. On the card is a microSD socket with a real card in it and some analogue switches. Flip the switches one way and the card is 'plugged' into the test system, flip them the other way and it connects to the PC. Combine this with some GPIOs for control and some power switching and you can do automated testing - eg flash disc image to SD card with PC, 'plug' it into test system, boot SBC from SD and run tests, turn off SBC and 'plug' into PC, read off results. Rinse and repeat for every build of the software.

TI has some nice SD mux chips, for instance:

formatting link
I can't remember the one I've used most recently, but it was in that family.

Ah, looks like somebody did it already:

formatting link

I'm sure there are easier ways to do this than SD emulation - the same idea with USB for instance. But some SBCs like the Raspberry Pi (until recently at least) like booting from SD.

Theo

(I have form on evil SD interfaces - my current hackery is a DIMM to SD card interface...)

Reply to
Theo Markettos

I stumbled on that project but its almost 10 years old! Nevertheless, I reached out to Antti Luktas, hopefully he's not too busy to get back to me :)

Making the physical connection isn't too difficult:

formatting link

Even jumper cables are suitable at 350 Mhz..

The specification for the SD protocol is nearly completely available in the Simple SD Specification freely available on sdcard.org - the state machines I'd need are bootup (3.3v), negotiating to high speed (which switches to 1.8v) and data transfer.

The SD-MUX option wears out, I've run through a couple SD cards already which is why I'm looking into the FPGA approach - not to mention faster in speed.

I'm uncertain about FPGA sizing and FPGA's in general which is why I posted here - there doesn't seem to be any relatable data between different FPGA manufacturers and I'm trying to keep costs low if I need to make a lot of boards.

Reply to
sriakhil

I stumbled on that project but its almost 10 years old! Nevertheless, I reached out to Antti Luktas, hopefully he's not too busy to get back to me :)

Making the physical connection isn't too difficult:

formatting link

Even jumper cables are suitable at 350 Mhz..

The specification for the SD protocol is nearly completely available in the Simple SD Specification freely available on sdcard.org - the state machines I'd need are bootup (3.3v), negotiating to high speed (which switches to 1.8v) and data transfer.

The SD-MUX option wears out, I've run through a couple SD cards already which is why I'm looking into the FPGA approach - not to mention faster in speed.

I'm uncertain about FPGA sizing and FPGA's in general which is why I posted here - there doesn't seem to be any relatable data between different FPGA manufacturers and I'm trying to keep costs low if I need to make a lot of boards.

Reply to
Sri G

People say the specs are available, but I looked for the mechanical details and never found them.

My understanding is you can use an SD card in SPI mode (one bit data width) but the 4 bit mode is not specified. Maybe that has changed and my info is out of date.

I saw the cables when looking for a mail SD card connector. I don't know how well they work. I didn't know SD cards ran at 350 MHz, but at that speed you need to pay careful attention to the details of connections. Signal integrity (SI) can be a significant issue.

Even a small FPGA will do the job of providing the SD card interface. The USB interface requires a lot of code (relatively speaking) but is well supported by vendors and various other sources with example code for MCUs.

Lattice has a number of low end FPGAs that use internal flash to load the config RAM so an external chip is not needed. That is why Antti used an XP device. They are now obsolete, but Lattice has the XP2, XO2 and XO3 lines in addition to the iCE40 family. The iCE40 line uses one time programmable NVM to load the RAM though. If you want the chip to be reconfigurable in the field you need an external flash chip.

--

Rick C
Reply to
rickman

UHS-I goes up to 104MHz (104MB/s SDR), and then UHS-II adds a differential interface (up to 312MB/s at present).

A small FPGA will handle the physical interface, but implementing the card end of the protocol is more complex (though not as bad as USB). I'd suggest you want to use an FPGA to interface to a CPU (or a soft CPU inside a larger FPGA) and running software to implement the protocol - doing it all in hardware will be pretty painful.

Another option might be to take an existing SD card chip and use an FPGA to emulate the NAND flash it's expecting to talk to. The NAND protocol is a lot cleaner than SD. However you'd have to force the SD chip to disabling wear levelling somehow, otherwise it would shuffle your blocks around.

It sounds like a somewhat finnicky project, particularly if you're expecting to get decent speed out of it...

Theo

Reply to
Theo Markettos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.