Download If, like most SFF board suppliers, you`ve spent your

ARM Yourself
If, like most SFF board suppliers, you've spent your career building x86-based embedded PCs,
you must feel challenged by the announcements coming out of Embedded World regarding new
standards and SBC/COM (computer-on-module) products using ARM architecture processors. If
you feel you need to join the crowd to stay competitive, it's going to be a little bit like walking on
the surface of Mars. Here's a primer for some of the things you need to think about.
Let’s start with the processor itself. In x86 land, you simply go to Intel, AMD, VIA or others to
choose from dozens of processors that all work pretty much the same. Follow their reference
design and in 90-120 days or so you have an embedded PC that boots Windows. No fuss, no
muss. In ARM country, you can go to dozens of semiconductor suppliers who have licensed the
ARM core, stacked a set of peripherals around the core, and sell a fully functional chip. The
gotcha here is the set of peripherals chosen. Chip suppliers pick the peripherals to target a
specific, high volume market, such as cell phones, tablets or infotainment. Most likely, this won't
be the same set of I/O that you will need to address medical devices, UAVs or industrial
controllers. You can fish for the closest model and add other necessary I/O on the board, or, dare
we say it, go the custom route yourself.
You, too, can license the ARM core and create your own custom ARM-based chip. This has a
number of advantages: You control the life cycle; you control the I/O set; and down the road you
are simply buying an ASIC, so you'll save significantly in product cost. And in the "high"
volume, low margin COM market, saving a few bucks a board can make a difference in winning
some volume business.
Creating your own custom ARM processor requires you to have access to a good chip designer.
These guys are few and far between—the real divas of the semiconductor industry. After you
find one, you need to spend a few hundred thousand dollars on chip design tools. And tools are
really important here. After you understand the $1M+ NRE cost for masks and such, you'll want
to be absolutely positively sure that your design is perfect before you commit to production. And
yes, it's OK to start with an FPGA with an ARM core, but if you want to save all those bucks we
talked about earlier to be competitive, you'll need to go the ASIC route eventually.
Let's say you've surmounted all these obstacles and now have an ARM-based CPU ready to slap
on a board. What's it gonna run? In x86 land, you have this thing called a BIOS, an
extraordinarily elaborate set of x86 assembly language code, refined over almost 30 years, to
initialize and test virtually any x86 system. It even does clever things like scanning each bus to
determine what I/O devices might be installed (one reason boot takes so long). If you followed
your chip supplier’s reference design, your BIOS should be easy to adapt. Unfortunately, in
RISC country, there is no BIOS. Sure, you'll get some kind of "boot loader" designed to get the
chip up and running (unless you did a custom chip—then guess what—you own that
responsibility lock, stock and barrel). But the boot loader doesn't know anything about what kind
of I/O you put on the board, so you need to adapt the boot loader for every single configuration
you support. ARM assembly language, of course. Of course, your BIOS guy knows just how to
do this. Did we mention the (expensive) new software tools?
Next step: Pick an OS. Windows, Linux, Android all pretty much run on x86 systems. And if
you gave up and used an off-the-shelf ARM processor, you might very well be able to get a
customized Linux or Android. Windows 8—don't hold your breath. And if you rolled your own
chip—hahahaha.
So now you have a board and an OS that boots. Let's plug in a PC/104-Express Analog I/O card.
There's just a simple matter of an Android driver for your custom ARM processor. Doesn't
everybody have one of these? You've got to be kidding me.
OK. Enough fun for today. Now you understand why it has taken almost twenty years for a
serious ARM-based COM in the SFF board market.