Make Your Own SoM

A Modular Approach

In this article, Joseph explains what a SoM is and how it’s useful in embedded design. He covers a design he came up with, and how it helped tackle a sustaining engineering problem during a period of limited time and resources.

But as products get smaller and/or time-to-market gets faster, how can we, as designers, keep up? There are many ways, of course. But one possible solution is to utilize a concept called a System-On-Module (SoM). The idea is the same as an IC, but instead of shrinking down semiconductor technology into a neat little package, we instead use discrete components to achieve the same result. Think of it as a piece of hardware you can use over and over again after you work out the hairy details to get it to work. Rather than re-laying out the circuit in a different printed circuit board (PCB), you can make a mini-PCB with those parts on it, which then, in turn, mount to your next design.

Xilinx defines a SoM as the following:

“A System-on-Module (SoM) provides the core components of an embedded processing system—including processor cores, communication interfaces, and memory blocks—on a single production-ready printed circuit board (PCB).” [1]

This is a solid definition. However, I would argue that it can be any system you’d like. It can be an analog filter system or power system, and in my opinion, is not limited to embedded processing. Though, embedded processing is the most common and natural case to use them.

Does the concept of a SoM sound counterintuitive? Perhaps at first it does, but think about what a SoM can possess that an IC cannot. ICs need to use structures limited to wafer technology and semiconductor processes. SoMs, on the other hand, can use whatever component is out in the market—preferably one in a small form factor. SoMs can be more complex, system-wise, than an IC, because it can have more than one IC that is high in complexity. Let’s dive into some SoMs that you may already be aware of.

Examples of SOMs

Raspberry Pi Pico and STM32 Nucelo are both SoMs, whether or not this was the manufacturer’s intention. Figure 1 and Figure 2 show them for reference.

A SoM can be as simple as a subcircuit that was proven out and that is used repeatedly in a design. No need to figure out how to properly bias all the power rails. It can have a common interface, such as USB, push buttons, and LEDs that are useful for designers and production staff. The examples in Figures 1 and 2 are a bit big, so let’s look at the ESP32-C3-MINI-1-N4 (Figure 3 and Figure 4).

The ESP32-C3-MINI-1-N4 is a great example of a SoM. It includes all parts that can be used over and over from one design to another. The hardware footprint is consistent, making it portable and easy to revise. And the overall package is small; it has over 20 components inside! Its design and size are such that Espressif is able to produce many units, driving the cost down to under $2 USD. Implementing this same circuit in your design from scratch would cost you more in PCB real estate and time.

As a last example, let’s take a quick look at the BMR4640002/001 from Flex Power Modules, a small DC-to-DC converter that can deliver up to 40A (Figure 5). Same concept here—just drop it into your design, as all the hard power circuitry work has been figured out for you.

There are seemingly endless other examples, ranging from barcode readers to RFID modules. But I hope at this point that the idea of a SoM and what it can look like is becoming clearer. So, what if you can’t find a SoM ready for you to use? You can make one! I want to walk you through a real-life situation that happened to me last year, and show how we created a SoM to solve our problem.

When to Roll Your Own SOM

There are times when you simply cannot find the subcircuit you want to use in places like DigiKey or Mouser. This could be because its not popular enough, or that your design is one-of-a-kind and you have no choice but to make your own. Making your own SoM is not hard, but it takes some careful consideration of how you want to use it in future projects.

I was caught in a situation in which the company I worked for had used a 32-bit microcontroller (MCU) from Atmel in every product for the last decade, possibly more. The MCU itself was not a problem, but the supply chain crisis during COVID-19 has scarred us all, and there were concerns that we wouldn’t be able to secure stock of these chips in the future. This started a conversation about when this MCU would reach end-of-life, deepening our concerns.

At the same time, we were looking into making a new product, and so there was a choice before us: Do we switch MCU platforms, or do we stick with the same one? Sticking with the same one meant we could leverage the same codebase. No need to port code. It also meant we could use the same MCU subcircuit that has been working well for over a decade.

But this route would only place more of our eggs into one basket, and increase our supply chain risk. There wasn’t much diversity in MCU platforms the company was using—so if that MCU vanished from the market, the company would have to race against the clock to port everything over to a new MCU platform while re-spinning new PCBs.

At the same time, switching to a new MCU can be a regulatory nightmare. As the die of a MCU shrinks, they tend to have faster rise times, and thus tend to have a higher chance of failing conducted and radiated emissions testing. If a customer were to suspect our equipment was interfering with something else in their setup or system, we’d need to prove that it wasn’t our device with a regulatory report. In short, changing an MCU in reaction to a possible supply chain crisis is a bad idea. A proactive approach is better.

This is where the SoM idea was proposed. Instead of porting code, re-spinning the PCB and possibly enduring regulatory headaches, we can simply re-spin the PCB to have the SoM footprint—further PCB re-spins for an MCU change would not be required, as only the SoM needs to change. We can switch to a new MCU in steps, as appropriate for a business with limited time and resources.

I must admit, this is not exactly my idea. I’ve seen a company use a SoM for an MCU, before. But I believe they got the idea from the Arduino platform. Arduino is not an MCU, but rather a platform that can use the same codebase with different MCU targets. That means the same code can run on every MCU that supports it, decreasing time-to-market and simplifying porting efforts. The SoM approach is like having an Arduino that’s made only for the employees of that company. Of course, the firmware staff needs to create the libraries and modules to standardize certain functions common to all MCUs, such as sending out UART packets and GPIO control. But once you’ve leaped that hurdle, it’s much easier to switch between MCUs, especially if the same footprint for the SoM is maintained.

Steps to Create Your SoM

Where does one start, in making a SoM? For me, it was by looking at examples of other SoMs out there in the wild. I took design aspects from the ESP32-S3-WROOM. The WROOM uses castellated holes on the carrier PCB. Think of these as plated holes that are cut in half, creating a pin-like structure. Figure 6 shows an example of this.

The next step is to pick dimensions of the castellated holes and their pitch. This is where the ESP32-S3-WROOM datasheet came in handy [7]. It shows both the footprint and the physical dimensions of their SoM. This is where I extracted this information. The source of this information is shown in Figure 7 and Figure 8.

Once I created the part in CAD (in my case this was Altium Designer), I exported the part onto a footprint that I created for the SoM. It all fit wonderfully, building my confidence that the design I had was going to work well mechanically the first time.

Next was to have an abstraction for the SoM’s pins. The Atmel MCU uses its own convention to identify its own GPIO. The future MCU to be used in this SoM form factor is unknown, but chances are high that it will not follow the same convention. This is where the Arduino platform inspired me once again. The Arduino has its own way of identifying the GPIO pins: It uses only a number for the GPIO pin, and denotes whether it can be used for digital, or analog/digital. Drawing from this concept, I developed a convention with our firmware engineer. We settled for Pa[n] and Pd[n]. For example, Pa2 meant that GPIO 2 in the Pa group could handle both analog and digital operations. Whereas Pd3, for example, could handle only digital signals in that group.

Other pins, such as UART, SPI, I²C, and USB were called out by their usual naming conventions, because on most parts these are standard peripherals. The MCU we were working with only had one of each (except for the UART, where there were three to break out), so it was relatively easy to allocate onto the SoM abstraction.

So far, so good. But should we add anything else? The firmware engineer and I thought about it, and we concluded that there was simply not enough digital I/O for the future product that needed to be created with this SoM. We elected to place an I/O expander on the I²C bus to get around this limitation. If the SoM in the future used an MCU with more I/O, we could get rid of it. We also placed an on-board linear regulator to create a +3.3V rail from +5V. Sprinkle on all the decoupling capacitors, an LED for debugging, and a crystal for the fastest clock operation (and chosen to work in tolerance with USB), and, voila!—we have ourselves a company SoM! This is shown in Figure 9.

Testing & Iterating

When we got the SoM in from our fabrication source, it was like a work of art. It looked beautiful. Unfortunately, the first version had some flaws. This MCU had two power rails that were missed and miswired, the I²C bus labels were mislabeled on the silkscreen, the I/O expander interrupt pin was incorrectly terminated, and we missed a UART channel. We did have a review meeting, but the project was going at lightning speed, so details were unfortunately glossed over. But after some tweaks and reworking, it performed quite well.

This brings up a good point in general with new designs: test, re-test, and then test again. To be sure we had something viable, every bus and every GPIO pin was exercised in code. It also ran for weeks before we were comfortable revising the mistakes. As for documentation, it is useful to create something we call a SoM Mapping Chart. This chart organized the SoM Alias (the pin name, such as Pd11), the SoM pin number on the footprint, the MCU alias (what the manufacturer called that pin), the MCU pin number on its footprint, and the assigned SoM function (digital, digital/analog, UART, and so forth). This helps tremendously when converting a non-SoM design in legacy products into ones with a SoM, and it aids in debugging and the creation of the library on the firmware side.

Advice On Creating Your Own SoM

At the end of this small adventure, we wound up with exactly what we wanted in the engineering department: a SoM that can be used for both future and legacy products. It saved us time in getting to market, limited PCB re-spins (once the legacy is converted to a SoM), eliminated re-laying the MCU subcircuit, and simplified future code porting. Of course, with any project, there are always things you wish you knew before going in, and things you were happy to get right in the beginning.

The idea of the SoM worked well for my situation, but it’s not a panacea. It may not make sense to create your own SoM if you need the product to be especially small. The products created by the company are benchtop devices that are able to accommodate the physical space. Also, if your product does not have the profit margin to allow for some extra cost, this approach may not work well for you. Even though SoMs on the marketplace are cheap, yours won’t necessarily also be cheap. Companies selling commoditized versions of their subcircuit can do so with large volumes and can price cheaply.

When creating the physical device in CAD, I had no idea where to start. So draw inspiration from existing solutions, alter it, and make it work for your own technical and business needs. A square-like profile shown in Figure 9 was something I had not seen before in an SoM, so I made sure that our PCB fabricator could make it, and that our assembly house could put it together without much trouble (and, of course, that we could use it as a component for another board).

It’s all about part density. Don’t choose large, passive components or large ICs (unless that IC is required and cannot be sourced in a smaller form factor). Instead, opt for 0402 components (or smaller), and leadless components, as these are intended for higher-density PCB layouts. Some engineers might be opposed to small and leadless components, but the reality is that most fabricators and manufacturers have no issue assembling QFNs or 0402 components. It has become commonplace. If they do find it difficult, find another place, as this is an indicator that they are becoming outdated. As for the engineers who are not fans of small components or leadless packages, it is the same story. They’re not keeping up with current technology and need to swiftly get more comfortable with these devices, because they’re not going anywhere anytime soon. (And when they do, their replacements will be even smaller.)

The board thickness for the ESP32-S3-WROOM and similar SoMs are 0.8mm. That is half the size of a typical FR4 PCB design. This thickness is appealing to me because of the profile height. I also think doing everything possible to decrease weight for the pick and place machine is in the best interest of the design and helps limit assembly time (for rework or placing by hand). The disadvantage is that PCB warpage can be a real issue. This is why I chose to have each SoM in its own panel. It also helps to cut the panel off, rather than bending off by hand, to limit the warpage the PCB experiences. As far as plating goes, stick with ENIG plating. It is the preferred plating for high-density components like BGAs.

As for the clearance and via constraints: For the sake of cost savings, only go as close or small as you require for your parts. I found it possible to use 6mil traces with 6mil spacing with the SoM I created. And since it was not a tight-pitched BGA, I was able to use through-hole-plated vias. Blind or buried vias were not necessary.

Lastly, create a SoM Mapping Chart, as mentioned earlier. It will save you an immense amount of time debugging and bringing up the board. Your firmware engineer will also thank you. I spent many hours jumping through datasheets and schematics just to map the SoM number correctly. It might take more time to create it, but it will pay you handsomely in future dividends.

Conclusion

And there you have it! In summary, SoMs are not just for large companies, but also small companies that require a quick entry into a market via a new product release. It can help guard against (or delay) supply chain correction efforts, and eliminate the need to re-lay out the same subcircuit over and over again. I hope that my small adventure in making an SoM gives you some ideas and possibly helps you out in the future. Until next time! 

RESOURCES
Espressif Systems | www.espressif.com

REFERENCES
[1] Xilinx—“System-on-Modules (SoMs): How and Why to Use Them”: https://www.xilinx.com/products/som/what-is-a-som.html
[2] Raspberry Pi Pico Development Board (Raspberry Pi Pico WH RP2040)—DigiKey: https://www.digikey.com/en/products/detail/raspberry-pi/

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • APRIL 2024 #405 – Get a PDF of the issue

Sponsor this Article