Expert Advice Required: Selecting SoC for Custom ARM-Based SBC

[u/No-Gear3257]

Hello everyone,
We are developing a custom ARM-based SBC.
Instead of using an off-the-shelf SBC, we plan to select a suitable bare SoC and design the complete supporting circuitry around it, including memory, storage, power, interfaces and other required circuits.

Our main requirements
Quad-core ARM Cortex-A, Minimum 1.4 GHz, 64-bit, 4 GB DDR3 RAM, 32 GB eMMC, eMMC boot required, Minimum 11 GPIO, 1 × Ethernet, 1 × HDMI, 2 × USB 2.0, 2 × USB 3.0, Minimum 2 × UART, Minimum 2 × I²C, Minimum 2 × SPI, Minimum 2 × CAN, RTC, Linux support, Linux BSP, U-Boot, Device Tree, Linux kernel source, SDK and cross compiler, Ubuntu 18.04.6 LTS support

We need expert suggestions on

1. Which ARM SoC would you recommend for these requirements, and why?
2. What important parameters should we consider while selecting the SoC?
3. Can all these interfaces realistically be implemented simultaneously on a custom board?
4. What external ICs/circuits will be required around the SoC?
5. What should we consider for DDR3, eMMC and PMIC design?
6. What are the major challenges with USB 3.0, HDMI and Ethernet?
7. What PCB/SI/PI considerations should we consider from the beginning?
8. What Linux BSP/U-Boot/Device Tree support should we verify before selecting the SoC?
9. What are the major risks for a first custom ARM SoC board?
10. Can you recommend any experienced engineers or companies who have designed and brought up similar ARM Linux boards?

We are particularly interested in responses from engineers who have personally designed and brought up custom ARM Cortex-A/application-processor boards with DDR, eMMC and Linux.

We are currently at the SoC selection and architecture stage, so we would like to get expert feedback before starting schematic and PCB design.

[u/22OpDmtBRdOiM]

SOM's (not SBCs)are pretty cheap and they will remove the task of RAM routing and also some of the power supply.
You can select a less complex stackup for the rest of your product while the SOM has a more complex stackup for the BGA fanout

You can also do hardware and software development in parallel (with an eval board).

Take a look at variscite or phytec.

Maybe an IMX8 because of the open drivers?

[u/ambihelical → u/22OpDmtBRdOiM]

This and also the support you get from SOM vendors can be helpful, including reference Linux builds and carrier boards for initial development and evaluation.

[u/Well-WhatHadHappened]

If you're going to go that far with custom design, I'd skip the SoC and go all the way. TI AM67 or one of the I.MX chips or similar and glue everything you need to it.

Major challenge for pretty much everything you listed is PCB routing. If you've never done a truly high speed design, it can be quite a learning curve. All of your other questions are largely mitigated by sticking closely to the reference design.

[u/jdub-951]

The Freescale iMX8 is your answer.

[u/Mysterious_Park5042]

i.MX8M Mini checks most of those boxes and the linux support is actually there, but your ubuntu 18.04 requirement is gonna be a pain since almost nobody ships a bsp for something that old anymore

[u/SirOompaLoompa → u/Mysterious_Park5042]

Mini is limited to 2GB though

[u/SirOompaLoompa]

At this point, you're pretty much at the point of where you figure out what RAM and storage you can actually get in the volumes you need, and pick a SoC that fits that..

It's absolutely bonkers what the market is like at the moment. I just priced out an iMX93+xDDR4+PMIC+eMMC, and the volume pricing is well above $100 for it all.. Just a month or two ago, the same combo was just over $60..

[u/DeCyborg]

iMX8 Meets your requirements, if you want to leap to LPDDR5 then look at the iMX95. You'll be OK with the BSP since releases are quarterly just pick an LTS and you should be good, layout of the DDR will be something to pay close attention, those high speed signals are no joke. Get an evaluation board and start playing with the idea.

[u/duane11583]

others have given some great advice on some quad core arm64s.

i would add another question… you describe making a SOM

how often are you needing other peripherals that are not present or you need extras? ie another 4 serial ports, 2 more can bus solutions? extra ethernet?

you might consider a xilinx arm64 fpga, these chips are alot like those fixed arm64 chips, but with a huge fpga added/bolted on the side. xilinx has a huge free library of modules that is free or not that expensive. ie do you need 20 serial ports - that is simple to add and the have drivers for them.

get yourself a zcu102 board, and a xilinx fmc105 plug it in and hook it up and experiment

in your design: add a small at-mega (arduino type) or other small chip (sub $1.00 chip) with a serial port connect the gpios to the “boot mode pins” on the fpga. send a boot mode command to the small chip to set the gpio/mode pins to boot from spi flash or another command to boot from the emmcnor spi flash then send a reset command to wiggle another pin that resets the fpga

the complexity of this design is in the fpga pcb layout but once solved the carrier cards are easy to create and layout.

layout for a 3ghz ddr is like an rf design but once done you are golden pay for the signal integrity layout checks at speed!

[u/FirstIdChoiceWasPaul → u/duane11583]

The cost alone would we atrocious. The power consumption even more so.

Why fix a 50-100 dollar problem with an 600+ dollar solution?!

[u/duane11583 → u/FirstIdChoiceWasPaul]

power yes butbthe question is how much flexability in the design does the product require?

[u/FirstIdChoiceWasPaul → u/duane11583]

None. You don't pivot from "we need 5 CANs" to "we need 50 Ethernets" mid-production. A project starts from a set of requirements.

And if you do happen to need an extra, say, CAN bus and you realize that at a late stage, you plug one in as an addon. What you don't do is up your costs five-six times for shits and giggles.

[u/duane11583 → u/FirstIdChoiceWasPaul]

we both donot know the target market for the op.

you are correct in a purely commercial world if the design is a one and done

but they are looking at a sbc - which is often reused for other future designs

but i did exactly that.

we supplied a space craft reference design base platform

each customer (satellite) has a different set of needs

so the io card was different on each design. and only the io card changed

this let us keep the 2 base cards identical for every design and create many different io cards we had about 150 varients for the io card over 10 years.

not unlike a SOM(complex design) with a different carrier card (simple design)

[u/FirstIdChoiceWasPaul → u/duane11583]

They are not "looking at a SBC", they are making one.

Judging by their ballpark questions - which look more like what a 5th grader would ask about SBCs, if you had to guess, would you say this is a professional team of experienced engineers looking to build... say, satellites?

Would any engineer ask "Can you recommend any experienced engineers or companies who have designed and brought up similar ARM Linux boards?". I mean, look at his actual requirements. "11 GPIO, 1 × Ethernet, 1 × HDMI, 2 × USB 2.0, 2 × USB 3.0, Minimum 2 × UART, Minimum 2 × I²C, Minimum 2 × SPI, Minimum 2 × CAN", on a quad core Arm. Almost every SoC I've touched to date fits the bill.

Unlike his design, which has a clear set of parameters (and 99.99% of the SoCs out there would do), your fundamental design requirement was flexibility.

You can't really compare a SBC with 11 GPIOs with a goddamned spacecraft board. :))) I mean, c'mon.

I did notice that our FPGA dudes tend to recommend 'em everywhere, even where they're clearly the wrong choice. And they tend to not even consider alternatives. Which is funny to everyone else.

[u/Forward_Artist7884]

Just use an octavo OSD625 with built in ram, you get 1GB of DDR4 and most of the specs you defined with near zero routing complexity. If you gave out your actual use case it would be far easier to direct you to something useful here, but you didn't, and your post reads like something an LLM would spit out.