In the future even your RAM will have firmware; and the subject of POWER10 blobs

Yeah, you would think so. But it really hasn't improved all that much over the years. (Of course, that's partially because it's hard to do!).

Roughly speaking, when I designed with DRAM in 1983, the access time from RAS was 150 ns for the most popular parts. Now, with DDR4, you're talking CAS latency of about 10 ns, an improvement of 15x.

In the same timeframe CPU clock rate increased from about 10 MHz to about 3000 MHz, an improvement of 300x.

I grok your comment about perhaps having two levels of DRAM, but the whole memory hierarchy thing is already crazy. Most computers already have 3 levels of cache ahead of the DRAM.

IIRC, Rambus RDRAM was also serial, or at least less parallel than conventional DRAM.

It's also $3000 per TB, triple the price of DDR4, and not much faster.

As I understand it, the switch to serial and point to point are because of three things.

a) pin/wire count reduction --- you can't have a small chip that uses a pc parallel port, cause it needs a lot of leads, etc.

b) bus termination gets weird with potentially variable reflection and distortion at high speed

c) clock skew is hard to manage on wide busses at high speed. You gotta make sure all the leads are the same length and/or add compensation logic, and it's a lot harder than a serial connection which might have a clock right next to the data line, or might be self-clocking, so the data line includes the clock signal and it can't be out of sync.

About the only parallel bus left in modern computers is RAM. Rambus was a disaster, and probably soured the industry on a serial ram interface for some time. Note though that a RAM channel now usually has a max of two slots, but boards with only one slot per channel are common too; 4 slots per channel was common many years ago, when speeds were slower.

You had SPI, which has a clock and data pin. That got faster and faster. Then there was QSPI (quad SPI) with four data pins, so you could shovel more data per clock, e.g. when loading an initial FPGA configuration, or when a fast CPU wanted to XIP from external flash.

Now apparently there's Octal SPI? Which is... arguably a parallel bus!

DRAM consumes less power than SRAM. Far less. My understanding is, that simply changing the parameters of DDR4 towards lower latency would yield better results.

I suspect it's because the trade-off for the increased performance would be more than just the price, and that's not even considering the CPU changes and motherboard design necessary to implement SRAM main memory - no CPU maker is going to go to the expense of a separate production line just for enthusiast CPUs that support SRAM core memory.

SRAM density is significantly lower (cells/mm^2) then DRAM, because a DRAM cell can by implemented as a single capacitor, where a SRAM cell is six MOSFETs. So very generally speaking the amount of SRAM you can pack into a chip is about 1/6 (or fewer) the amount of DRAM cells in the same space.

Given that modern CPUs typically have only four DIMM slots populated in pairs and you can't add more without changing the memory interface, that means you've cut the total amount of memory possible in a system by about 80%, so max 6.4GB instead of 32GB.

So.. a memory type for "enthusiasts" that costs e.g. 5x as much as DIMMS, only allows you 20% of the memory size, and also needs a motherboard and CPU design that's incompatible with DIMM based motherboards. Not attractive to too many people.

If you want an easier way to make an enthusiast product with the performance benefits of SRAM, just put the memory on die on a multi-chip module so it's a very short distance from the processor cores (like Apple's M1). Short distance equals good signal integrity, low latency, and on die means simpler motherboard design. The trade off is that you can't add memory later, you have to buy a whole new chip.

I wonder how I could have missed that issue with the Librem 5 till now.

I've personally created a BSP and did board bring-up on a platform based on the NXP LS1046A (one of their ARM based QorIQ SoCs). That chip uses DDR4 and didn't require any blobs (aside from the Ethernet hardware). All of the memory controller registers were fully documented too. The DDR4 controller there was very similar to the DDR3 controller on their older T2080 PPC chip that I've worked with.

In fact, one of the most annoying parts of the board bring up was determining what data strobe delay values to use via a process of trial and error.

I'm not sure why NXP would use a different DDR4 controller for the iMX that requires a blob while their other chips don't.

https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-i...

I don't know whether RK3399 uses Synopsys. There are other DDR4 PHY IP providers, like Cadence, which don't require firmware.

I suspect it's not a more popular scheme because it makes it hard to pipeline your activity if there's unpredictable timing somewhere.

[1] - https://www.computeexpresslink.org/post/the-benefits-of-seri...