I certainly agree with the sentiment that ARM is an attractive candidate for applications that that are too demanding for an 8051 derivative.

I also appreciate the fact that 8051 and ARM architectures are multisource. Even the MCS-251 architecture is multisource, with Atmel offering a few, although arguably not very compelling devices like the TSC80251G2D.

Now, at the most basic level and in the simplest situations, multisource is a great concept. I can pull out an Intel 87C51 from a working design, pop in an Atmel 89C51, and in most cases, with little more effort than performing the physical replacement, switch to a device which is just about functionally equivalent and significantly cheaper. This not only can generate a nice cost savings, but also provides protection for if/when Intel decides to pull the plug on the 87C51 (this is just a hypothetical scenario; I claim nothing about Intel's agenda).

The reality of the matter, however, is that a number of 8051-based applications being developed today are using exotic, high performance derivatives like the Silicon Labs C8051F120 or the Dallas Semiconductor DS80C400. Making a claim that the 8051 architecutre being multisource makes your product independent of Silicon Labs' or Dallas' agenda is exaggerated at best. So, what happens with your 'F120-based product if/when SiLabs decides to pull the plug? Maybe you can manage to buy the part at Rochester or another specialty distributor, although probably at an increased cost. If you cannot, or if you are not willing to pay the price, the fact that the 8051 is "multisource" isn't going to help much. The 'F120, as well as many other very high performance derivatives, shares little in common with the original 8051 outside of its instruction set architecture, not unlike how a Pentium 4 shares much of its instruction set architecture with a 386. As a result of replacing the 'F120 with a competing device, you will probably end up doing a significant PCB redesign, both because nothing else on the market has the same pinout and the exact set of functionality that you require on a single chip. And your firmware will need some major attention too; at a bare minimum, it will need new drivers for the new set of peripherals you have. If you have a custom in-system programming utility, that too will probably need to be rewritten when you switch to a device from another vendor. The whole job probably won't be quite as bad as porting the firmware to an entirely new architecture, but that said, it might not be easy.

The bottom line here is that "multisource" is something of an overhyped buzzword. Unless there is a part that is by all practical measures equivalent to or a clean superset of the part you are already using, multisource won't help you much when your primary source dries up. Incidentally, that can further make the case for a higher performance architecture in initial system design. If the level of performance required needs an exotic device within a particular architecture, selecting a relatively standard device in a higher performance architecture, like ARM, might make more sense.

--Sasha Jevtic