Break Points

Comment


David Brown

2/15/2012 9:41 AM EST

Some compilers, such as newer gcc versions, will factor out "hot" and "cold" ...

More...



David Brown

2/15/2012 9:40 AM EST

You misunderstand. First, it is quad-spi - there are four data lines in ...

More...

A SPIFI New Idea

Jack Ganssle

2/7/2012 12:12 PM EST

I’ve been experimenting with NXP’s new LPC4350 dual-core microcontroller recently. It’s quite an intriguing part, sporting a Cortex-M4 and a Cortex-M0. The former has floating point and DSP instructions, while the latter is targeted at the control and housekeeping functions that so many embedded systems need.

One interesting feature is their SPI Flash Interface (SPIFI). The company introduced this on their LPC1800 series of processors a year or two ago. SPIFI is a mechanism that interfaces the CPU to external serial flash memory. The cool thing is that the serial flash appears in the microcontroller’s address space, and can be accessed in a standard random access fashion. That’s right: random access to serial flash.

There are a number of upsides. Serial flash is cheaper than parallel. And, far fewer pins are needed. The SPI connection requires just four pins (6 for quad flash devices). A serial flash device can have just a total of 8 pins, greatly shrinking PCB real-estate needs. In contrast, parallel devices need gobs of address, data and control connections.

There’s no software layer between the flash and the CPU. A SPIFI controller on-board the microprocessor connects the flash directly to the AHB bus (for some reason a lot of literature about ARM’s Application High-speed Bus put the redundant word “bus” after AHB). Eight registers control the SPIFI interface; once set up, any instruction can access the flash as if it were regular memory. So the system can use serial flash as bulk storage, access it via DMA, and even execute code directly from it.

The LPC43xx series are very complex parts with tons of features. They do an initial boot from an on-board ROM, which can configure the SPIFI registers and then initiate the application’s boot from SPIFI flash.

Being on the AHB means that either core can access the serial flash at any time. It’s a little freaky using these parts since the M4 and M0 share address space. Either can use the same peripherals and memory. While this is a powerful idea, it’s laden with reentrancy threats. There is an interprocessor communications strategy, though, so with a little care robust code isn’t too hard to write.

The obvious down side is transfer speed. Real random-access reads and writes will be quite slow, as the address and data have to be transferred over SPI. That’s probably not important for booting.

But one could copy the flash to RAM and execute from there. Block transfers are very fast. Some applications might take advantage of the on-board LCD controller, and store blocks of images in the flash, which will transfer quickly. The SPIFI controller can mediate these transfers so no CPU intervention is needed.

Presumably SPIFI will be an NXP-only feature, as the company is applying for a patent on the technology. But it’s a pretty cool idea.

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.





Luis Sanchez

2/8/2012 9:37 AM EST

This reminds me of the memory chips that are accessed through I2C bus serial communication.
I think the new idea is that of making the Flash memory appear as if it were part of the chip’s RAM memory. I doubt SPI access to a flash memory is a new idea. And I agree with you, speed isn’t critical in boot time. Many of the powerful mobile phones out there in the market, the kind that may use an LPC processor, take a long while to finish booting. Good to know about SPIFI. I wonder which are better LPC or OMAP processors?

Sign in to Reply



cdhmanning

2/9/2012 3:16 PM EST

These are not at all like OMAP processors. The OMAPs are designed to be run with many MBytes of RAM and flash.

Which is better between a 3 ton truck and a Ferrari? Well it depends very much on what you are trying to do.


While SPI access to flash memory and SPI booting are not new, their particular way of mapping an SPI part into the memory space might be.

Clearly this mechanism would not be intended to provide the main execution space for code since the access speed is far slower than the CPU speed. It could still be useful for boot loading and such.

Sign in to Reply



Jack Peacock

2/8/2012 10:18 AM EST

The ST Micro STR750 series from a few years ago had the same feature, mapping serial flash into the ARM7 CPU memory space. The relatively low data rate on the SPI port and the limitation of 1-bit transfers limited its usefulness.

Sign in to Reply



kalpak

2/9/2012 6:25 AM EST

Now if I can add ram on this serial interface that would make PCB layout easier for low speed graphics.

Currently a 32 bit parallel DRAM is required for graphics scratchpad.

Sign in to Reply



Haldor

2/9/2012 3:46 PM EST

This is quad speed SPI which combined with the processors memory accelerator makes execution from SPIFI possible.

I agree that the most common use for this will be to hold code that gets copied to RAM for execution.

Sign in to Reply



cdhmanning

2/11/2012 1:30 AM EST

Quad speed is far too slow for most direct execution. On a 100MHz CPU executing thumb, the SPI would need to clock at about 2GHz to keep up.

This mechanism is only useful when you are prepared to take a punishing performance hit.

Sign in to Reply



David Brown

2/15/2012 9:40 AM EST

You misunderstand. First, it is quad-spi - there are four data lines in parallel. So when it is running at 100 MHz, you get approximately 40 MB/s throughput. For comparison, a typical 60ns 16-bit NOR flash gives you about 30 MB/s.

Secondly, the key use is for things like bootloaders, and then loading the program into ram.

On other processors with instruction caches combined with pre-fetching, SPIFI is much more appropriate.

Sign in to Reply



Code Monkey

2/10/2012 7:37 PM EST

This hilights the difficulty of factoring code into slow and fast ROM regions using C. Doing so is a linker trick that's not well supported if at all. Otherwise, the consensus would be that XIP doesn't slow down the code much because the CPU spends most of its time on-chip.

Sign in to Reply



cdhmanning

2/11/2012 1:25 AM EST

Doing so is actually pretty easy if you do it on a file-per-file basis.

For an example of how I did this using gcc for ARM look at http://lejos.svn.sourceforge.net/viewvc/lejos/trunk/nxtvm/platform/nxt/

The basic idea is to make different types of .o file: .oram for stuff in RAM, .orom for stuff in flash.

You can use the same idea for thumb vs ARM code: .016 and .o32

The ldscript then figures out the placement based on file name.

The way I did this is pretty rudimentary. It is also possible to do the same thing with #pragmas.

GreenHills tools provide mechanisms to help you to selectively compile stuff and figure out placements.

Sign in to Reply



David Brown

2/15/2012 9:41 AM EST

Some compilers, such as newer gcc versions, will factor out "hot" and "cold" functions automatically and work with the linker to place them separately.

Sign in to Reply



DutchUncle

2/13/2012 9:05 AM EST

Let's all reinvent paging! Or bank switching, or whichever similar technique you used back in the Z80 days. The problem is that the techniques have fallen out of use as address spaces widened, and the support in old linkers for things like bank-switching subroutine calls has to be done by hand now.

There is always a bottleneck. Some part of the system is always the slowest, and the one you have to work around. As CPU performance and memory capacity and comm speed improve, the *ratios* are what matter; and they sometimes come back to revive the same problem faced long ago (with different absolute values, of course).

The lesson that I've taken over the years is, Don't forget old techniques - they'll come back around.

Sign in to Reply



MWright

2/13/2012 2:06 PM EST

This is less useful for just moving boot code to SRAM. Can already do that with a peripheral SPI port. The benefit is for running code. Even if it is just boot code, or patching ROM code, it alleviates having a large chunk of SRAM on chip to hold this running code when speed is not an issue. SRAM is large on chip. With Qual SPI speed, one would hope for increased processing use also (faster access).

Sign in to Reply



Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Featured Job On
Scroll for More Jobs