Carrier board design

This is part 1 of 4 part series.

Introduction

There is a shift in the industry where more and more software engineers are coming into the hardware side, primarily driven by the rise of IoT, existing products are getting connected to the cloud, even if it does not make any sense for the user for this. I guess, the data is what the corporations are after, and are investing heavily in IoT. There are some products that make you think, why on earth this needs to be connected to the internet. On other hand, there are of course genuine use cases for IoT.

There is a high chance if the embedded device that is not battery powered it will be running Linux. This shift started when the first raspberry pi was released. This attracted a lot of software engineers. This was a really positive, as embedded devices got a lot smarter and capable.

So, due to this shift, more engineer with background in desktop and cloud computing are sometimes writing code for embedded devices to fill in the gap. From microcontroller stand point these are immensely powerful. But when engineer that code on desktops and cloud feel the devices is very underpowered, I have seen some times leading to software bloat.

For embedded devices to become a techincal success it needs proper architecture and resource managemnt not only on the software but on hardware too. Here we will talk mostly about hardware. And I forsee many more devices running on Linux in the future.

Using Linux has its tradeoffs, you lose on power saving, there is a slightly high cost, but the time to develop the software is relatively fast. Once you boot up the linux image and in userland, that is when you hardover to software.

The line between micro-controller and micro-processor is getting blurred real fast. There are very low cost chips available that cost in the same range as some high end microcontrollers.

There is also a new player RISC-V (Pronounced risc-five). It has grown from a academic project into a commercial product. I’d give it a few more years before I start using them into my product design, till than I’ll stick with ARM. Overall it’s a great step, now you have another option apart from ARM arcitecture.

So, for hardware engineers who have worked with 8- or 32-bit controllers, they need to design pcb for processors running OS, these needs some extra attention. Something that worked on microcontroller board may not work with board running Linux. Let’s get some nomenclatures out of the way, first is the SoC: system on a chip, this can be a micro example of the nRF52, which has Bluetooth, flash, CPU on a single integrated chip.

SoM stands for System on Module, is similar where the concept is similar but each component (RAM/flash memory, CPU, Wi-Fi/ETH communications) is an integrated chip on its own. These components are usually placed on a highly dense, 8–12-layer PCB. This PCB is called the System on Module. These are often called as daughter boards. These SoM are designed in a way they need to be connected to another board to receive power and have the interface signals connected to the connectors. These connectors are either edge connectors or have high-density connectors. The carrier board route these interface signals to their proper connectors.

Now why is there a need to do this, you could very well have a board, with the CPU, RAM, flash, power supply, and connectors on a single board. The answer is lower cost, reduced complexity and faster time to develop/market, lowering the barrier to entry. It’s a smaller bite to chew and don’t be afraid of the industry gatekeepers.

Knowledge and making mistakes will get you there. There is no magic going on.

Another word that gets used a lot is high speed design, I’ll have a seperate post for this.

How is this low cost?

If you design a board, it will usually be bigger than the SoM size, and the whole board would be 8-12 layers depending on the CPU size. This will make the cost of PCB quite high and more expensive revisions. You would also spend 1-2 months laying out the RAM chip (steam deck engineers took that amount of time). Not all CPUs have their datasheets public, you’d have to sign an NDA to get the docs, and some don’t entertain small players or individuals. This narrows your choices by a lot. In some cases, there is no other option but to use a SOM, e.g. Nvidia jetson, to have its components embedded on SoM Plus, you also need to make sure of what substrate material you will be using. You will need a lot of experience to get this going. So, using this approach you not only same on money but time as well.

Designing a carrier board is a stepping stone to design your own SoM or integrated boards. As your mistake wouldn’t be as costly and will take relatively less time to turn a revision board.

SoM solves a lot of these problems; you are offloading the engineer hours to a bigger company that has the resources. You pay a little upfront but you save on time. SoM also helps to have a quick upgrade or replacement if any one of the components fails. One notable SoM is from Compu lab which is on the Mars rover.

Once you get some experience with this style of design, next jump would be have tightly integrated on a single board.

Before we dive deeper in to the design of the carrier board, there are some fundamentals we need to get over.

The very first thing you need to know before starting out is what is a transmission line.

We will talk about in part 2 of the post coming next Thursday.

No part of this post was generated using LLMs or diffusion models.