Upgradeability of framework combined with low cost of SOC's

@Shiroudan , thanks for the reply! Although I am going to counter-argue what you said with a link to the video where I learned about UCIe. Maybe I misinterpreted what they were saying, but from what they said, what I have heard, it sounds like they’re talking about being able to replace the chiplets as, they talk about, “modular CPUs” and “building your own CPU like building a PC.” Here is the video link in question: A CPU From AMD…AND Intel?! (UCIe Explained) - YouTube

1 Like

I wanna just let you know that I am creating a new topic, and because I like the discussions going on, I will be linking this new topic here, so commenters on this topic will also have quicker access to this new topic. Here is the link: “Keyboard” modules that have controllers instead of a keyboard - Creators & Developers / Input Module - Framework Community

“modular” just means you have different parts, which you can choose from, to put together. It doesn’t always mean you can swap them after something was initially produced.
So “building your CPU like a PC” refers to the manufacturing stage, where companies can mix and match parts from different manufacturers (Intel CPU, AMD Graphics, etc.). But they still need a multi-billion dollar facility with high-tech pick-and-place stations and soldering robots, so nothing a consumer could do in his garage.

All in all, i think you have a bit of a misconception of SoC’s in general. They are pretty much the opposite of what Framework is doing with its laptops. Once a SoC is made, nothing about it can be changed, just like you can’t change the cores in a CPU after it left the factory. Putting RAM and/or storage on a tightly packed Chip with the CPU prohibits any meaningful upgradability and repairability and adds cost, if you also still want to have the corresponding slots for adding more.

(I know in theory it’s probably possible to desolder a chiplet from an AMD chip and replace it or something like that, but I think we can agree that you need pretty high end tools to do that reliably)

P.S.: I also enjoy the discussion here, but unfortunately from all I know and can tell this idea just doesn’t seem to make any sense.

2 Likes

@Schuasda, you make some very good points. And from the research I have done, everything you have said about UCIe seems to check out. I think that argument may have spelled this idea’s “fatality.” So… I guess that is probably it. I think that closes the case. This idea is proven to be a bad idea. Thanks for the discussions. I learned a lot from this.

1 Like

@Rylan_Kletnieks Sorry to burst the bubble like this :smile:
Your idea sounds cool in theory, but as I said, I’m afraid it’s not practical in reality

Nono, it’s fine. Who knows, maybe some day this idea of swapping chiplets in a custom SOC will become a reality through new standards. Probably many years from now, but it’s still possible. I think modern technology is totally capable of it. We just need a standard / protocol for it.

Contrary to you @Rylan_Kletnieks, the more I think about this, the more I think it makes sense.
I guess I’m the last holdout remaining to present the case.

Would you hypothetically pay an extra $50 for a mainboard that was exactly the same,
except in addition to all its current features,
it also has 4 GB of ram and 32 GB of storage built-in?
The answer for me is clearly a yes:

I would add two 8 GB DDR sticks (for a total of 20 GB) and whatever m.2 2280 I have available.
The smaller, soldered storage would be used for the system files and the larger, removable device for user files.

That soldered 4 GB is likely to be faster than any DDR stick that I could reasonably buy.
The theoretical maximum memory of this board is increased from 64 GB to 68,
but for most users, it would be a more significant difference of 8 → 12 or 16 → 20.
I could also forego buying any DDR sticks and recoup that added $50, and still keep the option to upgrade later.

Granted: if the RAM fails, it might bring the whole board down with it…
but that can be said of most of the components on the board,
and RAM is not (to my knowledge) a high failure-rate part.

Yes, you’re limited to currently available memory speeds,
but by the time we want to upgrade to faster memory,
it will probably also be worthwhile to upgrade the processor too.

SSDs, on the other hand, do have a high failure rate after regular use –
but unlike the memory, a dead soldered storage device doesn’t mean the death of the whole board.
An OS can be booted from the NVMe device instead, provided the BIOS is engineered to allow this.

Wear on the built-in SSD would be greatly reduced, since it would only be written to on system updates.
Separating my important user files from the OS seems desirable.
The devices would be unlikely to fail at the same time; in the event one fails, either your data is lost but your system still works, or your OS isn’t booting but your data is safe.

Yes, that’s a similar advantage that you could get from two m.2 slots, which arguably would be preferable, but that uses much more space so might just not be realistic.

Consider too the proposed re-purposes of the board.
When you upgrade your Framework laptop, what do you do with the old mainboard?
The old mainboard needs some kind of memory and storage to be useful.
Typical examples are things like TV streaming setups, Pi-holes, and other such home devices.
32 GB would be plenty of storage for many of those tasks; 4 GB might even suffice for memory.
If you don’t need to buy new components to re-use the board, you eventually spend less money in total.

@BarriBurt presents the argument that I don’t want to use 10-year old memory on my computer.
That’s true, but I don’t want a 10-year old processor either, and that’s soldered in.
It would seem a strange choice to me to upgrade the memory of an ancient CPU, even assuming it’s compatible.

The TLDR of this post is that I would happily pay somewhat more for a Framework mainboard that had all the same features as the current options and also included a small amount of RAM and storage.

I agree that it would actually be really cool to have a mainboard with a base level RAM and SSD package built in. Obvoiusly it would only be smart and useful if you could upgrade with DDR and NVME, and if it doesn’t become unuseable if the built in silicon fails. It would definitely require figuring out the best way to split the SoC and DDR RAM so that neither ruins the performance of the other, but if that can be done well this idea could be a great improvement to the original mainboard design!

No, I wouldn’t.
I used to do basic PC repair and support as a side business and I’ve had so many trashed laptops with soldered on RAM. I didn’t have the skills or equipment to replace the chips or a way to get replacements and replacement boards were almost always prohibitively expensive, so one broken ram chip equaled an entirely broken laptop.

I want none of this on my laptop mainboard, this is one of the main reasons why I bought a framework.

Maybe there is enough room in the framework 13 chassis for a second smaller m.2 ssd slot, but for me this is completely irrelevant. I can see how this might be useful, though.

I think the way the framework mainboards are made right now, is the best way.

3 Likes

Do you have a response to the counter-points already made?

Broken RAM bricking the board hardly matters if the RAM never breaks.
Besides, the current board becomes useless if the DDR slots get damaged; how is that better?

It still does not make sense. Soldered down memory has its advantages: take up less space and faster and/or more energy efficient memory. If you are not using it for any those benefits then its just a waste of time and money to engineer it that way while sacrificing the modularity.

What you find in cheap notebooks with some memory soldered down is the memory for a single channel is soldered down and the 2nd channel has the SO-DIMM. That means without any DIMM you will have severely bottlenecked memory performance (half the throughput) and dual channel only truly works when you put a very specific amount of memory in the slot (the same as already soldered down). Mixing different capacity memory will have some parts of your memory be dual-channel fast and others be single-channel slow, mixed at random. And because of it being only one channel, it will be normal DDR memory with the same speed and energy consumption as the modules, so you cannot use most of the benefits of soldered down memory (just maybe save 1 DIMM worth of space).

Then the custom engineered parts for the consoles: They use GDDR for a GPU-like, much wider memory interface (much more memory bandwidth as needed for performant GPUs). That cannot be modularized with standard sticks, because it is an entirely different architecture.

Now, technically, you could design a system with 2 separate memory controllers, one for soldered down, faster or more energy efficient memory or and one for DIMMs. But what is lacking here is a giant heap of software support. The OS is not designed to understand that distinction and will not handle this sensibly, nor will any normal software (NUMA-aware and -optimized would be the Buzzwords here). And you are actually taking up more space than before, because you have full modularity still, plus additional, soldered down memory that you cannot really exploit well, because no normal software can rely on getting the faster memory.
And if you are statically partitioning the memory, the fast part only for GPU and the slow one for the rest, look at what you have: a normal CPU+ dGPU with soldered down memory architecture.

2 Likes

Glad you guys support the idea. In regard to the whole, UCIe thing, I think it would be totally possible that some time in the next few years, UCIe might gain the ability to have hot swappable chiplets. Perhaps it could work by having the pins for the chiplets be really flat cubes that slot into little “cages”. An idea for how to keep the chiplets in place would be to magnetically lock it in place. After all, we already slot desktop CPUs into boards via pins, so for laptops, we could just shrink the pins on the chiplets. Just some thoughts on how to get the job done. Again, thanks for the discussions!