Hi We are trying to interface a 16MB MMC(of Infineon) to Spartan- FPGA ... We have designed reader for card(in VHDL) abopting MMC protocol(no 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 ... :)
"fahadislam2002" schrieb im Newsbeitrag news:kdqdnV-4CqYi4AbeRVn firstname.lastname@example.org...
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!)
there is snapshot from mmc host controller ip core from LARK project - notice that ipcore is 100% non-tested
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
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...."
indicates MMC has only 7 pins, and only one of these for data.
I thought most of the 'new features' work would be done on SD cards. The Mini-format is just a repackaging.
"Martin Schoeberl" schrieb im Newsbeitrag news:439d69c8$0$11610$ email@example.com...
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
Hi Antt as later i told i stated from Reader ... and i am facin problem in crc-7 ... i know that serial crc is easy but it will tak more time so i was trying for table based crc approach ... but its little more complex .. whats your suggestion for that .. and also I got your code and trying to understand and learn fro 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 fo developing reader i got help from sandisk datasheet and also o hitachi ... and in that although I not found any kind of suc description ... but in one example in datasheet i felt that to ignor crc he was puting all crc bits one(1111111) ...is it true
We turned to serial CRC7 and implemented it using "for loop" as wan for 40 bits ... and it give result in same cycle ... although is a inefficient approach (takes more hardware i feel your approach is better than us ... we will try it .. Anyways thanks Anti ... will meet u soon with some other issue