April 2015
33
E
MBEDDED
C
OMPUTING
case of the x86 module market whether the
compatibility and scalability expectations are
actually met, the market of the other architec-
tures is far more complicated. You will quickly
know that this is a completely di erent world
even if many marketing statements try to get
you to think di erently.
Outside the x86-world, modules based
on ARM architecture are dominant. If you
take a look at the suppliers of ARM-based
processors, i.e. mainly Freescale, TI, Sam-
sung, In neon, NVIDIA and many others, it
becomes clear that the chip manufacturers
have de ned their speci cations according
to their target markets. e functions o ered
by the individual processors are thus partly
very di erent. Unlike the case of the x86-ar-
chitecture, this makes it nearly impossible
to de ne a standard.
e Qseven Group and
the SMARC Group have both introduced
one standard each. At the time of the launch
itself, it was revealed that a common way or
a description is almost impossible. Qseven
assumes a connection between x86 and ARM,
which is absolutely legitimate. Today, both
architectures address partly the same appli-
cations. If the application demands only the
basic interfaces such as Ethernet, USB and
graphics, then an interchange of the architec-
tures is absolutely possible except for the nec-
essary so ware adjustment.
At the time of launch of SMARC, the highly
di erent target markets of x86 and ARM
were pointed out. If good graphics and fast
data transfer, i.e. many PCIe interfaces, are
required, the x86-architecture with the
COM Express standard is the rst choice. If
more industry interfaces, such as mainly
CAN, serial, I²C, SPI or camera interface, are
required, then SMARC suits better. Even if the
SMARC standard leans considerably more on
the o ered functions of ARM processors, it
does not solve the general problem of getting
the mapping of the di erent functions of var-
ious processor suppliers under one umbrella.
Here too, it is worth taking a closer look.
For example a manufacturer o ers SMARC
modules with a Freescale, NVIDIA and a
TI processor.
e 2 CAN interfaces given in
the speci cations are available in case of the
Freescale and TI solution, but not in case of
the NVIDIA solution.
e speci ed 3 PCIe
x1 interfaces are realized in case of the Frees-
cale solution using a bridge chip; the NVIDIA
solution o ers 2x PCIe x1 and the TI solu-
tion o ers no PCIe x1 interface. e question
about the interchangeability of the modules
of a manufacturer, which all follow the same
SMARC standard, is allowed here as well.
And how do the new interfaces such as mainly
USB 3.0 reappear in the latest standards? Are
there new standards or new de nitions and
are these again compatible with the previous
standards? In case of ARM modules, a switch-
over from one architecture or one supplier to
the next has an additional hurdle – the so -
ware drivers. What is still quite easy in case
of x86 systems, does not work in this seg-
ment. Every module supplier, even if it o ers
the same processor based on the same stan-
dard, has its own BSP. us, this part must be
adapted or developed anew in any case.
Standards in the ARMmodule market are thus
always compromises as regards the available
interfaces at the module plug. Depending on
the standard and the processor used, the user
does not have access to a number of functions
of the processor. But they have to pay for the
complete functional scope. And should the
processor o er the required functions in future
applications, the question remains whether
these are also supported by the module.
Moreover, the application boards are mostly
optimized for a certain application and power.
e real world shows that if more power is
required, even the application board is opti-
mized for this additional power. It should
simply be understood that a Porsche engine
cannot function optimally in a Polo chas-
sis, and obviously vice versa.
is actually
