8 ms·

I'm hoping someday there will be an embedded Linux processor with this much cache. 128MB on-die SRAM means the PCB would no longer need separate DRAM. The compl

I'm hoping someday there will be an embedded Linux processor with this much cache. 128MB on-die SRAM means the PCB would no longer need separate DRAM. The complexity of the board routing would also go down. That much RAM ought to be enough for a lot of embedded applications.

diarmuidc 4y ago
There are SOCs available with the DRAM on top already. eg https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/32-bit-mpus/sip-and-som/system-in-package https://www.microchip.com/en-us/products/microcontrollers-an...
- ChuckNorris89 4y ago
  Basically every smartphone ARM SoC for over 10 years now. Some Raspberry PI SoCs also had the RAM soldered on top.
rektide 4y ago
If you just want to reduce board complexity (what a hobbyost/maker/homebuilder dream that would be), there's lots of package-on-package and system-in-package offerings already! AllWinner V3s, S3. Theres a SAMA5D2 SiP. Bouffalo BL808 (featured on the Pine Ox64). There's a lot a lot more. I think there's a couple with even more memory too. Intel's Lakefield, with Foveros stacking, was an amazing chip with 1+4 cores and on chip ram. High speed too, 4266MHz, back in 2020 when that was pretty fast. This is more for MID/ultrabooks, but wow what a chip, just epic: add power and away you go. Ok not really but not dealing with routing (and procuring!) highspeed ram is very nice. Intels been doing such a good pushing interesting nice things in embedded, but the adoption has been not great. The Quark chips, powering the awesome Edison module, had nice oomph & Edison was so well integrated, such an easy to use & so featureful small Linux system... wifi & bt well well well before RPi. It would be fun to see DRAM-less computers but I more imagined them being big systems with a couple GB of sram. There's definitely potential for low end too though!
packetlost 4y ago
The Pine64 Ox64 has a Bouffalo Labs BL808 with 64MB of pSRAM for $6-8 and an MMU. It's already got sorta-working Linux build for it.
- sylware 4y ago
  I want to build my DYO usb keyboard, that including 64bits RISC-V assembly coding of the keyboard firmware. I have been lurking on the Ox64 for while but I need a few more green lights: - Is the boot rom enough to fully init the SOC? Aka, I don't need to run extra code I would need to include in my keyboard firmware on the sdcard. - The hardware programming manual misses the USB2 controller with its DMA programming. Even with some SDK example, you would need the hardware programming manual to understand properly how all that works. - I want to run my keyboard firmware directly from the sdcard slot, and that directly on the 64bits risc-v core, possible? (no 32bits risc-v core).
  - packetlost 4y ago
    The SDCard is not listed as a supported boot target, though you could almost certainly build a small bootloader that's stored in the qSPI flash and then load the rest of your code into RAM from there. I'm not the most familiar with it, but I believe all hardware init (setting clock source, initialing USB, GPIO, etc.) is handled by the flashable firmware of which there are open source SDKs for.
    - sylware 4y ago
      Then, it means I would need to flash my keyboard firmware, or a SDcard loader firmware. I guess this is a "standard" flashing protocol over usb, enabled by the right button pressed at power on (plugging the USB cable). Would I need to including the flashing support code into my keyboard/SDcard loader firmware or is it handled separately by a different piece of hardware? Any specs on the format of the firmware image, to know which core will run the real boot code? Erk... soooo many questions in the wrong news :(
      - 4y ago
LeifCarrotson 4y ago
The economics don't work out. Why would you avoid something as trivial as board routing, as cheap as $2 per gigabyte DRAM, and as performance-enhancing as having gigabytes of main memory, just to use a 128 MB on-die (or on-package) SRAM (at a price of ~$500/GB?)? The main distinction between application processors that can run Linux and microcontrollers that use onboard RAM (and often Flash) is that the former have an MMU. It's attractive to imagine that your SBC might only need something as simple as a DIP-packaged Atmega for an Arduino, and I can imagine a system-on-module - actually, saying that, I think several exist, ex. this i.MX6 device with a 148-pin quad-flat "SOM" with 512 MB of DDR3L and 512 MB of Flash: https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industrial-Grade-Linux-SBC-NAND-Version-p-4220.html https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industria... Whether you consider that Seeed branded metallic QFP (which obviously contains discrete DRAM, Flash, and an iMX6) to be a single package, while a comparably-sized piece of FR4 with a BGA package for each of the application processor, DRAM, and Flash on mezzanine or Compute-module style SODIMM edge connectors would not satisfy your desire for an embedded Linux processor with less routing complexity, I don't know. They build SOMs for people who don't want to pay for 8 layers and BGA fanout all the time. I don't think there are enough applications for embedded systems that need 128M of onboard SRAM that won't support the power budget, size, complexity, and cost of a few GB of DRAM.
- zymhan 4y ago
  > Why would you avoid something as trivial L3 cache is orders of magnitude faster than using RAM. You're talking a maximum of 50GB/s for DDR5, versus 1500GB/s for L3 cache https://en.wikipedia.org/wiki/List_of_interface_bit_rates#Dynamic_random-access_memory https://en.wikipedia.org/wiki/List_of_interface_bit_rates#Dy... https://meterpreter.org/amd-ryzen-9-7900x-benchmark-zen-4-improves-l3-cache-bandwidth-by-50-compared-to-zen-3/ https://meterpreter.org/amd-ryzen-9-7900x-benchmark-zen-4-im... It's a paradigm-shifting increase in processing speed when you don't need to hit RAM.
  - zX41ZdbW 4y ago
    + totally agree with that. There is a use case when you can improve performance by keeping compressed (LZ4) data in RAM and decompressing by small blocks that fit in cache. This is demonstrated by ClickHouse[1][2] - the whole data processing after decompression fits in cache, and compression saves the RAM bandwidth. [1] https://presentations.clickhouse.com/meetup53/optimizations/ https://presentations.clickhouse.com/meetup53/optimizations/ [2] https://github.com/ClickHouse/ClickHouse https://github.com/ClickHouse/ClickHouse
sylware 4y ago
On a "3nm" process, how much die real estate for 8GB/16GB of sram presuming we are in a fantasy world with massive dies?
- sroussey 4y ago
  No change. SRAM got almost no process improvements compared to 5nm. And 5nm had minimal compared to 7nm. So 3nm has “3nm”-class small transistors and 7nm class SRAM.
  - sylware 4y ago
    Ok, there is no change. But how much die real estate for 8GB/16GB of sram in such fantasy world?
    - wtallis 4y ago
      Going based on AMD's first generation V-Cache (TSMC 7nm), you could get 1GB of SRAM onto a die slightly larger than a top of the line NVIDIA GPU. 2GB would be too large to fab as a single die. Or you could spend several million to get a Cerebras Wafer Scale Engine 2 with 40GB of SRAM in aggregate and a ton of AI compute power all on one wafer.
      - sylware 4y ago
        ok. Then 8GB sram with a modern CPU, Zen4 for instance, is a die of ~ 9 top-of-the-line GPUs dies. And now, with 3D? ... mmmmmh... What is the size of the apple M2 die already?
daemin 4y ago
Might be worth taking a look at the announced Intel Xeon MAX chips then. I watched a video on it last night and these new server CPUs have a boatload of memory on the chip and can actually run without needing external DRAM.
redox99 4y ago
That would be incredibly inefficient. The price difference of such a 128MB L3 + 0GB DRAM, compared to let's say 128MB L3 + 2GB DRAM would be quite small, and in practice the performance would be much much higher because realistically in your 128+0 setup you'll be wasting easily half of that on the OS or libraries data that isn't actually needed at the moment, whereas having DRAM you can actually use the whole 128MB of L3 for things that need to be fast. It's also extremely niche to have a workload that requires such high CPU performance, but that it would fit including a linux OS in 128MB. Usually something like that is FPGA or DSP territory. I think what you want is a cheap ARM CPU with DRAM stacked on top of it on the same package (which exists).

diarmuidc 4y ago

There are SOCs available with the DRAM on top already. eg https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/32-bit-mpus/sip-and-som/system-in-package https://www.microchip.com/en-us/products/microcontrollers-an...

ChuckNorris89 4y ago
Basically every smartphone ARM SoC for over 10 years now. Some Raspberry PI SoCs also had the RAM soldered on top.

rektide 4y ago

If you just want to reduce board complexity (what a hobbyost/maker/homebuilder dream that would be), there's lots of package-on-package and system-in-package offerings already! AllWinner V3s, S3. Theres a SAMA5D2 SiP. Bouffalo BL808 (featured on the Pine Ox64). There's a lot a lot more. I think there's a couple with even more memory too. Intel's Lakefield, with Foveros stacking, was an amazing chip with 1+4 cores and on chip ram. High speed too, 4266MHz, back in 2020 when that was pretty fast. This is more for MID/ultrabooks, but wow what a chip, just epic: add power and away you go. Ok not really but not dealing with routing (and procuring!) highspeed ram is very nice. Intels been doing such a good pushing interesting nice things in embedded, but the adoption has been not great. The Quark chips, powering the awesome Edison module, had nice oomph & Edison was so well integrated, such an easy to use & so featureful small Linux system... wifi & bt well well well before RPi. It would be fun to see DRAM-less computers but I more imagined them being big systems with a couple GB of sram. There's definitely potential for low end too though!

packetlost 4y ago

The Pine64 Ox64 has a Bouffalo Labs BL808 with 64MB of pSRAM for $6-8 and an MMU. It's already got sorta-working Linux build for it.

sylware 4y ago
I want to build my DYO usb keyboard, that including 64bits RISC-V assembly coding of the keyboard firmware. I have been lurking on the Ox64 for while but I need a few more green lights: - Is the boot rom enough to fully init the SOC? Aka, I don't need to run extra code I would need to include in my keyboard firmware on the sdcard. - The hardware programming manual misses the USB2 controller with its DMA programming. Even with some SDK example, you would need the hardware programming manual to understand properly how all that works. - I want to run my keyboard firmware directly from the sdcard slot, and that directly on the 64bits risc-v core, possible? (no 32bits risc-v core).
- packetlost 4y ago
  The SDCard is not listed as a supported boot target, though you could almost certainly build a small bootloader that's stored in the qSPI flash and then load the rest of your code into RAM from there. I'm not the most familiar with it, but I believe all hardware init (setting clock source, initialing USB, GPIO, etc.) is handled by the flashable firmware of which there are open source SDKs for.
  - sylware 4y ago
    Then, it means I would need to flash my keyboard firmware, or a SDcard loader firmware. I guess this is a "standard" flashing protocol over usb, enabled by the right button pressed at power on (plugging the USB cable). Would I need to including the flashing support code into my keyboard/SDcard loader firmware or is it handled separately by a different piece of hardware? Any specs on the format of the firmware image, to know which core will run the real boot code? Erk... soooo many questions in the wrong news :(
    - 4y ago

LeifCarrotson 4y ago

The economics don't work out. Why would you avoid something as trivial as board routing, as cheap as $2 per gigabyte DRAM, and as performance-enhancing as having gigabytes of main memory, just to use a 128 MB on-die (or on-package) SRAM (at a price of ~$500/GB?)? The main distinction between application processors that can run Linux and microcontrollers that use onboard RAM (and often Flash) is that the former have an MMU. It's attractive to imagine that your SBC might only need something as simple as a DIP-packaged Atmega for an Arduino, and I can imagine a system-on-module - actually, saying that, I think several exist, ex. this i.MX6 device with a 148-pin quad-flat "SOM" with 512 MB of DDR3L and 512 MB of Flash: https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industrial-Grade-Linux-SBC-NAND-Version-p-4220.html https://www.seeedstudio.com/NPi-i-MX6ULL-Dev-Board-Industria... Whether you consider that Seeed branded metallic QFP (which obviously contains discrete DRAM, Flash, and an iMX6) to be a single package, while a comparably-sized piece of FR4 with a BGA package for each of the application processor, DRAM, and Flash on mezzanine or Compute-module style SODIMM edge connectors would not satisfy your desire for an embedded Linux processor with less routing complexity, I don't know. They build SOMs for people who don't want to pay for 8 layers and BGA fanout all the time. I don't think there are enough applications for embedded systems that need 128M of onboard SRAM that won't support the power budget, size, complexity, and cost of a few GB of DRAM.

zymhan 4y ago
> Why would you avoid something as trivial L3 cache is orders of magnitude faster than using RAM. You're talking a maximum of 50GB/s for DDR5, versus 1500GB/s for L3 cache https://en.wikipedia.org/wiki/List_of_interface_bit_rates#Dynamic_random-access_memory https://en.wikipedia.org/wiki/List_of_interface_bit_rates#Dy... https://meterpreter.org/amd-ryzen-9-7900x-benchmark-zen-4-improves-l3-cache-bandwidth-by-50-compared-to-zen-3/ https://meterpreter.org/amd-ryzen-9-7900x-benchmark-zen-4-im... It's a paradigm-shifting increase in processing speed when you don't need to hit RAM.
- zX41ZdbW 4y ago
  + totally agree with that. There is a use case when you can improve performance by keeping compressed (LZ4) data in RAM and decompressing by small blocks that fit in cache. This is demonstrated by ClickHouse[1][2] - the whole data processing after decompression fits in cache, and compression saves the RAM bandwidth. [1] https://presentations.clickhouse.com/meetup53/optimizations/ https://presentations.clickhouse.com/meetup53/optimizations/ [2] https://github.com/ClickHouse/ClickHouse https://github.com/ClickHouse/ClickHouse

sylware 4y ago

On a "3nm" process, how much die real estate for 8GB/16GB of sram presuming we are in a fantasy world with massive dies?

sroussey 4y ago
No change. SRAM got almost no process improvements compared to 5nm. And 5nm had minimal compared to 7nm. So 3nm has “3nm”-class small transistors and 7nm class SRAM.
- sylware 4y ago
  Ok, there is no change. But how much die real estate for 8GB/16GB of sram in such fantasy world?
  - wtallis 4y ago
    Going based on AMD's first generation V-Cache (TSMC 7nm), you could get 1GB of SRAM onto a die slightly larger than a top of the line NVIDIA GPU. 2GB would be too large to fab as a single die. Or you could spend several million to get a Cerebras Wafer Scale Engine 2 with 40GB of SRAM in aggregate and a ton of AI compute power all on one wafer.
    - sylware 4y ago
      ok. Then 8GB sram with a modern CPU, Zen4 for instance, is a die of ~ 9 top-of-the-line GPUs dies. And now, with 3D? ... mmmmmh... What is the size of the apple M2 die already?

daemin 4y ago

Might be worth taking a look at the announced Intel Xeon MAX chips then. I watched a video on it last night and these new server CPUs have a boatload of memory on the chip and can actually run without needing external DRAM.

redox99 4y ago

That would be incredibly inefficient. The price difference of such a 128MB L3 + 0GB DRAM, compared to let's say 128MB L3 + 2GB DRAM would be quite small, and in practice the performance would be much much higher because realistically in your 128+0 setup you'll be wasting easily half of that on the OS or libraries data that isn't actually needed at the moment, whereas having DRAM you can actually use the whole 128MB of L3 for things that need to be fast. It's also extremely niche to have a workload that requires such high CPU performance, but that it would fit including a linux OS in 128MB. Usually something like that is FPGA or DSP territory. I think what you want is a cheap ARM CPU with DRAM stacked on top of it on the same package (which exists).