MMC(MultiMedia Card) interfacing with FPGA

Hi 
    We are trying to interface a 16MB MMC(of Infineon) to Spartan-2
FPGA ... 
We have designed reader for card(in VHDL) abopting MMC protocol(not
SPI) and this card is supports 2.7 to 3.0 standard ...
    Before designing its writer i want to test reader ...
and before that i want your suggestions ... :)  

So please share your experience and guide me ...

                       Thanks

"fahadislam2002" <fahadislam2002@hotmail-dot-com.no-spam.invalid> schrieb im 
Newsbeitrag news:kdqdnV-4CqYi4AbeRVn_vA@giganews.com...
> Hi
>    We are trying to interface a 16MB MMC(of Infineon) to Spartan-2
> FPGA ...
> We have designed reader for card(in VHDL) abopting MMC protocol(not
> SPI) and this card is supports 2.7 to 3.0 standard ...
>    Before designing its writer i want to test reader ...
> and before that i want your suggestions ... :)
>
> So please share your experience and guide me ...
>
>                       Thanks
>

so whats your problem ??
why are "trying" and not "DOING" ??

I have published an project at opencores that can configure an FPGA from MMC 
in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!)

at
http://gforge.openchip.org

there is snapshot from mmc host controller ip core from LARK project - 
notice that ipcore is 100% non-tested

and www.xilant.com
has MMC/SD cardside ipcore that could be used for testing (not announced 
yet)

for initial testing you can just make an Microblaze SoC in the S-2 and use 
bitbang to read the MMC so it would be easy to debug and see the response, I 
think I published once that software but dont recall where and if it is 
still on the web, in any case it isnt complex

so go ahead and test you mmc interface, until you do that, you would not 
know if it works or not

Antti

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dngni1$olv$1@online.de...
> I have published an project at opencores that can configure an FPGA from 
> MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!)

Ah, the Verilog one. Very useful project.
I hope to get it booting my own project.

> http://gforge.openchip.org
> there is snapshot from MMC host controller IP core from LARK project - 
> notice that ipcore is 100% non-tested

Very nice, I've just downloaded that!

I've got ideas for using that too.
Looks like it is for a 32-bit wide data bus, I'd like to mod it for humble 
8-bitters.

#> and www.xilant.com
> has MMC/SD cardside ipcore that could be used for testing (not announced 
> yet)

I look forward to it.

I hear SD is a superset of MMC.

SD details are harder to come by without NDA or licences, but presumably if 
you don't use the 'secure' features then it will just look like an MMC card 
with 4-bit wide data bus?

Cheers, K.

"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag 
news:WuXmf.5709$XZ6.534@newsfe1-gui.ntli.net...
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dngni1$olv$1@online.de...
>> I have published an project at opencores that can configure an FPGA from 
>> MMC in MMC mode this IPcore is hardware tested (uses 21 PLD macrocells!)
>
> Ah, the Verilog one. Very useful project.
> I hope to get it booting my own project.
>
this is one really works !

>> http://gforge.openchip.org
>> there is snapshot from MMC host controller IP core from LARK project - 
>> notice that ipcore is 100% non-tested
>
> Very nice, I've just downloaded that!
>
I think there is small bug in CRC7 and maybe something else
as said its presented in the way I got it, and its completly untested

> I've got ideas for using that too.
> Looks like it is for a 32-bit wide data bus, I'd like to mod it for humble 
> 8-bitters.
>
go ahead :)

> #> and www.xilant.com
>> has MMC/SD cardside ipcore that could be used for testing (not announced 
>> yet)
>
> I look forward to it.
>
:) me too

> I hear SD is a superset of MMC.
>
somewhat

> SD details are harder to come by without NDA or licences, but presumably 
> if you don't use the 'secure' features then it will just look like an MMC 
> card with 4-bit wide data bus?
>
> Cheers, K.
>
no exactly

SD and MMC have the same mmc like communication protocol what by default is 
1 bit

SD has somewhat different command set meaning that some commands that are 
present
in MMC are not there in SD like streaming read is only in MMC not in SD
also the initialization is different

both MMC and SD can turn on 4 bit mode
additionally MMC (standard 4.1) can also support 8 bit mode and turbo clock 
up to 52MHz !

Antti

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dnhgmj$q4f$01$1@news.t-online.com...

>>> http://gforge.openchip.org
> I think there is small bug in CRC7 and maybe something else
> as said its presented in the way I got it, and its completely untested
>

>> I hear SD is a superset of MMC.
>>
> SD has somewhat different command set meaning that some commands that are 
> present
> in MMC are not there in SD like streaming read is only in MMC not in SD
> also the initialization is different

Sigh. SD cards seem to be the best thing to buy for most consumer 
electronics, they seem to be replacing MMC cards. Better data bus width etc.

Any recommendations for documentation describing MMC, SD, and their 
differences. I have Googled, and got swamped with loads of links to places 
selling such cards. The few techy links were fairly useless, along the lines 
of "you can buy the full spec from...."


> both MMC and SD can turn on 4 bit mode

http://www.howell1964.freeserve.co.uk/parts/sd_mm.htm
indicates MMC has only 7 pins, and only one of these for data.

> additionally MMC (standard 4.1) can also support 8 bit mode and turbo 
> clock up to 52MHz !

Wow.

I thought most of the 'new features' work would be done on SD cards.
The Mini-format is just a repackaging.

> Any recommendations for documentation describing MMC, SD, and their differences. I have Googled, and got swamped with loads of 
> links to places selling such cards. The few techy links were fairly useless, along the lines of "you can buy the full spec 
> from...."
>
http://www.sdcard.org/sd_memorycard/index.html
http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf

BTW: will your MMC or SD card interface be open-source?
I am interested in the SD card interface, ?but don't find
the time to implement it.

Martin 

"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
news:439d69c8$0$11610$3b214f66@tunews.univie.ac.at...
>> Any recommendations for documentation describing MMC, SD, and their 
>> differences. I have Googled, and got swamped with loads of links to 
>> places selling such cards. The few techy links were fairly useless, along 
>> the lines of "you can buy the full spec from...."
>>
> http://www.sdcard.org/sd_memorycard/index.html
> http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf
>
> BTW: will your MMC or SD card interface be open-source?
> I am interested in the SD card interface, ?but don't find
> the time to implement it.
>
> Martin
>
Hi Martin,

your question was to whom?

if you want a SD card interface for your JOP, then firstly it can be done 
100% in software (I guess you are talking about the host side).

the SW version can be painfully slow depending on the CPU and compiler being 
used and coding style

for better speed one combo option could be that CMD line eg all 
command-response is handled in sw bitbang and only the DAT (eg block 
read/write) is implemented in hardware this would give very small FPGA core 
and only have a minor penalty on the speed. for this purpose the LARK mmc 
vhdl code archive actually contains allmost ready to use block (but I think 
the crc16 is also wrong there), in any case its not a major issue to design 
module that can rec-transmit the mmc style commands from-to block ram

Antti 

"Kryten" <kryten_droid_obfusticator@ntlworld.com> schrieb im Newsbeitrag 
news:OWXmf.4434$zt1.198@newsfe5-gui.ntli.net...
> "Antti Lukats" <antti@openchip.org> wrote in message 
> news:dnhgmj$q4f$01$1@news.t-online.com...
>
>>>> http://gforge.openchip.org
>> I think there is small bug in CRC7 and maybe something else
>> as said its presented in the way I got it, and its completely untested
>>
>
>>> I hear SD is a superset of MMC.
>>>
>> SD has somewhat different command set meaning that some commands that are 
>> present
>> in MMC are not there in SD like streaming read is only in MMC not in SD
>> also the initialization is different
>
> Sigh. SD cards seem to be the best thing to buy for most consumer 
> electronics, they seem to be replacing MMC cards. Better data bus width 
> etc.
>
> Any recommendations for documentation describing MMC, SD, and their 
> differences. I have Googled, and got swamped with loads of links to places 
> selling such cards. The few techy links were fairly useless, along the 
> lines of "you can buy the full spec from...."
>
there are enough specs to be find with DEEPgoogling

>
>> both MMC and SD can turn on 4 bit mode
>
> http://www.howell1964.freeserve.co.uk/parts/sd_mm.htm
> indicates MMC has only 7 pins, and only one of these for data.
>
>> additionally MMC (standard 4.1) can also support 8 bit mode and turbo 
>> clock up to 52MHz !
>
> Wow.
>
> I thought most of the 'new features' work would be done on SD cards.
> The Mini-format is just a repackaging.
>
both mmc and sd have new things

MMC has rs-mmc format, also microMMC
and the 8 bit mode and turbo speed

SD has miniSD and microSD (aga Transflash)

OMHO the only card to be used is microSD :)

Antti

>>> Any recommendations for documentation describing MMC, SD, and their differences. I have Googled, and got swamped with loads of 
>>> links to places selling such cards. The few techy links were fairly useless, along the lines of "you can buy the full spec 
>>> from...."
>>>
>> http://www.sdcard.org/sd_memorycard/index.html
>> http://www.sandisk.com/pdf/oem/AppNoteMMC_SDv1.0.pdf
>>
>> BTW: will your MMC or SD card interface be open-source?
>> I am interested in the SD card interface, ?but don't find
>> the time to implement it.
>>
>> Martin
>>
> Hi Martin,

Hi Antti,

>
> your question was to whom?

Who ever wants to provide it ;-)

>
> if you want a SD card interface for your JOP, then firstly it can be done 100% in software (I guess you are talking about the host 
> side).

That's the way I (or everybody else) would implement it first.
And than when it works one usually 'forgets' to ove it to HW.

>
> the SW version can be painfully slow depending on the CPU and compiler being used and coding style
>
> for better speed one combo option could be that CMD line eg all command-response is handled in sw bitbang and only the DAT (eg 
> block read/write) is implemented in hardware this would give very small FPGA core and only have a minor penalty on the speed. for 
> this purpose the LARK mmc vhdl code archive actually contains allmost ready to use block (but I think the crc16 is also wrong 
> there), in any case its not a major issue to design module that can rec-transmit the mmc style commands from-to block ram

Yes, a practical idea.

Martin

Hi Antti
           as later i told i stated from Reader ... and i am facing
problem in crc-7 ... i know that serial crc is easy but it will take
more time so i was trying for table based crc approach ... but its a
little more complex ...
whats your suggestion for that ...
    and also I got your code and trying to understand and learn from
it(as your coding style is much better and professional than me) ...
but i have some questions about ur code ...
   1) stream read ?
   2) crc7 is right ?
   3) standard 3.1 (7 pin) ?
and one more question ...
       Is there any way to avoid crc in command    as    for
developing reader i got help from sandisk datasheet and also of
hitachi ... and in that although I not found any kind of such
description ... but in one example in datasheet i felt that to ignore
crc he was puting all crc bits one(1111111) ...is it true ?