Choosing a SOM – Why Standards don’t work for ARM modules

When choosing a System on Module (SoM) for a new project, you quickly find that there are some which follow a standard, and others which don’t. On the standards side, you may have heard of Q7 or SMARC. Proprietary modules use SO-DIMM connectors, board-to-board connectors or modules like our Topaz and Quartz products have no connector at all and solder directly to a board.

This post explores some of the reasons why we at Device Solutions have gone the proprietary non-standard path, and why we think standards don’t work for ARM and don’t deliver on the benefits you expect from a standard.

Why choose a standard?

For processor modules, having a second or third supply option sounds attractive. Obsolescence is a big problem and using a standard module to avoid this sounds like a compelling reason to go down that road. In fact it does work very well – for x86 based modules. However x86 chips are very well defined compared to the huge variation in features found on ARM based parts.

Why standards don’t work for ARM

ARM devices are used for a huge variety of applications, with an equally diverse set of requirements. If you have ever taken a close look at a Freescale i.MX part, you will see a lot of different functions and no single application makes use of them all.

This creates some big problems when trying to map an ARM chip to a standard interface. The challenges are:

• Wide range of features, and not enough pins to expose them all.
• Multiplexed features – which feature do you pick for a particular pin?
• Functions change between chip generations and there may be no slot on the standard interface for a new feature. A good example of this is display interfaces – these have evolved from parallel TFT and chips have this interfaces along with LVDS, VGA or HDMI and now MIPI.

Designing with a standard ARM module

All this is not to say that ARM modules based on a standard don’t work at all. They do, but they might not do everything you expect (or need) them to do.

The first thing to check is, can you access all the features on the chip that you need? Make sure anything you think you might need is available. It is painful to get half-way through a design only to find you can’t get at a vital signal!

Using a standard module for second source reasons

This is where things get tricky and your design effort may effectively double. Because of all the reasons above, you can’t rely on two different standard ARM modules to give you exactly the same signals on the interface. It is important to identify what module you are going to use as a second source at the design stage. Every signal will need to be analysed and your base-board may need to have different build options for each module to get it working. Often this proves to be impossible because some vendors don’t share module schematics.

An alternative to second sourcing

Often the reason for having a second source is continuity of supply. Rather than invest in extra engineering (which is expensive and time consuming enough!), we suggest you ask the module vendor if they have an escrow service for their design files. This way should there be a problem for whatever reason, you will still have access to the module.

Conclusions

If you have made it this far, you will see that there are some issues with the current ARM based modules that follow a standard. Our advice is to choose a module that is the best fit for your design, and to solve second sourcing issues by other means.

There are a lot more details we haven’t gone into around this issue. Contact us if you would like to know more.