RISC-V

RISC-V has seen a flurry of activity over the past few years. Most RISC-V implementations have been small in-order cores. Western Digital’s SweRV and Nvidia’s RV-RISCV are good examples. But cores like those are meant for small microcontrollers, and the average consumer won’t care which core a company selects for a GPU or SSD’s microcontrollers. Flagship cores from AMD, Arm, Intel, and Qualcomm are more visible in our daily lives, and use large out-of-order execution engines to deliver high performance.

Out-of-order execution involves substantial complexity, which makes SiFive’s Performance P550 and T-HEAD’s Xuantie C910 interesting. Both feature out-of-order execution, though a quick look at headline specifications shows neither core can take on the best from AMD, Arm, Intel, or Qualcomm.

To check on RISC-V’s progress as its cores move toward higher performance targets, I’m comparing with Arm’s Cortex A73 and Intel’s Goldmont Plus. Both have comparably sized out-of-order execution engines.

Geekbench 6.4 introduces support for RISC-V Vector Extensions, boosting the performance of workloads that leverage SIMD instructions when run on RISC-V CPUs that implement RVV.

RISC-V is a relatively young and open source instruction set. So far, it has gained traction in microcontrollers and academic applications. For example, Nvidia replaced the Falcon microcontrollers found in their GPUs with RISC-V based ones. Numerous university projects have used RISC-V as well, like Berkeley’s BOOM. However, moving RISC-V into more consumer-visible, higher performance applications will be an arduous process. SiFive plays a key role in pushing RISC-V CPUs toward higher performance targets, and occupies a position analogous to that of Arm (the company). Arm and SiFive both design and license out IP blocks. The task of creating a complete chip is left to implementers.

By designing CPU blocks, both SiFive and Arm can lower the cost of entry to building higher performance designs in their respective ISA ecosystems. To make that happen within the RISC-V ecosystem though, SiFive needs to develop strong CPU cores. Here, I’ll take a look at SiFive’s P550. This core aims for “30% higher performance in less than half the area of a comparable Arm Cortex A75.”

Just as with Arm’s cores, P550’s performance will depend heavily on how it’s implemented. For this article, I’m testing the P550 as implemented in the Eswin EC7700X SoC. This SoC has a 1.4 GHz, quad core P550 cluster with 4 MB of shared cache. The EIC7700X is manufactured on TSMC’s 12nm FFC process. The SiFive Premier P550 Dev Board that hosts the SoC has 16 GB of LPDDR5-6400 memory. For context, I’ve gathered some comparison data from the Qualcomm Snapdragon 670 in a Pixel 3a. The Snapdragon 670 has a dual core Arm Cortex A75 cluster running at 2 GHz.

direct Youtube link: https://youtube.com/watch?v=4TmHSsIU1ns

cross-posted from: https://lemmy.world/post/24756689

Hello all,

I've only done very basic research on RISC-V as the DeepCompute RISC-V mobo caught my attention. For the software side, I know that support will (probably) come with time, so I can't really do much besides lament over it huh?

The main thing that caught my eye is that the DeepCompute mobo seems to only accept SD cards for storage. Is this a hard limit of RISC-V or is it just a limit of current technology (i.e. we need time to build something over RISC-V like x86_64/amd64?)?

I've also heard that Linux ran vaguely slow on RISC-V architectures, but ive only heard it as a passing comment. How true is this? Would future developments/putting in more time like for the decades behind x86_64 developments alleviate the speed issue?

Thank you all!

Finally my 6€ come back 😓 Source: https://x.com/milkv_official/status/1879799138705195303

You might get intimidated when you hear OS or kernel development, the basic functions of an OS (especially the kernel) are surprisingly simple. Even Linux, which is often cited as a huge open-source software, was only 8,413 lines in version 0.01. Today's Linux kernel is overwhelmingly large, but it started with a tiny codebase, just like your hobby project.

We'll implement basic context switching, paging, user mode, a command-line shell, a disk device driver, and file read/write operations in C. Sounds like a lot, however, it's only 1,000 lines of code!

[…]

In this book, I chose RISC-V as the target CPU because:

• The specification is simple and suitable for beginners.
• It's a trending ISA (Instruction Set Architecture) in recent years, along with x86 and Arm.
• The design decisions are well-documented throughout the spec and they are fun to read.

We will write an OS for 32-bit RISC-V. Of course you can write for 64-bit RISC-V with only a few changes. However, the wider bit width makes it slightly more complex, and the longer addresses can be tedious to read.

A team from China’s top government research academy pledged to produce this year a processor based on the open-source chip-design architecture RISC-V, as Beijing advances its semiconductor self-reliance drive amid escalating US restrictions.

The Chinese Academy of Sciences (CAS) will be able to deliver its XiangShan open-source central processing unit in 2025, wrote Bao Yungang, deputy director at the academy’s Institute of Computing Technology, in a Weibo post on Sunday.

cross-posted from: https://lemmy.bestiver.se/post/174306

Comments

cross-posted from: https://lemmy.world/post/23802973

Can it topple x86 and Arm, or is the gap too wide to close?

Finally! After weeks of work, I have successfully booted postmarketOS on both of those devices. This should hopefully make the adoption of both, RISC-V and PostmarketOS easier.

The goal of this text is to provide an overview of RISC-V Vector extension (RVV), and compare — when applicable — with widespread SIMD vector instruction sets: SSE, AVX, AVX-512, ARM Neon and SVE.

The RISC-V architecture defines four basic modes (32-bit, 32-bit for embedded systems, 64-bit, 128-bit) and several extensions. For instance, the support for single precision floating-point numbers is added by the F extension.

The vector extension is quite a huge addition. It adds 302 instructions plus four highly configurable load & store operations. The RVV instructions can be split into three groups:

• related to masks,
• integer operations,
• and floating-point operations.

When a CPU does not support floating-point instructions, it still may provide the integer subset.

RVV introduces 32 vector registers v0, ..., v31, a concept of mask (similar to AVX-512), and nine control registers.

Unlike other SIMD ISAs, RVV does not explicitly define size of vector register. It is an implementation parameter (called VLEN): the size has to be a power of two, but not greater than 216 bits. Likewise, the maximum vector element size is an implementation parameter (called ELEN, also a power of two and not less than 8 bits). For example, a 32-bit CPU might not support vectors of 64-bit values.

But generally, we may expect that a decent 64-bit CPU would support elements having 8, 16, 32 or 64-bit, interpreted as integers or floats.

Hi there! I'm still trying to build alternative OSs on the DC-ROMA PAD II and I have successfully built spacemit's u-boot but the board used in the ROMA PAD does not seem to be supported. I asked deepcomputing about it but since people might already have that config somewhere I thought I'd ask.

It looks like the upcoming Linux 6.13 cycle will be adding RISC-V support for user-space pointer masking and tagged address ABI. RISC-V pointer masking can be used for implementing memory tagging akin to the Arm Memory Tagging Extension (MTE) by way of ignoring various bits of the effective address on RISC-V platforms. Memory tagging can help with the memory safety state of user-space applications.

Spacemit advertises their K1 soc as compliant with the RVA22 but this table suggests it might not be: https://mastodon.giftedmc.com/@haui/113372897786006093

What am I missing?