Arbel: Building The Impossible RISC-V CPU

I spent 18 years at Intel building processors. I never thought I would assemble a great team and build a CPU from scratch using a new architecture. Arbel's creation is a story I think is worth telling, hoping it will open new horizons for the high-performance RISC-V industry.

For most of my professional life, CPUs were my world. I worked across architecture, design, and execution, and I saw up close what it takes to build a high-performance processor core. It is one of the hardest engineering challenges in computing. It requires deep architectural judgment, years of accumulated knowledge, ruthless attention to detail, and a team that has already lived through the mistakes that only real CPU teams understand.

So when I first met Elad Raz and the founders of NextSilicon, and they told me they wanted to build their own CPU cores, I didn’t immediately say, “Great idea.” I thought they were dreaming.

NextSilicon was not a CPU company. It was a young company building a new kind of accelerator, based on a novel dataflow architecture where hardware is dynamically reconfigured by software according to the workload being executed. Internally, we call this software-defined hardware. That idea became Maverick, our acceleration platform for high-performance computing and AI workloads. The ambition was already enormous.

Then Elad said something even more ambitious: acceleration alone would not be enough. If NextSilicon wanted to build the next generation of compute infrastructure, we could not only build the accelerator. We needed to control the full compute platform. CPU, accelerator, memory, networking, software, and the way all of them interact.

And for that, we needed our own processor cores.
Not a small embedded controller.
Not a “good enough” core.
A real, high-performance processor core.

At the time, I thought this was almost impossible. Not because the idea was wrong, but because I knew what it really meant. Building a competitive CPU core is not something you do with a few smart people and a clean sheet of paper. It takes domain expertise. It takes microarchitecture experience. It takes verification discipline. It takes physical design reality. It takes software enablement. It takes patience.

It also takes credibility.

The Human Challenge

Convincing great CPU engineers to join this mission was not easy. Many of them had spent years inside large processor organizations. They knew how hard this was. They knew how many companies had tried and failed. They knew that every CPU presentation looks good on slides, and that real silicon is where the truth comes out.

So the challenge was not only technical. It was human.

We had to convince people that this was not a fantasy. We had to convince them that a small, focused team, if built correctly, could do something that normally requires a much larger organization. We had to convince them that NextSilicon was not trying to build a CPU because it sounded fashionable. We were building it because our architecture demanded it.

Slowly, the right people started to join. And once they joined, the mission became clear. We were going to build the core properly.

Our first goal was practical, but not in the way people usually think about accelerators. Arbel was not a standalone CPU product. It began as an internal program driven by the needs of the Maverick platform. In HPC, workloads naturally divide between parallel and serial components. The parallel, compute-intensive portions run on Maverick’s dataflow architecture. But the serial parts, the ones that cannot be parallelized, still rely on a strong CPU. We needed high-performance RISC-V cores to handle that serial execution efficiently, while Maverick focused on parallel workloads.

That was the beginning of what became Arbel.

The first generation was not meant to impress the market. It was meant to prove to ourselves that our direction was real. It was an out-of-order, superscalar, integer-only RISC-V core integrated into the accelerator. Its purpose was to build confidence, validate the architecture, and give us a real foundation to move forward.

And it worked. It ran Linux. It ran BusyBox. It proved that the dream was not only a dream. From there, we kept going.

We added more capability. We added more sophistication. We moved from internal infrastructure toward higher performance. We continued building the core, the system around it, the validation environment, the performance model, and the software stack.

We added the pieces that a real high-performance CPU needs. Vector capability. Coherency. Stronger memory structures. Wider execution. Better system integration. We were no longer only asking whether we could build a core. We were asking whether we could build a CPU that could become an important part of the next compute platform.

Then came the next major step: the Arbel test chip.

Real Silicon - Real Impressions

This was the point where the program became much more than an internal enabler for Maverick. The test chip is a dual-core, coherent, high-performance RISC-V system running at 2.4 GHz, with PCIe Gen5, CXL, and a CHI-based network-on-chip. We integrated it with off-the-shelf CXL DDR and PCIe components for memory, disk, networking, and USB. In other words, we did not just build a chip - we built a mini PC.

A real system. Real silicon. Running Linux and Ubuntu. Supporting out-of-the-box GCC and LLVM. Running benchmarks. Running real software. Demonstrating real performance. And shown publicly, not as a rendering, not as a future promise, but as working hardware.

That matters.

The RISC-V world has seen many good presentations. It has seen many roadmaps. It has seen many bold claims. But high-performance CPU silicon is different. The moment you hold the chip in your hand, the conversation changes.

For us, that was always important. We chose to speak publicly only after we had silicon to show. Because in CPU design, slides are nice. Silicon is truth.

The test chip gave us confidence not only in functionality, but in performance. In parallel to the hardware, we built a cycle-accurate simulator for performance analysis and estimation. We correlated it against FPGA. Then we correlated it against silicon. That correlation is critical because it allows us to move from today’s test chip to the next generation with much higher confidence.

And the next generation is the Arbel server-class CPU.

When we started, Arbel was designed to support our Maverick accelerator. But the world around us changed. AI changed. HPC changed. The datacenter changed. Which made us realize that the story of Arbel became bigger than Maverick.

For years, the industry spoke as if accelerators were the entire story. GPUs, custom accelerators, matrix engines, tensor units. All of that matters. But as AI systems become more agentic, more interactive, and more complex, it is becoming obvious that acceleration alone is not enough.

We built Arbel because agentic AI changes what a CPU needs to do.

An AI agent is not just a model running a static inference pass. It calls tools. It triggers code. It retrieves information. It orchestrates services. It moves through complex workflows. It communicates across systems. It manages memory. It interacts with the operating system, the network, storage, databases, and other accelerators.

In that world, the CPU can no longer be an afterthought. It needs to run fast, respond quickly, and keep the entire system moving. It needs to feed the accelerator, coordinate the software stack, manage the unpredictable parts of the workload, and handle the control flow that becomes more important as AI systems become more autonomous.

This is one of the biggest changes in computing today.

The accelerator is still critical. But the system around the accelerator is becoming just as important. If the CPU cannot keep up, the entire platform suffers. The bottleneck moves from the math engine to orchestration, memory movement, scheduling, networking, and software execution.

Why Arbel Matters

With Arbel, we started from the workload requirements, not from the constraints of an inherited architecture. We asked what the next generation of AI and HPC systems will need from the CPU, especially when the CPU sits beside an adaptive accelerator like Maverick. We asked how to build a processor that can support both traditional datacenter workloads and the emerging needs of agentic AI.

The result is a CPU designed for the next generation of AI and HPC systems, built on an open ISA that gives customers control. The production processor will take that even further.

This is also where RISC-V became more than an interesting ISA choice.

When we started, I knew very little about RISC-V. After 18 years at Intel, I believed deeply in x86, and assumed it would remain the dominant high-performance architecture for many years. But as we studied RISC-V, the more interesting it became.

The decision was not trivial. On one hand, RISC-V gave us freedom. No dependency on a proprietary CPU roadmap. No need to wait for another company’s priorities. No licensing structure that limited what we could build. We could design the architecture we needed for our system.

On the other hand, the ecosystem was not mature. The software stack was still developing. The server specifications were still evolving. The question was not only whether we could build a RISC-V CPU. The question was whether the ecosystem would mature fast enough for RISC-V to compete seriously in high-performance computing and datacenter infrastructure. We took the risk.

Today, I believe it was the right decision.

The RISC-V ecosystem has advanced dramatically. The software stack is stronger. The specifications are maturing. The community is moving from embedded and academic discussions into serious server-class compute. And at NextSilicon, we have now built multiple generations of RISC-V silicon and a roadmap toward a full server-grade CPU.

Arbel is designed as a 64-core, server-class, high-performance CPU chiplet. It is built for datacenter requirements, including virtualization, security, reliability, debuggability, high-bandwidth IO, and modern memory configurations. It is designed for standalone servers and for systems where the CPU works together with accelerators such as Maverick.

But the most important thing is not the checklist. The most important thing is the core.

High-performance CPU cores are not created by adding features to a block diagram. They are created through thousands of detailed microarchitectural decisions. Fetch bandwidth. Branch prediction. Allocation. Execution. Memory ordering. Cache hierarchy. Load-to-use latency. Coherency. Vector and floating-point units. Verification. Timing. Power. Area. Physical implementation.

This is where domain expertise matters. Many teams can implement an ISA. Very few teams can build a high-performance CPU core properly.

In Arbel, we made several deep architectural choices that reflect that experience. We built a strong front end with high fetch capability, without relying on an expensive micro-op cache. We designed a virtual L1 cache structure that delivers low load-to-use latency while addressing the real complications of aliasing and tag management. We built an atomic L1 fill and evict pipeline that reduces hardware complexity and avoids unnecessary buffering. We designed large execution resources, strong memory operations, vector and floating-point capability, and the infrastructure required to scale.

These are not marketing features. They are the kind of details that decide whether a CPU is real, and they are exactly the details that are hard to get right unless the team has lived through CPU design before.

That is why I am proud of what this team has done. Not only because we built something ambitious, but because we built it with the discipline that high-performance CPU design requires. We started with skepticism. We moved through first silicon. We integrated cores into Maverick. We added capability. We built a coherent test chip. We ran real software. We validated performance. And now we are moving toward a server-class CPU.

Looking back, I understand why my first reaction was disbelief. It was the rational reaction. But engineering progress often begins with someone asking for something that sounds unreasonable.

Elad and the NextSilicon founders believed that the future of compute would require much more than another accelerator. They believed that hardware would need to become more adaptable, that the full platform would matter, and that the CPU would remain central to the next generation of AI and HPC infrastructure.

I joined because I wanted to see whether that dream could become real.

Today, after multiple generations of silicon, after seeing Arbel run real software, and after watching the RISC-V ecosystem come together around serious high-performance computing, I can say something very different from what I thought on day one.

The dream has become real.

And this is only the beginning.

Stay Connected

Stay tuned as we share more details in future blogs and announcements via our Nextletter.