Writing IP-Cores while sleeping ;)

Hi

Creative lazyness and sometimes simple waiting (or sleeping) is possible the most effective way to work! Ok, only sometimes:

I did write FPGA bootloader for MMC Card (in MMC not SPI mode), I was about to write the SD Card version also, but that wasnt challenging at that time and I had no real urgent need. Some time ago I uploaded my IP Core to opencores, and now, guess what I dont have to work on the SD Card FPGA configuration core as it done already, possible at the time while I was a sleep. 39 hours ago a spiboot project was added to opencores, supporting FPGA config from both MMC or SD cards in SPI mode.

My MMC card was 21 PLD macrocells, my estimate for MMC-SD card core was

50..55 PLD cells (in non SPI mode) and I was sure the MMC-SD card combined core in SPI mode would fit 36 Macrocells, - the spiboot from opencores (MMC+SD in SPI) - my synthesis gives 24 PLD cells so it defenetly fits XC9536 :) - please note that I have not verified the opencores spiboot with any hardware, it may not be working out of box, as it is the first release. (I know my core does work, it sits on SystemACE slot on VP20 and does work)

Antti has a smile on the face today

Reply to
Antti Lukats
Loading thread data ...

hum, do you meen that you can use an MMC card connected to a CPLD to configure a FPGA? Is the MMC card formatted to any file system? What is the procedure? You copy the config file with a normal card read connected to your computer then connect this card to your app and that's it?

"Antti Lukats" schrieb im Newsbeitrag news:cufkhe$mt7$03$ snipped-for-privacy@news.t-online.com...

Reply to
Mouarf

"Mouarf" schrieb im Newsbeitrag news:420b57fd$0$8202$ snipped-for-privacy@news.free.fr...

it?

yes!

basically there are 2 options

1) you reformat the mmc-sd card with reserved sectors and copy the bitstream there 2) you can also just copy normal xilinx bitstream as generated by xilinx tools as first file to formatted mmc card this will also work, you overwrite the file later its ok too, as long as the bitstream file is located in sequential sectors.

the above applies for xilinx, for altera it maybe require todo bitswap additionally

a similar IP core is offered commercially by El Camino, they provide a windows utility also. (their price is 1900 EUR for source code license)

Antti

Reply to
Antti Lukats

"Antti Lukats" schrieb im Newsbeitrag news:cufldf$rj5$01$ snipped-for-privacy@news.t-online.com...

Reply to
Mouarf

"Antti Lukats" schrieb im Newsbeitrag news:cufldf$rj5$01$ snipped-for-privacy@news.t-online.com...

I did not checked into the code but how do you recognize the correct bitstream file in the card with the second method? To you look for the first time you meet a special set of bytes?

Reply to
Mouarf

"Mouarf" schrieb im Newsbeitrag news:420b5ae8$0$8186$ snipped-for-privacy@news.free.fr...

first

For xilinx FPGAs it isnt necessary :) just dump all the mmc card from sector

0! FPGA will sync itself when the bitstream begins :)

That is tested with my bootx core, my IP core also includes minimal emulation ip core that emulates the FPGA configuration internals (not complete) so I tested with MMC card connected to FPGA and did configure my "config emulator" later test where done with real XC9536 connected to VP20

Antti

Reply to
Antti Lukats

"Antti Lukats" schrieb im Newsbeitrag news:cufm2s$sn6$01$ snipped-for-privacy@news.t-online.com...

with a card reader, are you sure that the first file will be at sector 0 in a just formatted MMC?

Reply to
Mouarf

"Mouarf" schrieb im Newsbeitrag news:420b5d65$0$8212$ snipped-for-privacy@news.free.fr...

in

No, it want be, but that doesnt matter :) the all content before the actual bitstream is dumped to FPGA as well it is discarded by FPGA config logic, as it is looking for sync word

Antti

Reply to
Antti Lukats

"Antti Lukats" schrieb im Newsbeitrag news:cufmna$rnu$03$ snipped-for-privacy@news.t-online.com...

ok, I understand now, nice behaviour from the FPGA!

Reply to
Mouarf

Sounds good. But these SD cards aren't they built with NAND Flash? And NAND Flash can have bad sectors. If one of these bad sectors is one of the first you can't use it.

There was a similar idea some time ago to configure the FPGA from a NAND flash. With pointers from one sector to the next good sector. However, this design will take some more resources in an CPLD - not worth the effort.

Martin

---------------------------------------------- JOP - a Java Processor core for FPGAs:

formatting link

Reply to
Martin Schoeberl

And it's a great weight loss program. You can burn 50-90 calories per hour sleeping. I think I'll start sleeping more!

Reply to
Eric Smith

No, because the SD card incorporates an intelligent controller that hides the bad blocks, just like a SCSI disk does.

Reply to
Eric Smith

Great, looks a very useful thing!

Wouldn't this be better done by a small micro (e.g. AVR) though?

These could be smaller than the 9536 chips.

I'm also looking for a system where the main micro can use the SD card after booting.

That is, the FPGA boot device tri-states the control signals so the main CPU can drive them.

This would get more usefulness out of the SD card.

However, if the card gets the FPGA bit file re-written on a PC then returned, the CPLD hardware method might have to send megabytes of data before the FPGA sees the sync word. A micro-based method might be able to search a FAT to find a particular-named file, though obviously this is a non-trivial job unless you have some experience with FAT already. Anyone got any PD FAT source code in C?

Reply to
Kryten

I'm sure there are others, but OpenDOS, OpenBSD, NetBSD, FreeBSD, Linux, and such do have farious versions of FAT code. Also, I seem to remember a number of MP3 type projects out there with FAT code.

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Reply to
Tobias Weingartner

Kryten wrote:

It could be, but it would be slower and more expensive.

The 9536XL is amazingly cheap.

Shouldn't be any problem with that. Just tie the SD to both the CPLD (or uP) and the FPGA, and have the CPLD (or uP) put its SD interface pins into high-Z once the config is done.

True. A point in favor of the microcontroller.

Though if you don't mind writing special code for the PC, you can have it always arrange for the FPGA bit file to be a single contiguous chunk near the start of the SD.

In fact, once you've got it there the first time, you should be able to rewrite the bit file without it moving around.

Yes, RDCF2 by Philip J. Erdelsky:

formatting link

I wish I'd known about RDCF2 when I wrote the boot ROM for the ReplayTV. I wrote my own read-only FAT filesystem for it. (Used for software development only; the ReplayTV does not use FAT.)

Eric

Reply to
Eric Smith

None of which are public domain. The BSD licensed code is closest. But code for either a BSD or Linux kernel will be hard to adapt to a tiny microcontroller.

Reply to
Eric Smith

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.