Microblaze using SPI flash as instruction memory

Even if you manage to hide that (behind a gazillion wait states) it's going to be painfully slow.

You need to either implement pre-fetch and caching in BRAM, or more likely segment your code into various modules with a routine that loads and unloads them from BRAM as neeeded.

If your 100MHz MicroBlaze fetches it's instruction directly from the Flash, this will require 64 clock cycles at 20MHz for each 32b instruction. This reduces the MicroBlaze instruction rate to about 330kHz.

If the instruction cache is enabled then the speed should improve by 10-100 times, depending on code.

Memory management is needed as the code exceeds the available memory. For a small application this is most simply done in software. For example, if your user interface is much larger than the application core, split it into a number of modules. Compile the user core and first level menu of the user interface into the base code memory area. Determine the free system code space. Compile the user interface modules to each fit into this space. On selecting an item on the configuration menu, copy the required overlay into the shared code memory area.

I'm developing a processor which reads code 'phrases' from serial flash to improve performance further, without using a general cache. This is to target very small, or 'zero power' requirements.

hth Jan Coombs.

Hi Karel,

I cannot comment on Microblaze, but we do this with our ERIC5-processor (also in S3E 250/500 design). For better performance, we use 1 BRAM as cache, and the SPI-flash-interface is optimized for sequential accesses. BTW: The ERIC5 needs much less resources than Microblaze, so maybe you could get away with a S3E 250 (if every dollar counts ;-).

Regards,

Thomas

"Dolphin" schrieb im Newsbeitrag news: snipped-for-privacy@giganews.com...

What MHz can you stream from the SPI at, in sequential mode. I see there are now ~70MHz SPI device.

I wonder when we'll see DDR SPI devices ? They could do that with another read opcode..

-jg

Oops, I hit the wrong button somewhere, here for the newsgroup:

The 70Mhz one I spotted was here, at 8MBits. I think ST mentioned 66MHz

Of course, but that could change the core design a little, or even the SW Tools (or mindset) for creating the Code. After all, with Serial Flash, the Code becomes dirt cheap, so you trade off compactness, for blocks that fit the cache.

At 70MHz, you get close to 9MBytes/s of (linear) BUS bandwidth, which is pretty good. Quite a few 8 bit uC are around there...

On present trends, that speed could increase a little more - it is not quite at FLASH access ceiling yet. The smart thing to do, would be to (optionally) flip the HOLD pin, so it can pause the FPGA streaming, on page boundaries - that would get much more MHz out of the system

regards Jim G.

Some more devices have since appeared :

Winbond now have a 150Mhz SPI memory (W25X family), that uses dual pins (MOSI becomes an output, CLK @ 75MHz )

Atmel have a new AT25FS040, that hits 50MHz, and does not need a padder byte on read - so turnaround is a bit faster.

One could use 2-3-4 of these small devices, to increase the memory bandwidth.

-jg