FPGA Programming solution

FPGA configution IP core for MMC card is as small as 21 PLD MC's (more for SD card) or less than 1Kbyte of code for AVR if using micro as boot processor

Antti

Reply to
Antti
Loading thread data ...

Certainly, it's easy to read MMC/SD cards in SPI mode, but that offers only 1-bit-wide data. It's possible to start in SPI mode then switch to "native" mode (but you have to power off the card to do that). I prefer to initialise in "native" mode, read the FPGA configuration and any microcontroller update, then switch to 4-bit mode so that the FPGA can read the card at high speed.

Mike

Reply to
MikeShepherd564

21 MC is NATIVE mode MMC init. native SD mode is just a little more.

I never use SPI mode if possible

Antti

Reply to
Antti

core for MMC card is as small as 21 PLD MC's (more

All this talk of SPI vs Native mode has me curious. SPI mode is fairly well documented online, but Googling indicates that getting specs on how to use native mode requires licensing from the SD Card Assoc, which is apparently quite costly. Is this true? Are there any free resources where one could learn more about using Native mode?

EB

Reply to
emeb

IP core for MMC card is as small as 21 PLD MC's (more

Never mind. Apparently the spec is now freely available here:

formatting link

A quick skim seems to indicate that all the necessary protocol details are there.

BTW - I assume that all the previous discussions about loading FPGAs from SD/MMC assume that the data on the SD/MMC is _not_ in a standard filesystem, but was written in some raw format. It's difficult to imagine getting a FAT filesystem reader into 21 macrocells.

EB

Reply to
emeb

configution IP core for MMC card is as small as 21 PLD MC's (more

I have done the impossible, but FAT in 21 MC is beyong my limits as well.

however if 1 file is copied to mmc card (the first file after format) then FPGA will configure from that file

I have however developed a 0FAT filesystem that allows access to files in FAT file system without fat parsing, it is compatible to almost any filesystem.

a microcontroller code that support SD native and 0FAT is still below

1 k of code

a SD card hard IP-Core could also support 0FAT with very little extra resources

Antti

Reply to
Antti

Well, I'm not going to reveal all my secrets for free, but a fairly simple scheme can be figured out for the SST chips. They need an "instruction" byte serially shifted in to program the memory to read from the beginning. The Xilinx FPGAs all seem to ignore everything before a byte of "FF" which appears right after a short header in the BIT or MCS file. Wiring up a 4-bit counter and a gate chip was the minimum package count scheme I could come up with for that bare minimum. If I needed to program a few bits of the starting address, too, that would probably expand to a 3-chip solution. These SSOP-packaged parts are pretty small.

I also built my own programmer for the SST chips, as none of the device programmers would handle them. It was a one-evening job to get the programmer working. One bit from CPU to PROM, one clock bit, one data bit back from the PROM. Pretty simple, plugs into the parallel port. I wrote it in C for Linux, just my personal choice. The way I am setting it up doesn't allow for on-board programming, I DON'T want to give my customers that option. But, there's no reason that couldn't be provided easily.

Jon

Reply to
Jon Elson

The SD Card Association makes available freely some limited specifications. As I understand it, the full specifications are available if you pay to join the SDA.

For example, the public documents show how to operate the card up to

25MHz but don't show the different timing sequence used when running at 50MHz (although I have seen some documents which describe that and which, I assume, "leaked out").

Either way, don't expect well-written specifications. The publicly-available documents are abysmal. I'd be amazed if the full specifications were any better.

The MMC/SD standards seem to be the fruits of a committee on drugs. Certainly, it's difficult to see how a sane person could invent them. This is reflected in the quality of the documents. For example, the document which claims to describe the "physical layer" actually describes just about everything but the physical layer. Also, some products widely sold with the "SD" logo don't meet the specification.

Mike

Reply to
MikeShepherd564

I've often wondered why these Serial FLASH vendors have missed the REALLY OBVIOUS option, of alias of a 00 or FF opcode to read, so you could simply connect their serial memory, and just clock to stream out data. Would be 100% upward compatible with present usage.

-jg

Reply to
Jim Granville

45LF010 had a 0xFF read opcode, but its eol ...

-Lasse

Reply to
langwadt

Yup, that would have made it easier, and probably saved two chips to default to read out one FPGA config. For that case, using the SST chip, I had to generate a couple 1 bits in the first byte and then zeros from then on to get what I wanted.

Jon

Reply to
Jon Elson

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.