Open Source accelerator chips and how RISC-V plays a role (COSCUP 2026 draft)

NOTE: This artical reads like evangelism because it is. It is how I belive cores and hardware should be built. And partially why I joined Nekko in the 1st place.

This is another talk I am giving at COSCUP this year. :sigh:.. I am late making the drafts again, let alone the slides. Rush job, but what I must do is what I must.

Esperanto was a company that originally tried to make a RISC-V based GPU. It later pivoted to a RISC-V AI accelerator, primarily aimed at CNN inference, named ET-SoC-1. The company closed in late 2025, AiNekko bought its IP, and the RTL was released through the OpenHW Group as CORE-ET.

ET-SoC-1 is the actual chip; CORE-ET is the OpenHW project containing the released Esperanto RTL.

A sea of small programmable machines

At the center of ET-SoC-1 is the Minion core. It combines an RV64IMF CPU with a custom vector matrix unit. The design was created before even the now infamous RVV 0.7, so this is Esperanto's own vector ISA rather than RVV.

One Minion is not the interesting part. The ET-SoC-1 contains a massive sea of these cores with supporting NoC and memory subsystems. With the intention of supporting both SPMD and MIMD programming.. Personally I describe it as Xeon Phi done right. And does program like so.

Rather than making one giant CPU and attaching a matrix engine to it, Esperanto built a processor from many smaller cores, each sitting next to specialized compute. You Convolution, matrix multiplication or other kernels can use the vector and matrix units, while control flow, address calculation, synchronization and awkward operations run on the scalar RISC-V pipeline. An algorithm can change without necessarily making the chip useless; another program can arrange the same hardware differently.

A programmable accelerator needs far more than RTL. Someone has to make it programmable.

Congratulations, you invented a software ecosystem

A beautiful accelerator idea comes with exactly the operations it should perform, how data should move through the machine, and how it not waste enerty compared to a CPU or GPU for its intended workload. Designing a tiny custom instruction set around it is tempting. Students make CPUs in university courses, and there are coding agents now. Ask one to write some Verilog and an LLVM backend. Problem solved!

No. Absolutely not.

Getting some RTL to run instructions is easy. Getting a usable computer out of it is not.

Once you invent an ISA, you need an assembler and disassembler (good luck programming in binaries). You need linker support (even if static linking), an ABI defining registers, function calls, stack layout and data types. Compiler code gen, proper instruction scheduling and register allocation that understand the machine. Let alone a debugger and getting some samblance of the C standard library working.

.... and maintain them across time.

Writing a compiler backend is not the end. A compiler that emits legal instructions but produces terrible code is not very useful for an accelerator. Optimization is where years disappear, if you ever aim to support the usual diverse set of kernels you'd run. Otherwise you'd be writing in assembly. Codegen bugs are also incredibly annoying to identify: source looks correct, the compiler accepts it, and it fails for not good reason.

I have even seen people modifing LCC and add a backend for their architecture. That worked as well as you'd think it does.. LCC being LCC.. not very. Often turning the accelerator into a decelerator and pratically forcing writing non-control code in assembly.

You can invent your own SIMD ISA too. IMO that is very ill-adviced and writing a vectorization pass is a huge amount of work, despite now AI can generate code for you. Often instructions look elegant in an architecture diagram and become miserable when a compiler has to compose them into real programs. Operands do not fit, register constraints fight each other, implicit states, corner cases do not compose, and a theoretically powerful operation spends most of its time moving data into the exact register and layout it demands.

And that's only the first item in your bill. The programming model will be paid for the lifetime of the product, by its developers and eventually its users.

The CPU core is not the accelerator

None of this makes the accelerator valuable. An AI accelerator's advantage comes from the matrix machinery, data movement, memory hierarchy, numerical formats and the way those pieces fit the workload. For a network accelerator, it comes from packet processing and moving data efficiently. For a video accelerator, it comes from codecs and image-processing pipelines.

The competitive advantage is not another implementation of integer addition, a function call or a load from memory. We figured out how to optimize branches and loops a long time ago. You can build increasingly elaborate state machines for all of that, but at some point you just redesigned an OoO pipeline or a VLIW.

Integrating a CPU core into an accelerator

Putting a CPU core inside an accelerator is where things get weird. Maybe you want a tightly coupled scratchpad instead of the usual cache hierarchy. Maybe the matrix unit needs another way into the register file, or the core needs a coprocessor interface, unusual interrupts, or no MMU because virtual memory makes absolutely no sense inside that part of the chip. A management core sitting across an interconnect can remain a mostly normal CPU. One placed inside every processing element rather quickly stops being normal.

Commercial IP works when the vendor already has the configuration you need. You get documentation, characterized memories, integration support and far more verification than you want to do yourself. Otherwise you browse the product catalogue, negotiate over what can be changed and eventually discover that the core was designed to sit beside your accelerator rather than participate in it.

With source RTL I can at least make the bad decision myself.

Now the modified core is my problem. Plenty of open-source RTL has never left an FPGA, passed serious verification or worked outside the exact configuration its author tested. Some repositories have a testbench, singular, and great confidence. Timing closure, DFT and safety requirements do not appear because a licence says "open source". If I choose the wrong core, I get to discover all of that personally.

CORE-ET is interesting because it is very far from a clean teaching core. It is a large piece of RTL made for an actual commercial many-core accelerator, with all of Esperanto's rather specific decisions buried in it.

And no, the repository is not a chip you can send to a foundry. ET-SoC-1 depended on process-specific SRAMs, a NoC implementation, clocking, DFT, physical design and knowledge which cannot be reconstructed from synthesizable RTL. The code just gives you the core and a verified, well designed compute primitive (see my upstreamed llama.cpp backend for how it is used).

RISC-V is good enough

Modifying the CPU core does not remove the need to compile software for it. This is the less exciting part of why RISC-V is involved.

GCC, LLVM, binutils and GDB already speaks RISC-V. There is already an ABI telling me which registers survive a function call, what the stack looks like and how object files fit together. I can compile ordinary C, C++ or Rust code before teaching the compiler that my wonderful matrix unit even exists.

RISC-V provides a boring scalar programming model without having to ask an architecture owner for permission. I still hate RVV and compressed instructions. Committees will do whatever committees want. Thankfully putting an RV64IMF core in an accelerator does not obligate me to collect every extension like Pokemon.

Which gets us back to ET-SoC-1. Esperanto put the ordinary control flow and scalar operations in RV64IMF, then built its own vector and matrix operations beside it. The compiler and library still had to understand those operations -- there is no escaping custom software for custom hardware -- but it did not also need Esperanto's pristine interpretation of integer addition, memory addressing and function calls.

A sea of programmable cores consumes area and power. It is still the right design choice when the accelerator has to do more than one fixed operation.

Esperanto first aimed at a GPU, pivoted towards AI and eventually closed. Good chip architecture alone does not make a successful product. But the way to build new accelerators is clear: get RISC-V, get a validated working design, glue on the units needed for your workload and done!

And now we can look at the one Esperanto made. And learn what made the chip good, and bad. All from the lowest level.