Seite 8 - Boards & Solution/ECE Magazine July 2013

July 2013

8

C

OVER

S

TORY

Import drivers and it runs—mostly anyway.

Here too, you have to pay attention to the

subtle difference. So for example, 24 Express

lanes are specified with COM Express spec

2.0 for the version 2 implementation. A mod-

ule populated with an Intel® Atom™

N2600/N2800/D2550 processor and NM10

chipset delivers twice PCIe x1. A different

module populated with an embedded Intel®

Core™ i7/i5/i3 processor and QM67 chipset

offers five times PCIe x1. This shows the lim-

itations of standards already introduced in

this area a long time ago.

Amazingly, the two leading groups in the

x86 module market view the conversion to

ARM technology in completely different

ways. The Qseven group argues for a seam-

less transition from vx86 to ARM, thus logi-

cally the same standard for x86 as for ARM

modules. On the other hand, the SMARC

faction sees the need for independent x86

and ARM standards because an ARM proces-

sor’s special functions can’t reasonably be

mapped to an x86 standard. Actually you’d

have to assume that a universal standard

would suggest itself, meaning that a unified

solution would be defined. The user con-

verting from x86 to ARM quickly realizes

that there’s a further serious difference and

difficulty. When installing an x86 system,

you just select the corresponding driver from

the chip manufacturer’s existing libraries and

the application runs right away.

Thus the conversion from one system, meaning

the scalability or the use of a second source, is

more of a logistical task than a technological

challenge. The world looks completely different

with ARMmodules. There’s an individual driver

for each processor and for each function. As a

rule, the former doesn’t exist as a freely available

library, certainly not from the chip manufacturer.

That clearly shows the increased demand on

the module manufacturer to make suitable driv-

ers available. There aren’t any standards at all in

this area. In other words, interchangeability

among various manufacturers and different

modules from a single manufacturer isn’t

possible right off the bat.

But a look at the hardware is

also extremely decisive. Anyway,

a detailed comparison helps to

arrive at a safe decision. The

question is which functions in

a module are implemented by

different providers and also

with various processors. In

other words, where the actual

exchange possibilities are, and

which processor functions

aren’t available because the cor-

responding signal pins aren’t

defined in the standard and

thus aren’t available on the sys-

tem connector. How much de-

sign freedom does the user

have with the module?

The more overlap among the functions that

each module provider and each processor

delivers, the greater the actual interchange-

ability. But what about processor functions

not reflected in the standard? If these are

needed in future projects, does it mean that

the user will have to change module

providers? In any case, it pays to create a de-

tailed list of functions to get clear about

which systems fit your particular application,

what interchangeability opportunities exist,

and what future needs are also mapped with

the module The table shown might be a pos-

sible work aid.

It quickly becomes clear that having a perfect

standard is still a dream at the moment when

you consider the standards for ARM modules

currently being propagated in the market. The

restrictions and compromises with respect to

complete interchangeability and restricted access

to all processor functions actually make the

products proprietary systems lacking scalability

and second-source capability. This is true unless

the requirements limit themselves to the

functions’ lowest common denominator.

On the other hand, TQ modules are generally

optimized for the processor being used. As a

rule, this enables a considerably more com-

pact form factor. All of the processor’s func-

tions are available on the robust, industry-

capable system connector. Nor does it make

any difference to the use whether he inte-

grates the processor into his application

board or uses a TQ module, naturally apart

from a module’s general usefulness. Such a

module offers the user the greatest possible

design freedom under the aspect of the

longest possible usage period for a processor

platform.

Which system is reasonable for the user is

always a very individual decision. Proprietary

systems have the advantage if size plays a

critical role and if the specific processor’s

functions are important. The connector sys-

tem used plays an important role if shock

and vibration requirements are decisive. If a

Q7- or COM-Express module was previously

in use, and if the new system should use just

a little power, then a Q7 or SMARC is the

right decision.

In any case the user has to be clear that a

direct interchange between existing x86 and

ARM solutions isn’t possible without adjust-

ments. And as a rule, the application board

will have to be optimized and overhauled

along with it at the same time. Thus having

mechanical interchangeability isn’t so decisive.

It seems more important to have design

freedom to optimize and adjust optimally to

one’s application.

n

System integration with TQ module

System integration diagram