Inside this Framework 13 laptop is a special mainboard developed by DeepComputing in collaboration with Framework. It has an 8-core RISC-V processor, the ESWIN 7702X—not your typical AMD, Intel, or even Arm SoC. The full laptop version I tested costs $1119 and gets you about the performance of a Raspberry Pi.
A Pi 4—the one that came out in 2019.
But unlike the Pi 4, this eats up 25 watts of power at idle, meaning the poor battery only lasts 2-3 hours.
And it uses a bit of tech I don't remember seeing since, like... well...
This thing. From 2009.
But before we get to that, no, I'm not recommending most of you reading this even consider buying the DC-ROMA II. It's is a very niche product, meant for RISC-V developers and enthusiasts.
But I'm still excited to see it, for two reasons:
- DeepComputing decided to build a Framework Mainboard instead of a custom laptop. Meaning after the system is unsupported in two years, you can upgrade the mainboard to a modern AMD or Intel version, and get a lot more life out of the rest of the chassis.
- It has the fastest RISC-V chip I've ever tested, with 8 SiFive P550 CPU cores, which increases my hope we might get three viable CPU architectures: x86, Arm, and RISC-V. (Yes I know there are others, but x86 and Arm are ruling over the rest right now).
But no, objectively this is not a good laptop.
And if it isn't obvious, DeepComputing, who sent me this laptop, are not paying me for this post. They did provide the laptop, but have no say in my review.
Video
I have a full video of this review, if you'd like to watch. Otherwise, scroll past for the rest of the written version!
Hardware
If you've never heard of Framework, they make repairable and upgradable laptops. The Framework 13 seems to be a midrange option, and the build quality is good. It's not quite Apple-premium—especially the keyboard, which is a little mushy—but overall it's a solid laptop.
It has four expansion slots (two on each side) that you can stick in a number of modules, from USB-C ports to HDMI, SD card readers, or even Ethernet. It also has an audio headset jack (separate from the modules).
I tested USB-C modules, and got about 100 Megabytes per second for file copies, so not quite the full USB3 speed I expected, but at least it's better than USB2. I also tested an HDMI module in the top right slot, and was able to run a full external display without any issues (see photo at top of post).
The Framework's built-in display is 2.2K, with a nice 3x2 aspect ratio. Inside it has a 56 watt-hour battery, which for normal Framework 13 builds, would get you 8 or 9 hours of use.
But this isn't a review of the Framework 13—the laptop hardware itself is fine, and I'd say overall midrange.
I'll focus more on the RISC-V mainboard inside, which DeepComputing custom-built for the 8-core P550 RISC-V CPU.
If you haven't heard of RISC-V, it is an open ISA, meaning the overall chip architecture isn't tied to one or two companies' whims. RISC-V CPUs are already popular in hard drive controllers and microcontrollers, but they've had a harder time in things like SBCs, laptops, and desktops. We'll see why later.
But with the Framework, getting to the mainboard is easy, compared to most laptops. You flip over the laptop, unscrew 5 screws, flip it back over, and pull off the top cover.
(Framework even includes the only tool you need for all repairs in the box.)
The CPU resides under the cooling module, and once removed, we reveal the odd CPU:
It looks like there are two identical ESWIN EIC7702 CPU dies—the same die that's used in the single-chip HiFive Premiere P550 I tested earlier this year.
Looking at the RAM layout on the mainboard, two 8 GB chips go to one CPU, and the other chips go to the other one.
A strange architecture, but not unprecedented—I mentioned the Dell Optiplex earlier in the video. It has an Intel Core 2 Quad CPU, and it has the exact same weird architecture: Intel took two Core 2 Duo CPU dies and slapped them together on an interposer.
Those Core 2 Quad chips would burn a lot of power, and had issues with cross-die memory access being slower than accesses on the same die.
Did ESWIN solve those problems on this new RISC-V chip? Short answer: no. Before we get to benchmarks, I'll talk a little bit about Linux support.
Software
The DC-ROMA II ships with Ubuntu 24.10. Newer Ubuntu releases like 25.10 won't run on it.
RISC-V is a newer CPU architecture, and up until the past year or two, important RISC-V standards for higher-perfoming CPUs were still being formalized. The latest standard, RVA23, is the main target for a lotta Linux distros, like Ubuntu.
The P550 cores inside the ESWIN CPU don't support RVA23, so Ubuntu 24.10 be the only version that'll ever run on it!
There's also a special version of Fedora 42, but this is one of the main reasons I recommend you don't buy these first-generation RISC-V computers, unless you're really into the architecture, or you're developing software that you wanna run on RISC-V.
But assuming you're okay with all that, how is it using this as a laptop?
Well, bringing back another theme from the early 2000s, it's one of those laptops with the fan running pretty much all the time.
And it would ramp up to 100% quite often.
Why is that? Well, the power profile for this complicated dual-die chip is not efficient. The total system power draw is about 25 watts while it's sitting there doing nothing.
Other modern laptops I've tested idle between 2-10W, depending on screen brightness.
The DC-ROMA II, even with the screen turned off, is burning through the battery like crazy.
I tested battery life through a few charge cycles, and I'd say you can expect 2-3 hours, tops. So, again, this is not a laptop you should buy if you just want a decent Linux laptop. The regular Framework 13, maybe, but not the RISC-V version.
The screen looks great, but running normal applications on the RISC-V chip is sluggish. Just like an older Pi 4, you can only expect to get smooth video playback at lower resolutions, like 720p. And the UI is generally a little choppy.
It's not horrible, and it's actually the best experience I've had running a RISC-V desktop environment—but that's not saying much.
Chromium ran better than Firefox, due to GPU acceleration working in that browser. I could get 40 fps on Chromium running WebGL Aquarium versus 16-17 fps on Firefox.
SuperTuxKart was playable after I turned down all the settings, but it was only getting single-digit FPS at 1080p.
At least Doom gave me a full 60 fps at full resolution—but that game's from the 90s, so that's not surprising!
I keep comparing this to the Pi 4 though, because that was the first Arm SBC where I could use it as a desktop and not feel like it was painful—just, slow.
The biggest let-down besides the power draw was how features on this chip are still not supported.
It includes H.265 encode and decode, and a modest but decent built-in NPU, but using those things requires software support, and that was a little lacking.
They provided a demo of Deepseek R1 7B optimized for the NPU, and it was respectable, running around 5 tokens per second. But trying to get other models to run on it was difficult. If I just ran models on the CPU, I would get less than a token per second.
And even though the system comes with 32 GB of RAM, half of it is allocated to the NPU, somewhere in the firmware. So unless you use one of the few demos that runs on the NPU, that extra 16 GB is wasted.
DeepComputing did say the RAM might be able to be re-allocated, but I wasn't able to get that to happen in time for this post. So for now I guess think of this machine as having half the RAM that's advertised, if you're not using the NPU.
Performance
But having only half the RAM is only half the problem. Let me show you a few performance graphs (full testing data is stored in my sbc-reviews project, as always](https://github.com/geerlingguy/sbc-reviews/issues/82)), and we'll talk about the other half.
First up, Geekbench. It's not a perfect benchmark, but it's a good match to the overall 'feel' of a computer's UI performance, at least for these systems.
This is the fastest RISC-V computer I've ever used, but... RISC-V isn't fast. At least not with any of the chips I've tested so far.
The chip even beats the Raspberry Pi 4 (7 years old, remember) on HPL performance, but the efficiency in doing so is pretty rough:
It's less efficient than the same single chip CPU in the HiFive Premiere P550, which isn't too surprising, since you have to use more power to keep the two chips in sync all the time. But even Intel looks amazing here, with their N100 chip in that LattePanda Mu up top.
And these are far from the most efficient Arm and Intel systems I've tested. I just wanted to find some modern systems in the same ballpark, to give RISC-V the best chance possible.
The graph that really destroys this thing for a laptop, though, is this one:
25 watts at idle is a lot.
I think a large part of the reason the performance and efficiency numbers are so rough comes down to memory access. This is a measurement of core to core latency—how many nanoseconds it takes one CPU core to access memory from another core:
Cross-die memory access is over 1000 nanoseconds. That's an order of magnitude slower than memory accesses on the same die.
GitHub user @ganboing speculates:
The critical issue here is that the LLC (last-level-cache) on each die is only responsible for the memory connected to the die. It doesn't care about remote memory, and the logic on each Die is probably quite straightforward: if the address belong to myself, use my L3, otherwise, ask the remote L3. This can be further validated by the patch from ESWIN where the code checks to see which cache controller a particular cache line belongs to, and then invalidate.
Thus, you actually get the worst performance for core-to-core latency in the same die if the synchronization variables happen to reside in the remote die memory, because it has to reach out to L3 on remote die, then back. The estimated latency for this scenario is 1029 * 2 - 79 = 1979, which is pretty close to the actual number. To me this is really inefficient. I'd imagine all modern multi-socket/die CPUs to be able to cache remote socket/die memory and snoop for modifications. Here it's more like ESWIN glued together 2 P550 clusters without too much thought.
I think @ganboing is on to something, and it is also somewhat confirmed by this post on the SiFive forums—where @dconn notes core designs following the P550 should not suffer from the same problem.
Compared to Dell Optiplex 780
I wanted to see how the Dell Optiplex system with the Core 2 Quad (from 2009) stacks up against this modern ESWIN chip.
And... it's a lot better. Granted, this is a workstation CPU. But back in 2009, Intel figured out how to get two dies communicating at just over 100 nanoseconds. Apparently we've forgotten how to do that!
The almost 17-year-old computer still beats the DC-ROMA II in Geekbench. And in raw HPC computing performance. And... well, not in efficiency. At least RISC-V can take a small win here.
Benefits of Framework
Anyway, I don't want you to think I hate the DC-ROMA II. In fact, it's the opposite. I've been following RISC-V for years now, and the thing I liked most is that it's built into a Framework Mainboard form factor.
Because of that, the entire laptop chassis won't go to ewaste in a couple years once Linux isn't supported on it.
To give a proper comparison in the exact same chassis, I tested Framework's cheapest AMD Mainboard (kindly provided by Framework). It costs around $450, and a full Framework 13 with the AMD AI 340 configuration is actually cheaper than the equivalent DC-ROMA II setup.
I replaced the mainboard, and with the DC-ROMA, I had a choice of either installing it in a $40 Cooler Master case, or 3D printing my own Framework Mainboard case—which is what I did:
I re-ran all my benchmarks on the base model AMD Framework 13 build, and it absolutely slaughtered the ESWIN chip, in every metric.
In a few benchmarks, the DC-ROMA is somewhat visible on the chart at least, but the one that maybe matters most for laptop users is idle power consumption, and it's rough:
BUT, I should re-iterate, you're not buying the DC-ROMA II if you're looking at the best performance or efficiency. The thing I like is how it's a modular, future-proof chassis, because they partnered with Framework.
RP2350 GPIO Module
On the theme of modularity, one last thing I got to test on this laptop was a new module with two more RISC-V CPU cores, the RP2350 GPIO expansion module from SemiTO-V (I hope I'm pronouncing that right...). It's from a student team at Polytechnic of Turin, in Italy.
They sent over this module, which is part of their curriculum towards learning CPU architecture. This module has a Raspberry Pi RP2350, which has it's own RISC-V cores—two tiny Hazard3 CPU cores.
It doesn't accelerate the DC-ROMA, but it does add on GPIO capabilities, meaning you can do things like... well, I'm just blinking an LED on here, but you get the idea.
It's a neat little open source hardware design that was supported by DeepComputing and Framework, and I love to see these community projects, especially when they help the next generation learn about computing hardware.
The students also built a Python library, 'MCL' to make it easier to interact with the RP2350 from Python directly.
Conclusion
But the DeepComputing DC-ROMA II—or the 'AI PC' as it's labeled on the website...
Do I recommend you buy it? No. Not unless you're deeply into RISC-V or you're developing stuff and wanna test it on real RISC-V hardware.
It's not a great laptop, but it's the best RISC-V laptop I've seen. And the fastest RISC-V computer I've ever used. Which isn't saying much right now, but functional and slow is better than fast and broken—which is the state of many Arm boards I test!