A row stationary, sparsity aware Verilog core, released under Solderpad v2.1 with cluster, PE, and buffer counts exposed as top level parameters — measured on a Xilinx ZU19EG.
A new preprint out of FH Dortmund and the University of Duisburg-Essen puts a working, parameterizable, sparsity-aware DNN inference accelerator on the table — released as open-source hardware under the Solderpad Hardware License v2.1, with the RTL, the Python-to-RTL toolchain, and the verification harness all in one GitHub repository. The accompanying arXiv paper (2606.01450), authored by Denis Lebold and Hendrik Wöhrle, has been accepted to the ARCS 2026 proceedings and is what you actually have to work from today.
OpenEye is a hierarchical cluster-of-processing-elements architecture with a streaming dataflow. The basic unit is a 2×8 grid of clusters, each cluster holding 12 processing elements, for a default 192 PEs. Inside each cluster, the dataflow is row-stationary — the same family Chen et al. introduced in EyerissV2 (arXiv:1807.07928) — but with one important difference: OpenEye exposes the knobs EyerissV2 had to bake into a fixed fabricated ASIC as top-level Verilog parameters. You don't edit the RTL to resize the array; you set CLUSTER_COLUMNS, CLUSTER_ROWS, NUM_GLB_WGHT, NUM_GLB_PSUM, IACT_PER_PE, WGHT_PER_PE, PSUM_PER_PE, SERIAL_MACS vs. PARALLEL_MACS, and SPARSITY_EN and resynthesize. That alone changes what you can do with the design.
The compute path is INT8 activations and weights with a 20-bit partial-sum accumulator, and structural sparsity is supported on both input activations and weights — meaning zeros are skipped at the dataflow level rather than via runtime bookkeeping. The on-chip pooling block does 2×2 max-pooling, and the host interface is a 64-bit DMA with an AXI-stream-style handshake.
Two builds are checked into the OpenEye repository. OpenEye_Parallel.v is the bare compute core, written as portable ASIC-style RTL. OpenEye_FPGA.v is the ~3,050-line top-level wrapper that adds the DMA burst interfaces and BRAM buffers you need to actually deploy on a Xilinx FPGA.
The Python side takes a TFLite or Keras model, runs per-filter affine quantization, compiles each layer into DMA streams, drives the RTL simulation, and verifies the outputs against the reference. Verification is done with CocoTB, which is the practical choice if you want to keep the testbench in Python rather than SystemVerilog/UVM. From a researcher's perspective, this means a single Python script can take a small CNN all the way from a Keras model to bit-exact results in simulation.
The headline result, according to the arXiv preprint, is that routing and interconnect overhead scale near-linearly with the number of PEs as the cluster grid is enlarged — the cost you pay for adding more PEs is roughly proportional, not quadratic. Multiple cluster/PE configurations were synthesized and measured on a Xilinx ZU19EG FPGA, and the authors report favorable performance and resource trade-offs across those design points. This is the falsifiable claim the rest of the paper hangs on: a parameterizable PE array that does not fall off a cliff as you scale it.
It is worth being precise about what is and is not in the source material.
If you are an open-hardware researcher, a graduate student, or an FPGA engineer, the design gives you several concrete starting points:
OpenEye_Parallel.v](https://github.com/Learning-Chips-Lab/OpenEye) core is small enough to read end-to-end.The arXiv preprint and the GitHub repository are the source of truth, and both are public. OpenEye is a working, modifiable, parameterizable DNN accelerator for FPGAs with measured scaling results on a real device — not a whitepaper, not a roadmap, not a fabricated chip. Read the paper, clone the repo, and decide for yourself whether the dataflow choices hold up.