Worth pursuing DDR4 design vs SOM - Page 1
Forum section: electronics / general

author: loki42
author_rank: Frequent Contributor
timestamp: August 01, 2023, 01:18:31 pm
content: So the SOM I was thinking about using has (intel compute module) has been cancelled by Intel. I'm now looking at the qualcomm options which are both very powerful and cheap. However they are a bit scary to design as they are a soc not a som. So I'll need to place bgas, probably do scary HDI stuff and route DDR4. I've done usb and 800mhz MIPI before but nothing over 1 GHz. How hard is the faster stuff? Should I ignore the soc option and just use slower soms that are much more expensive and much less available? It's a consumer product without a lot of margin. The total bom cost of the soc + power + ram + pcb is less than 1/4 of a vaguely similar speed som.

author: asmi
author_rank: Super Contributor
timestamp: August 01, 2023, 01:37:18 pm
content: If you've got the right tools, there is nothing hard about it. There are just a bunch of rules you have to follow, and that's it. Also many SOCs actually come with reference designs for memory and other high-speed stuff, which you are encouraged (and sometimes even required!) by the vendor to replicate them in your designs. If that's the case for your SOC of choice, you don't even need to know much about high-speed and SI - you can simply copy-paste pre-verified layout and refrain from anything stupid like adding ground voids under that routing. Just remember to pay attention to the stackup - in order for vendor-provided layout to work, you also need to replicate the stackup they used. Stackup not only affect trace impedance, but also affects the crosstalk, so it's important to get this part right, and it's often overlooked.As for SOM vs SOC, it usually comes down to volume. If the volume is large-ish, it's cheaper to use SOC and design a board from scratch, because NRE costs will be amortized over large number of units, and also your custom design will probably be cheaper than SOM because the latter tend to be over-built to support as many various applications as possible, while your design can be very specific to your application.

author: tszaboo
author_rank: Super Contributor
timestamp: August 01, 2023, 02:59:07 pm
content: Well, the issue is not designing the things. The issue isa) You design it, order it, it doesn't work, no idea why. You don't have the tools to debug it, and it's only two signal rising edges have to be 15ps from each other.b) You design it, you order it and it works - barely. You again, dont have the tools and knowledge and time to do design verification. You end up a bad design which works, instead a proper design.c) You design it, deviate from the reference design just a little bit, and spend weeks writing linux kernel level patches writing amgic numbers to magic registers that you have to figure it out yourself, with barely functional support from your supplier.I have done or witnessed all three of these. It's not fun.

author: nctnico
author_rank: Super Contributor
timestamp: August 01, 2023, 03:44:45 pm
content: Quote from: tszaboo on August 01, 2023, 02:59:07 pmThat happens only if you use SoCs that have no support from the manufacturer and/or use PCB design tools that are inadequate. For designs like these the goto CAD tool is Orcad PCB Designer Professional (or better) as this also support internal package delays, Z-axis (via) delays, and impedance & cross-talk simulations to make sure the memory traces don't see a lot of impedance variations.Next step is to use a SoC that has tools provided by the manufacturer to get DDR memory going. NXP (for example) offers various tools to generate the right initialisation for a certain memory and stress test the design. If you can't find these kinds of tools for a SoC, run away!Vendor provided reference designs go a long way but from what I've seen these tend to use ultra fine line PCB technologies which are hard to produce. I typically go from a reference design and try to stay close to it but due to different (easier to manufacture) PCB technology I always end up with a slightly different PCB design (sometimes more layers, sometimes less layers; it always depends).

author: asmi
author_rank: Super Contributor
timestamp: August 01, 2023, 03:56:14 pm
content: Quote from: tszaboo on August 01, 2023, 02:59:07 pmWhen it comes to memory, SoC vendors typically provide some sort of tools to execute a memory interface diagnostics, here is example for Xilinx Zynq SoC (look at 20:38 if you don't want to watch the entire video):https://youtu.be/W3Jt_y6PHjA?t=1208As you can see, you can not only run memory tests, but also perform in-circuit read and write eye measurement without any expensive equipment, which will tell you what kind of margin does your design have. Other vendors provide similar tools functionality-wise. Here is the one for iMX6 and 7 series SoCs:https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-6-7-DDR-Stress-Test-Tool/ta-p/1108221and here is the same for iMX8:https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467

author: loki42
author_rank: Frequent Contributor
timestamp: August 01, 2023, 09:52:01 pm
content: So basically it's how easy is it to implement the reference design and does it come with handy tools. Has anyone done layouts with Qualcomm chips? I don't think the brands mentioned have anything in the price / performance range I'm looking at.

author: tszaboo
author_rank: Super Contributor
timestamp: August 01, 2023, 10:22:28 pm
content: Quote from: nctnico on August 01, 2023, 03:44:45 pmWell, it's nice and dandy if you have the resources for it. I kid you not, when I took over the design after the previous fresh graduate engineer quit, it was made in Eagle. And the company had a nice handheld multimeter and a Tektronics TDS2000 oscilloscope with a generous 100 MHz bandwidth to debug electronics.Quote from: asmi on August 01, 2023, 03:56:14 pmCool I just time travel back about 15 years and tell the guy struggling with this to use something like this on that ARM9 MPU.If memory serves me right, actually the new DDR2 interface made routing signals easier than the original DDR, the timing constraints were more relaxed.

author: asmi
author_rank: Super Contributor
timestamp: August 02, 2023, 04:00:44 am
content: Quote from: loki42 on August 01, 2023, 09:52:01 pmI didn't, but in any case I would start by trying to reach their FAE or sales rep covering your area, as some vendors only provide you with reference designs and tooling after you execute an NDA with them.

author: asmi
author_rank: Super Contributor
timestamp: August 02, 2023, 04:23:55 am
content: Quote from: tszaboo on August 01, 2023, 10:22:28 pmThat was sort of my point - a lot has changed in this field since that time.Quote from: tszaboo on August 01, 2023, 10:22:28 pmI personally think DDR2 is the most PITA of all DDRx memories, because of requirement for doing a balancing tree for address/control signals. Fly-by routing introduced with DDR3 has been a godsend for wide interfaces.

author: loki42
author_rank: Frequent Contributor
timestamp: August 02, 2023, 05:07:53 am
content: Quote from: asmi on August 02, 2023, 04:00:44 amChatting with them and filling in more forms at the moment. I was keen to know if the forms were worth the effort. I had meetings with AMD-XILINX and they just wanted to sell me Xilinx stuff which is a pretty terrible fit for what I want to do but obviously what they needed to sell this quarter. I didn't hear much back about Ryzen. Intel was easy then then cancelled the product line.

author: asmi
author_rank: Super Contributor
timestamp: August 02, 2023, 05:55:57 am
content: Quote from: loki42 on August 02, 2023, 05:07:53 amI seem to recall your application is heavy on SIMD, if you can effectively parallelyze it for GPGPU, you might want to look at NVidia's SOCs as they contain not only ARM cores, but also a GPU, which, if utilized effectively, will give a run for the money to any CPU solution, having much more FPU computing power while being more power-efficient. And they sell SOMs so you won't have to deal with high-speed stuff so much. Take a look here:https://developer.nvidia.com/embedded/jetson-modules

author: loki42
author_rank: Frequent Contributor
timestamp: August 02, 2023, 08:20:51 am
content: I've looked at the NVidia SOCs and they are very nice. The interchangeability and GPU power is wonderful however GPGPU is too high latency for my use case. I need lots of single core float performance. Thus why I'm either looking for a very fast ARM core or basically any old x86 core. I'm currently running a A53 and need at least 4 times the float performance.Use Geekbench 5 ( I know all benchmarks are a specific case etc) but single core float scoreQualcomm Kyro 460: 427 ($70 BOM cost, lots of dev effort)Celeron 6305: 614: $120 SOM (but intel just stopped production)Jetson Nano: 198: $129 SOMJetson TX2 NX: 295: $200 SOMOrin Nano: 554 $259 SOMA53: 69 float score.So the Orin Nano is a little faster the the Qualcomm but almost 4 times the price. It might still be attractive given the saving in development time though.

author: asmi
author_rank: Super Contributor
timestamp: August 02, 2023, 10:34:43 am
content: Quote from: loki42 on August 02, 2023, 08:20:51 amThis is what lazy developers say, who can't think parallel. Those SOCs have shared memory for GPU and CPU, and so there is no latency (nor there is a need) to move stuff between GPU and CPU memory. Tell your software folks to stop being lazy and come up with a GPU-friendly version of their algorithm. And don't tell me it's impossible.

author: loki42
author_rank: Frequent Contributor
timestamp: August 02, 2023, 01:11:44 pm
content: I am all the folks, well I have 1 employee. And I enjoy the sheet metal working part more than the programming part but realistically real time low latency audio dsp with a gpu is hard, and probably too hard for me, especially when I want the algorithm to work on multiple CPUs. Fast float is easy. So yes Lazy.

author: asmi
author_rank: Super Contributor
timestamp: August 02, 2023, 01:44:56 pm
content: Quote from: loki42 on August 02, 2023, 01:11:44 pmI highly recommend you to overcome your laziness, buy a Jetson Nano Developer Kit (it's only $148) and give it a try. Even if you won't be able to come up with a GPU-friendly version of the algorithm, it's still worth putting the effort into learning how these things work, because they enable many applications which are simply not possible using CPU, no matter how powerful they are. And they will teach you to think parallel, which is also very useful. Also many GPUs in embedded SOCs nowadays support OpenCL (which is a cross-platform alternative to NVidia's CUDA), so you can transfer that knowledge and experience to other SOCs as well.I would also look at FPGA implementations since those excel at DSP as well and can offer super low latency (because there are no interrupts to answer for, no sleep states, timers and other things, pipeline just chugs along no matter what with guaranteed latency and throughput).

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2023, 07:09:01 pm
content: I'm not so sure the Jetson modules are the best choice. I have designed a product using one of the Jetson modules. They do offer a lot of performance, but getting the software going can be a real PITA. Documentation isn't great and a lot of info is hidden on their forum which in many cases was obtained through trial & error. Another problem is that the hardware changes every now and then making the existing software incompatible (mainly the bootloader). This means spending time on stuff that already worked just fine. The latter is a problem with SOMs in general. As a rule of thumb I always tell customers that when more than 100 to 150 units are needed, going full custom is cheaper.For the iMX8MQ I even created a partial design I can drop into new designs very quickly which reduces the development time to integrating a SOM in a design.

author: tszaboo
author_rank: Super Contributor
timestamp: August 02, 2023, 08:07:27 pm
content: I'm just going to drop the name Toradex here. They are Swiss, make SOMs that are interchangeable with each other. So you design your base board and then decide later if you want an IMX or an Nvidia SOC. Or start with their carrier boards. I have an old Nvidia board from them that boots windows CE to desktop in like a second.

author: loki42
author_rank: Frequent Contributor
timestamp: August 02, 2023, 09:50:37 pm
content: Quote from: asmi on August 02, 2023, 01:44:56 pmIt will be far too expensive to port 100s of modules of dsp code that needs to run on CPUs in the future to FPGA or GPGPU. I'm familiar with Cuda / opencl luckily haven't used them as much as I used to in the last decade. Sorry I should have mentioned I'd looked into non single core float options and some of the algorithms can use other options but in this design they aren't cost effective.

author: loki42
author_rank: Frequent Contributor
timestamp: August 02, 2023, 09:59:12 pm
content: Quote from: nctnico on August 02, 2023, 07:09:01 pmI'm aiming for a few 1000 units / year. I don't have x Ray in my line so I've avoided big bga but given the cost differences and the control advantages it looks attractive to just use the SOC instead of the SOMs. I don't have fancy signal integrity software though.

author: loki42
author_rank: Frequent Contributor
timestamp: August 05, 2023, 11:06:56 pm
content: Quote from: nctnico on August 02, 2023, 07:09:01 pmThis is super useful info. The Orin looks like a good option but I expected solid software compared to the allwinner etc I've used in the past. Qualcomm looks a lot better from a driver point of view, GPU driver is open source so less likely to have fun bugs with the RT kernel.

author: Scrts
author_rank: Frequent Contributor
timestamp: August 07, 2023, 02:48:51 am
content: Which exactly SoC are you looking for from Qualcomm?The SA8620/SA8630/SA8650 will all have SOM as QAM86xx accordingly. SA8255 will also have QAM8255 AFAIK.If you will go with SoC only - you will most likely also have to buy and implement Qualcomm PMIC.

author: loki42
author_rank: Frequent Contributor
timestamp: August 07, 2023, 03:01:12 am
content: Quote from: Scrts on August 07, 2023, 02:48:51 amQCS410 / QCS610.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 07, 2023, 03:58:37 pm
content: Quote from: loki42 on August 02, 2023, 09:50:37 pmHow did you determine cost-effectiveness? I don't know your exact numbers, but still:1000 parts/year * 10 years * $200 = $20000001000 parts/year * 10 years * $100 = $1000000$2000000 - $1000000 = $1000000$1000000 / 30 software modules = $33000 gain per module re-written

author: loki42
author_rank: Frequent Contributor
timestamp: August 07, 2023, 10:15:23 pm
content: There's about 120 modules but also where do your numbers come from? The celeron is the cheapest... the orin gpu would be handy for future stuff (AI training). The big cost saving vs time appears to be soc vs som.

author: NorthGuy
author_rank: Super Contributor
timestamp: August 08, 2023, 03:03:00 am
content: Quote from: loki42 on August 07, 2023, 10:15:23 pmMy numbers are bogus. Hard to come up with something realistic without knowing the details. With audio, you probably can live without floating point and also with less than whole 23-bit resolution of single-size flots, and you performance is probably determined by a number of multiplications that you can produce. Even if you manage one multiplication per cycle (which is too optimistic even with SIMD) on a 2 GHz CPU, you'll get 2G multiplications per second. For comparison, you can get the same performance from 5 DSP blocks in FPGA running at 400 MHz. Entry-level Spartan-7 FPGA ($15 to $20 in single quantities) has 10 DSP blocks. Thus running floats on a big CPU may not be the most cost-effective solution.Of course, your situation may be totally different.

author: loki42
author_rank: Frequent Contributor
timestamp: August 08, 2023, 11:08:15 am
content: Yeah, fpgas don't suit our algorithms. ANN stuff, long convolutions etc. I had meetings with AMD xilinx about their product line but fast celeron works a lot better for us.

author: stone
author_rank: Contributor
timestamp: August 08, 2023, 01:19:19 pm
content: You can use the model of Chinese FPGA manufacturers

author: asmi
author_rank: Super Contributor
timestamp: August 08, 2023, 02:13:29 pm
content: Quote from: loki42 on August 08, 2023, 11:08:15 amQuite the opposite - this is exactly where FPGA (and GPUs for that matter) excel and trash even the fastest modern CPUs without breaking a sweat.Quote from: loki42 on August 08, 2023, 11:08:15 am

author: loki42
author_rank: Frequent Contributor
timestamp: August 08, 2023, 10:16:22 pm
content: Quote from: asmi on August 08, 2023, 02:13:29 pmI might be wrong about the ease of porting over 100 dsp algorithms to fpga. The chip also needs to run opengl for the gui and the collection of dsp modules used in every patch and how they are connected is totally flexible depending on the user. With my limited FPGA skills this sounds very expensive to do, but I could be wrong. Maybe the fpga som with gpu will be faster than the celeron and cost less than $100. If so please suggest.

author: nctnico
author_rank: Super Contributor
timestamp: August 12, 2023, 06:55:22 pm
content: IMHO it is good to consider portability & maintainability of algorithms at the expense of ultimate performance / low power. In the end it is the algorithms that make your IP and company valuable. It could be worthwhile to try and convert a few algorithms to OpenCL and see how that goes though to improve the power / performance ratio without giving up on portability.I recall being in a meeting several decades ago where my employer at the time wanted to buy some IP in the form of DSP algorithms so we invited a company over to show what they had to offer. It turned out all their algorithms where written in hand crafted assembly for a DSP that was already in end-of-life stage. So at the least the algorithms would need to be rewritten for the new version of the DSP. At that point in time Intel's x86 processors really started to pick up speed. So in the end we ditched the DSP idea and simply ran the DSP algorithms (written in C) on the x86 platform which offered enough performance.Nowadays a cheap GPU outperforms an x86 processer easely for tasks that can run parallel. A long time ago I experimented a bit with crypto mining and GPU versus CPU performance ratio was like 30 to 1. And it looks like there is even GPU processing support for Python which could help maintainability / flexibility.

author: loki42
author_rank: Frequent Contributor
timestamp: August 13, 2023, 12:11:12 am
content: Yeah I've had a look at VHDL and Verilog many years ago and just had a quick look over it when this was mentioned... porting a whole synth will be a lot of work. Then I'll need to maintain multiple versions as we'll still need to run on existing hardware, new content will take longer to do, I'll end up doing less of what I enjoy. So if I can spend less money to have a product that is easier for me to build new content for but I might lose some magic internet points I'm pretty okay with that. There might be easy cross platform tools I don't know about though. Basically they all need to run in a multi processing Linux environment with multiple of any module running which from my understanding makes some of the fpga stuff harder as nothing is fixed. Open CL / CUDA on a gpu makes more sense though. The Orin looks like a good SOM but it doesn't support mipi DSI so I'd need to stock two lots of screens which is both cost and space expensive. Lead times on screens are usually long too.