I’ve been interviewing Daniel Lang, Toradex Chief Marketing Officer (CMO), over email just before Embedded World 2019, to learn a bit more about the system-on-module market, and what’s ahead.
CNXSoft: We’ve already covered several Toradex systems-on-module and development kits on CNX Software, but for readers who may not know Toradex yet, could you provide a short description of what the company does in the embedded systems space?
Daniel Lang: Thanks for having me.
Toradex builds high reliable Arm-based System on Modules. Our focus is to make the life of developers easier and to reduce the complexity and time-to-market. We sell hardware, but most of our engineering resources focus on Software and Support. Our products are used in areas such as Industrial Automation, Medical, Transportation, Test and Measurement, Building Automation and many more.
CNXSoft: Could you explain why / what type of customers go the SoM route instead of designing for a complete custom single board computer?
DL: Toradex SoMs are ideal for customers who like to have more predictable and low-risk product development. Customers who are choosing SoMs prefer to use their own engineering resources on features which sets them apart. A reason people choose SoMs is that Toradex does a lot of testing and they know many other customers test the same SoM configuration and Software. Also, they like the fact that they can focus on their applications and don’t need to worry about BSP development. Typical customers have projects with volumes from a few hundred to a few ten thousand per year. In general, they look at the total cost of ownership including HW and SW development, product maintenance and the time to market. Many customers like the flexibly of pin-compatible SoMs. Also, a common requirement is long term product maintenance and availability.
CNXSoft: Standards are useful to both vendors and customers, as they help to bring costs down, and reduce risks of having to rely on a single vendor. There are many SoM standards including Qseven, SMARC, and Toradex’ own Apalis standard. Do you see the fragmentation continues due to different customer’s requirements, or do you expect that over time a standard will prevail?
DL: I do think both options have their space. Toradex has its Apalis and Colibri form factors, and we make sure our customers can use all modules of the same form factor in the same carrier board. As you mention, there are several cross-vendor standard form factors, especially for larger modules. In reality, it is important to understand what features the form factors require and what is optional, plus how well the different modules and vendors adhere to the standard. Also, a very large impact is the available software. Fully proprietary SoMs do have advantages such as they allow to take optimum advantage of all the features of a single SoCs. There is a trend to more standardization. However, I don’t think one single standard will prevail. Also, one reason Arm is so successful is that there are many different solutions available. We see the concept of SoM is pushing into new markets, some may require new form factors.
CNXSoft: Toradex now offers Arm SoMs, but in the last year or so, RISC-V has gotten a lot of buzz as it’s open source and royalty-free. Have you had any requests for the new ISA, or do you have any specific plans to bring RISC-V modules to the market?
DL: We are very interested in RISC-V and keep a close eye. We do get requests, but so far, it’s more that people like to hear Toradex’s opinion than that they have concrete commercial plans. Toradex is focusing on the performance range of Cortex-A CPUs, is interesting to see the development in the higher performance range of the RISC-V or as Cores in FPGAs. At the moment, there are no RISC-V SoMs on our roadmap, but this may change in the future.
CNXSoft: One issue that keeps coming back in comments in CNX Software is cooling, as Arm processors have become quite powerful now, and throttling happens often on platforms with inadequate cooling. Does Toradex offer specific cooling for their modules, or do your customers have to handle it as part of their overall design?
DL: Our Apalis System on modules are designed to handle Thermal Design Power of up to about 15W. A special pad on the bottom of the module doubles as a thermal relief and load absorbing mechanism, which supports the mounting of a heatsink or heat spreader. We offer an off-the-shelf heatsink. It’s also very common that customers integrate the complete thermal solution into their design. In this case, Toradex provides support with 3D drawing, Thermal test reports, Reviews, … In our Partner network, we have companies specialized in thermals solutions. As Toradex invests in Software optimization, our modules come with solutions to make sure no unnecessary components generate heat, and the possibility to configure the thermal management to the customer needs.
CNXSoft: The maker community is quite active now, and some hobbyists projects end up becoming commercial projects via crowdfunding campaign or otherwise. However, beside the Raspberry Pi Compute Module and systems-on-module from a handful of SBC companies like Olimex or Pine64, SoMs are not usually easily procurable by hobbyists. Does Toradex entirely focus on companies with a proven track record, or do you – or plan to – also sell your modules to the maker community?
DL: Makers are not the main target. However, Toradex is a popular choice for makers which have the final goal to build a commercial, industrial grade device. We make it easy for makers to get started; there is a webshop with no minimum order quantity, extensive up-to-date documentation, simple interactive step-by-step starting guides, and an active community moderated by our engineers. Our software offering such as Torizon or development tools such as the Flash Analytic tool make it easy, even when you are not an experienced embedded Linux specialist.
CNXSoft: Since Embedded World 2019 has just started, would you have any product announcements that you’d like to share with us?
DL: This year we are focusing our brand-new SW offering called Torizon, an easy-to-use industrial Linux Platform. Many of our customers are coming from the Windows / WinCE environment or have only experience with application development and are not embedded Linux specialists. This new offering simplifies the configuration of a Linux system. It will also make security features easier accessible and comes with a secure automotive-grade over the air update client.
On the HW side, we show our brand new NXP i.MX 8 and i.MX 8X based SoMs. The Apalis iMX8 comes with the highest performance iMX8 and the Colibri and the Apalis iMX8X are very power efficient and have advanced safety features such as ECC Memory.
Also, we have a lot of cool demos such as “IoT Beer” and a full wall of exciting AI Edge applications.
Toradex is at Hall 4, booth 4-410 at Embedded World 2019.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
“Typical customers have projects with volumes from a few hundred to a few ten thousand per year.”
This is exactly what I thought but apparently shipping under 1K volume makes you a “joker” ;p. There must be a point where modules with mezzanine or card connectors become uneconomical because of the cost of the connector etc but LGA solder down modules seem to be non-existent for Cortex-A. Maybe the margins just aren’t there for Cortex-A modules in a mass production form factor.
Where’s that kid who couldn’t figure out who’d spend $54K on SoM parts? Oh, there he is, waving the ‘see I was right banner!’, using his selective memory of recent conversations ; )
Yes, there is a point where SoMs become non-viable. $54 a pop for 1K is not it.
“Where’s that kid who couldn’t figure out who’d spend $54K on SoM parts?”
Oh dear. It was an honest question as I didn’t know an application where those things would be cost effective. The only thing I’ve worked on where a SoM like that would make sense was some highly specialised test equipment that was incredibly low volume and eye wateringly expensive. For that application even a $200 module would be workable because of the margins involved.
“Oh, there he is, waving the ‘see I was right banner!’, using his selective memory of recent conversations ; )
And here you are calling people “kid”. Next you’ll be writing “hurr durr I’ve been in this game since the bronze age”. It’s revealing that all the people that none of the people like yourself that responded with how great SoMs are provided any numbers. As if they had never actually produced anything with that pirated copy of Altium that’s been sitting on their computer gathering dust…
“Yes, there is a point where SoMs become non-viable. $54 a pop for 1K is not it.”
Actually it seems there is a very narrow Goldilocks zone where these sort of SoMs are viable at all.
> Oh dear. It was an honest question as I didn’t know an application where those things would be cost effective
For somebody asking honest questions you still manage to sound rather edgy. That only decreases your chances of getting into truly informative discussions. Just saying.
There is another significant SOM market. It is for companies that don’t have the staff, time, or money to mess with designing a SOC board and then getting all of the software working. There is a lot more to these costs than just the price of the module.
For example I have probably wasted a year of my life fighting with poor software releases from Allwinner and their OEMs. I’m now to the point where we don’t use Allwinner anymore. A central problem is lack of access to the git repositories at Allwinner and having to have an intervening Chinese OEM in the way. That intervening company does not prioritize our software needs and they cause more problems than they fix.
Ah yes, sounds like AllWinner, the “big” important guys that seemingly think their customers don’t matter…
>There is another significant SOM market. It is for companies that don’t have the staff, time, or money…
I guess you could also save some money in production using a SoM because the amount of layers are reduced, tolerances are less strict etc. In my mind $25 for a SoM makes sense for something you’ll be selling to the general market ($200 or under stuff). More than $50 seems like it would be pretty hard to balance.
At $DAYJOB there was a project based around the i.mx6ull that was potentially going to be LGA solder down SoM based but it was about half the price to chuck the components on the board and route out the bits that were required.
>For example I have probably wasted a year of my life fighting with poor software releases
>from Allwinner and their OEMs. I’m now to the point where we don’t use Allwinner anymore.
I’m strongly against using anything that isn’t mainlined. For the above mentioned project I did some of the initial bring up for the firmware. It turned out the SoM we were prototyping with from a “brand name” SoM vendor used a custom module to mess around with a weird PMIC they had come up with and that module only worked with the BSP kernel from NXP. Mainline kernels ran fine for about 5 minutes until the PMIC thing turned off the CPU because the custom driver wasn’t loaded. Of course the BSP kernel was missing something we needed so even if we wanted to get trapped with that it wouldn’t have worked.
The kernel is not really causing us problems, it is the fact that they don’t flow Android updates through the development chain. Companies practicing “port and forget” should be avoided. Allwinner clearly has the Android updates, the breakdown is from forcing a hardware OEM into the middle of the chain that does not care about how our software functions. It is a gigantic hassle getting updates through that chain. And we pretty much don’t get any or maybe once a year.
>Companies practicing “port and forget” should be avoided.
Sadly that’s the majority. So many Linux 3.18 BSPs in the wild that will never be maintained. Even stuff like the Amazon echo’s run 3.18. 🙁
> The kernel is not really causing us problems.
That’s my experience as well. Even when a kernel is beyond LTS, things are still salvageable at the kernel level. Google, for instance, have been backporting 4.x features to *their* 3.18 LTS as they see fit — after all google’s 3.18 is not linux.org’s 3.18. It’s the layers above and beyond the kernel that can make a project stall and roadblock. An OEM’s HAL stack can be such a roadblock, and there GPU vendors are the usual suspects (in my sphere). And it’s not so much a matter of closed- vs open-sourceness, it a matter of vendors who know what they’re doing vs vendors who ‘fire and forget’ so that they can claim they have launched their next product.
I’m wondering what an OEM HAL stack is. I can’t believe anyone would actually advocate for 3.18 kernels either. Next you’ll be saying vendor kernels with thousands of lines of printk debug output and backdoors for debugging are actually a good thing.
> I’m wondering what an OEM HAL stack is.
I literally gave an example in the second part of my original sentence.
> I can’t believe anyone would actually advocate for 3.18 kernels either.
You need to expand your horizons, by quite a bit.
> I’m wondering what an OEM HAL stack is.
>I literally gave an example in the second part of my original sentence.
HAL is “Hardware abstraction layer” right? In Linux that will almost always be the kernel itself. That’s is the majority of it’s purpose. OEMs generally ship what is known as a board support package or a BSP. That’s not a HAL. It’s a collection of pre-baked and hacked up stuff that hides the fact that the ARM eco-system is a car crash mixed in a train wreck powered botnet of e-waste. The weird shims and other shit ARM GPU drivers use is only there to avoid GPL infringement.
> I can’t believe anyone would actually advocate for 3.18 kernels either.
>You need to expand your horizons, by quite a bit.
Ok so you know better than everyone else. What applications does a 3.18 kernel make sense for? Even Google have mandated 4.x series LTS kernels now.
> HAL is “Hardware abstraction layer” right?
Right.
> In Linux that will almost always be the kernel itself.
No. The kernel is just a part of the HAL mechanism. What you’re thinking of are device drivers. Those can be statically linked into the kernel, or dynamically loaded, provided by 3rd parties, open-source/closed-source, etc. Various binary blobs that are loaded by the kernel, to bring up or abstract away various parts of the hw are not the kernel (like for instance the x86 ucode blobs on most people’s PCs). In other words, a linux kernel that brings up a system on binary blobs and 3rd party modules one does not have the sources to is still a linux kernel, tainted or otherwise.
> That’s is the majority of it’s purpose.
No, a function of a kernel of the linux kind is to *establish protocols* for (some portions) of the HAL, not necessary to *implement* those, for the sake of resource arbitration and process management — that latter part is the true kernel’s job. You clearly confuse kernels with device drivers.
> OEMs generally ship what is known as a board support package or a BSP. That’s not a HAL.
The entire HAL for a board should be included in the BSP. Where else would you think an OEM HAL comes from?
> It’s a collection of pre-baked and hacked up stuff that hides the fact that the ARM eco-system is a car crash mixed in a train wreck powered botnet of e-waste. The weird shims and other shit ARM GPU drivers use is only there to avoid GPL infringement.
I see that the example I gave with GPUs flew over you head, as you have no clue how GPUs work. That explains the rest of the gibberish you wrote. So let me elaborate:
A GPU HAL is provided almost in its entirety in user space. It normally comes in the form of libraries implementing low-level GPU APIs. The only part provided by the kernel in this scheme is the GPU buffer protocol — the kernel has no idea what resides in those buffers and what the device does in response to receiving such buffers. To put it bluntly, the kernel provides just a tunneling mechanism to and from the GPU.