RAVEL

RAVEL (Rate-Aware Vectorized Engine for Low-latency) generates a specialized, hls4ml-compatible FPGA inference project. Aria 1.7.0 supports one or two Conv/ReLU/Pool blocks followed by Flatten and one Dense output. It composes PHARA or a wide first-convolution stage, a qualified hls4ml channel-mixing stage when needed, lossless stream bridges, and RAVEL's packed Dense stage. New conversions default to P8/D4. P2 and P4 remain available through explicit configuration. Compatibility describes the supported geometry and architecture describes the typed planner.

The performance figures below describe the historical single-convolution reference model; they are not throughput promises for other architectures. Each sample frame contains one value from each of four 8-bit ADC channels. Each input chunk contains 256 such frames: 8,192 bits, or 1 KiB, of raw input. One PHARA core processes an estimated 40.1 Gb/s. An optimistic 16-core KU5P configuration processes 642 Gb/s, equivalent to 20.1 GSa/s on each of the four synchronous channels. The example model distinguishes in real time between neutrino signals generated by Askaryn Radiation and noise, and can detect over 99% of neutrinos at a trigger rate of 1 Hz.

Single-convolution reference performance

Like-for-like comparison

The table uses the same example model, KU5P target, and 5 ns clock constraint. Resources and WNS are single-core Vivado 2023.2 post-route results. Resource counts are followed by KU5P utilization. II means initiation interval.

The raw input chunk sized 4 x 256 x 8 bits. The single-core rate is Fmax / II * 8,192, with the corresponding unit conversion. The parallel estimate allows up to 70% of every listed KU5P resource and linearly replicates 8/28/19/21/16 cores for the five rows. LUTs limit the first four estimates; DSPs limit PHARA. These values exclude shared infrastructure, I/O limits, and multi-core routing overhead.

At 200 MHz, 1 GSa/s per channel equals 3.90625 million 256-frame chunks/s and requires 60.08/3.48/1.84/1.84/1.00 equivalent cores for vanilla/Aria 1.1/1.3/1.4/1.6. PHARA processes 1.004 GSa/s per channel per core. Relative to Aria 1.4, it reduces II by 45.7%, latency by 43.4%, and OOC LUTs by 29.4%. Registers increase by 6.0%, BRAM tiles increase from 1.5 to 2.5, and DSP use increases from 15 to 79.

At the timing-estimated 249.8 MHz, one PHARA core processes 4.898 million chunks/s. This equals 1.254 GSa/s per channel across four channels, or 40.1 Gb/s of raw input. Sixteen cores reach an estimated 20.1 GSa/s per channel and 642 Gb/s, or 80.3 GB/s, while using 36.4% of LUTs, 14.2% of registers, 69.3% of DSPs, and 8.3% of BRAM tiles.

The Aria 1.6.0 PHARA qualification snapshot records the source commit, three-model RTL CoSim results, arithmetic proofs, and canonical post-route measurements.

The throughput requirements of ARIANNA, RNO-G, and IceCube-Gen2 are already met by the current system design (AI Trigger System, v3.3.0). For models with similar architectures and size, processing speed and power consumption are no longer limiting factors.

More Information about the reference implementation, please see the performance of the CNN-Core-Generator.

Aria 1.7 multi-block qualification

The two-convolution K5/S3/F12 target passes exact C verification on the mandatory 96-sample corpus plus 1000 supplied events, RTL CoSim, and reset/backpressure protocol checks. At a 5 ns KU5P constraint, its composed P8/D4 implementation measures II 844, latency 866 cycles, and routed WNS +0.475 ns. A clean hls4ml baseline measures II 3076 and latency 3091 cycles under the same full-reset settings. The exact legacy P2/D2 model retains its previous II, latency, resources, and routed slack.

The Aria 1.7 qualification snapshot contains the measured resource tradeoff, a non-F12 two-block check, immutable source/report bindings, and reproduction commands. These results apply to those qualified models; board integration and model-accuracy evaluation are separate.

Install

Use a clean Python 3.11 virtual environment on Linux:

python -m pip install ravel-hls

Python API

import ravel_hls as ravel

config = {
    "HLS": {
        "Backend": "Vitis",
        "IOType": "io_stream",
        "Part": "xcku5p-ffvb676-2-e",
        "ClockPeriod": 5.0,
    },
    "Verification": {"Mode": "required", "Samples": 32, "Seed": 19},
    "Vitis": {"Run": False},
}

analysis = ravel.analyze("model.keras", config)
project = ravel.convert("model.keras", "cnn_core", config)
print(project.status)

Optimization is optional. Omission selects the versioned aggressive default:

config["Optimization"] = {
    "TemporalPacking": 8,  # 2, 4, or 8
    "DenseParallelism": 4,  # 1, 2, or 4
}

The supported pairs are P2/D1, P2/D2, P4/D1, P4/D2, and P8/D4. An omitted axis inherits the aggressive P8/D4 default. ravel.refresh(project, model_or_parameters) reuses the recorded architecture envelope and rejects changes that require an ordinary conversion.

Vitis.Run defaults to False. Set it to True to run vitis_hls -f build_prj.tcl after atomic project publication and automatically record the synthesis report. The default Vitis stages are reset and synthesis; CSim, CoSim, validation, export, and Vivado synthesis remain disabled unless their booleans under Vitis.Stages are enabled explicitly. The same operation can be requested later with project.build().

The concise project lifecycle is analyze, convert, refresh, Project.open(path), project.build(), project.record(report_dir), and project.link(). The CLI command ravel-hls inspect PROJECT --json performs full source-integrity checking; add --fast when payload hashing should be skipped.

Parameter packages

Parameters stores portable generation-relevant inference state without generated HLS sources or executable Python objects:

parameters = ravel.Parameters.extract(model)
parameters.save("trained.ravelparams")

project = ravel.Project.open("cnn_core")
project.refresh(ravel.Parameters.load("trained.ravelparams"))

The schema-v2 deterministic archive contains JSON plus NPY arrays compiled from the clean ModelGraph. Tensors are addressed by canonical operation and role, not Keras layer names or variable order. Structure, numeric descriptors, and layered hashes are checked before complete staged regeneration. Without embedded known-answer evidence, package refresh can prove baseline-to-optimized equivalence in auto mode but required mode rejects it. A package is not encrypted.

Other Information

See the executable CNN-for-Arianna reference, architecture, compatibility, and project format for the full contracts. The Aria 1.5.1 RTL evidence records the previous three-model subset.

Our Project used RAVEL

• CNN Core Generator
• AI Trigger System
• Hi-Lo Gated CNN Trigger
• And more!

The Future Plan

RAVEL will evolve from the closed, qualified specialization flow into a general rate-aware FPGA inference generator. Plans for higher versions are tentative.

Higher versions will focus primarily on expanding functionality and model support. At present, Nocturne 2.0 is expected to bring the target model into its highest practical throughput range. Further versions may still achieve higher throughput, but the remaining headroom is expected to be quite limited.

• Aria 1.x Continue improving the closed P2/P4/P8 specialization set, deterministic project lifecycle, verification, and tool compatibility. For this version, RAVEL's goal is simply to design an efficient converter for models currently in use or planned for use for high-energy neutrino experiments, e.g., ARIANNA, RNO-G, and IceCube-Gen2.
• Nocturne 2.x Generalize model support and derive balanced layer-level parallelism from system bandwidth and resource limits.
• Rhapsody 3.x Support multiple independent inference contexts within one IP, with configurable resource sharing, duplication.
• Requiem 4.x Select internal parallelism, IP replication, and lane scheduling according to input rate, internal interval, latency, and FPGA resource constraints.

License

This project licensed under Apache-2.0. See LICENSE.