edge-cores v0.2 — Edge32 and physical design progress

v0.2 replaces the edge-rv control core used by the v0.1 E3 system with Edge32, a four-stage RV32 processor designed for NPU control and physical timing. The public PyTorch → bare-metal C++ → Verilator flow now runs on Edge32 with the encrypted Edge E3 RTL.

What changed

• Edge32 is the new public control core. Its RV32IMF pipeline, register file, and arithmetic units replace the former RV64 scalar path.
• The E3 software and simulation flow has moved to RV32. The public edge-e3enc composition runs the hello, Tensor, and PyTorch-to-NNC examples.
• Tensor control timing more closely reflects hardware latency. The maintained 64×64×128 BF16 Tensor example measures 8,753 cycles, or 93.59% effective MAC utilization. Cycle counts have shifted slightly as the timing model improved, with little effect on this workload's utilization.

E3 whole-system resource comparison

The matched synthesis comparison is v0.1 edge-rv@e3 versus v0.2 edge32@e3. Both were synthesized with Yosys 0.67+post for Xilinx xc7, using the same options and default DSP mapping.

E3 system resource	v0.1 edge-rv@e3	v0.2 edge32@e3	Change
Total cells	284,862	191,992	−32.6%
LUT1–LUT6	171,193	109,772	−35.9%
Flip-flops	43,332	38,516	−11.1%
CARRY4	8,420	6,512	−22.7%
MUXF7 + MUXF8	21,615	12,639	−41.5%
DSP48E1	101	93	−7.9%
RAMB18E1 / RAMB36E1	32 / 38	32 / 37	0 / −1

These are FPGA synthesis resource counts, not post-route ASIC area. The comparison covers the complete E3 system, so its savings include changes beyond the RV64-to-RV32 processor replacement. The separate cached-core comparison and its methodology are documented in the Edge32 README.

Physical implementation status

Routing has been completed for the following individual modules:

Design	Routed modules
Edge32	RV32 core, mul/div, GPR, FMAC, FDIV, FSQRT, and other scalar modules
Edge E3	ACTU

Routing is in progress for DTCM, the Tensor dot8/dot16 kernels, and WLD. FPR, CMPU, and DMA have not yet been routed. Full-core global routing remains in progress; v0.2 does not claim final chip-level routing or timing signoff.

v0.2 is a step from the working RTL flow established in v0.1 toward a physical implementation, with a smaller synthesized E3 system and measured progress at the module level.

edge-cores v0.1 - PyTorch to Custom ASICs MVP

v0.1 is the first working release of edge-cores, demonstrating an end-to-end path from PyTorch models to bare-metal C++ running on custom ASIC RTL.

The goal of this release is simple: make the whole flow work.

PyTorch model
    ↓
torch.export
    ↓
NNC
    ↓
bare-metal C++
    ↓
Clang / LLVM
    ↓
RV64 ELF
    ↓
custom ASIC RTL

What's included

• End-to-end PyTorch → C++ → ASIC RTL flow
• PyTorch graph export and lowering through NNC
• Generated bare-metal C++ inference code
• Standard Clang/LLVM-based build flow
• edge-rv and edge-rv-lite control planes for custom accelerators
• Verilator-based RTL execution and verification
• Llama 3 transformer block demo
• Reduced Qwen 3.6 decoder layer demo
• Minimal PyTorch SiLU end-to-end smoke test
• C++ examples for Tensor, DMA, activation, comparison, and synchronization
• edge_intrinsic.hpp as a reference software interface between C++ and custom ASIC instructions

Bring Your Own ASIC

The included edge-e3 NPU is a working reference implementation, but it is not required.

You can connect your own accelerator to edge-rv or edge-rv-lite and expose its operations through a C++ intrinsic interface following the edge_intrinsic.hpp example.

The intended flow is:

your PyTorch model
        ↓
       NNC
        ↓
generated / handwritten C++
        ↓
your intrinsic.hpp
        ↓
your custom instructions
        ↓
your ASIC

This allows a custom ASIC to participate in the same PyTorch-to-hardware workflow without requiring a custom LLVM backend or a dedicated compiler stack.

Status

v0.1 is an early MVP.

The focus of this release is not API stability or complete model coverage. It establishes a working software and hardware integration path that can already be used to demonstrate models, write hardware-aware C++ kernels, and bring up custom accelerators.

The path works. Now you can plug in your own ASIC.

What's next — v0.2

v0.1 makes the PyTorch → C++ → ASIC path work.

For v0.2, we're taking the next step: from working RTL to physical implementation.

The current edge-rv and edge-rv-lite reference cores will be replaced by edge-32, a new RV32-based architecture designed as the foundation of the edge-cores hardware stack.

Our target for v0.2:

PyTorch
   ↓
C++
   ↓
edge-32 / custom accelerators
   ↓
RTL
   ↓
ASAP7 synthesis & place-and-route

The goal is to provide not only RTL that simulates, but a complete reference design that can go through a real ASIC implementation flow.

v0.1 makes it run.
v0.2 makes it physical.