ATLAS closes the gap between writing a neural network in PyTorch and running it on an FPGA with custom DL-optimized hardblocks. Today, realizing the performance of in-fabric GEMM accelerators requires knowing the hardblock microarchitecture, writing manual RTL instantiation code, and managing tiling and control logic by hand. ATLAS replaces that with a two-part compiler: hls4ml-GEMM transforms DL layers into HLS C using GEMM as a universal abstraction, and a backend maps that representation to the custom RTL IP without the model author touching any of it.
The mechanism is a GEMM-centric intermediate representation. Because GEMM dominates DL compute, using it as the universal abstraction lets the compiler map any supported layer to any compatible hardblock without the programmer knowing the hardblock interface. Prior work showed blackbox HLS mechanisms could target custom hardblocks, but still required explicit function calls in user-written C code and manual IP library creation per layer. ATLAS removes that per-layer burden by making the compiler own the mapping entirely.
The constraint being removed is not the compilation step. It is FPGA DL inference requiring joint expertise in ML modeling and RTL engineering on the same team. ML teams deploying inference on FPGAs currently need either an FPGA engineer to handle the hardblock layer or a vendor tool that already supports their specific silicon. If ATLAS generalizes to production-scale FPGAs and a wider hardblock ecosystem, that dependency and its iteration overhead go away. FPGA silicon vendors who sell DL-optimized hardblocks as a differentiation story should watch this closely: a programming model that lets ML engineers target the silicon directly compresses their addressable design team from "teams with FPGA expertise" to "teams with a PyTorch model."