PaperlayerView exact revision on arXiv

Source-linked AI summary

Quantifying the Effect of HCLs on a Fixed-Microarchitecture MXFP4 Accelerator

Daniele Passaretti, Sajjad Tamimi, Nicola Dall'Ora

arXiv:2609.18792v2cs.AR

TL;DR

Existing HCL comparisons often confound language effects with differences in design. This paper compares fixed-microarchitecture MXFP4 implementations across HCLs, SystemVerilog, and HLS; the HCLs match or undercut RTL in area, and all variants close timing. Remaining differences include back-end arithmetic lowering and a width choice that changes DSP inference.

  • Problem

    Existing comparisons either test one language across many benchmarks or many languages across heterogeneous designs, making language effects difficult to separate from design effects.

    Source: §I · p. 1

  • Method

    The study implements the same MXFP4 microarchitecture in five HCLs and hand-written SystemVerilog, includes HLS, and measures the variants on the same FPGA flow.

    Source: §I · p. 1, §II · p. 1, §III · p. 2

  • Results

    Every variant closes at 100 MHz, and the HCLs match or undercut hand-written RTL in area; remaining QoR differences reflect arithmetic lowering and width-dependent DSP inference.

    Source: §IV · p. 2

  • Takeaways & Limitations

    For a regular pipeline, language choice should follow designer background, ecosystem fit, and interface needs rather than area or timing.

    Source: §V · p. 2

    The study covers one kernel and one device, so absolute QoR numbers may change on other targets; tool maturity remains a language-specific risk.

    Source: §IV · p. 2

Abstract

from arXiv · show

Hardware Construction Languages (HCLs) aim to improve hardware design productivity while generating register-transfer-level (RTL) circuits without changing the designer's microarchitecture. However, most comparisons between HCLs are either qualitative or evaluate quality of results (QoR) across different designs, making it difficult to separate language effects from design effects. This paper compares the most widely used HCLs using the same fixed design, the OCP MXFP4 block dot product, a quantization primitive at the heart of edge Physical-AI inference, implemented as a single 12-stage, II=1 pipeline. A SystemVerilog baseline is followed by implementations in Chisel, SpinalHDL, Amaranth, Clash, Bluespec, and C++ for high-level synthesis (HLS). Every variant goes through the same flow on the same Artix-7 device set at 100 MhZ, driven by a RISC-V soft core. With the micro-architecture held constant, the comparison is clean: every variant meets timing, and the HCLs match or even undercut hand-written RTL in area. The remaining differences stem not from the algorithm but from how each back end lowers arithmetic, and from a single width choice that silently toggles DSP inference. Unlike HLS, where design decisions are limited to pragmas, the HCLs achieve comparable area and timing. Therefore, the choice comes down to ecosystem fit and interface needs rather than QoR.

I. INTRODUCTION

Prior HCL comparisons confound language and design effects, limiting guidance on language choice. This work compares fixed-microarchitecture implementations and finds no HCL area or frequency penalty over hand-written RTL.

I. INTRODUCTION

  • Existing comparisons cover one language across many benchmarks or many languages across heterogeneous designs, confounding language and design effects.The authors frame language selection, rather than whether to use an HCL, as the open question.Source: §I · p. 1
  • The experiment describes the same RTL microarchitecture bit-for-bit in five HCLs and hand-written SystemVerilog, with HLS as an upper baseline.All variants are measured after place-and-route on the same FPGA.Source: §I · p. 1
  • HCLs impose neither a frequency nor an area penalty over hand-written RTL in this study.Remaining QoR variance comes from arithmetic lowering and a width choice that changes DSP inference; HLS changes the solution and uses more flip-flops.Source: §I · p. 1

II. MXFP4 MICRO-ARCHITECTURE

The MXFP4 block dot-product accelerator quantizes pairs of 32-element blocks using a shared scale, then computes an integer dot product and casts it back to FP32. Its reference design is a 12-stage, II=1 pipeline.

II. MXFP4 MICRO-ARCHITECTURE

  • Each block contains 32 E2M1 elements sharing one E8M0 scale; together they span an approximately 12× range between nonzero magnitudes.The shared scale provides an FP32 exponent range.Source: §II · p. 1
  • The pipeline finds a shared exponent, quantizes 64 operands to E2M1, multiplies paired magnitudes, sums them in a 16-bit adder tree, and casts the dot product to FP32.Quantization uses round-to-nearest, ties-to-even.Source: §II · p. 1
  • The reference is a 12-stage, II=1 SystemVerilog pipeline that closes at 100 MHz.The full 2×32×32 = 2048-bit operand pair is presented in parallel each cycle, while control travels through a valid shift register.Source: §II · p. 1
  • For system integration, the accelerator connects to a RISC-V soft core through a thin GPIO wrapper that is identical across variants and excluded from QoR.The passage identifies the core as MicroBlaze MCS V.Source: §II · p. 1

III. IMPLEMENTATIONS AND METHODOLOGY

The implementations use a shared core and FPGA flow so post-route QoR is compared under common conditions. The reported core metrics exclude the identical wrapper overhead.

III. IMPLEMENTATIONS AND METHODOLOGY

  • The comparison covers seven MXFP4 dot-product variants and their post-route QoR.The table caption identifies its scope but does not provide cell values.Source: Table I · p. 2
  • SLoC counts pipeline-description source lines, excluding short elaboration drivers; the SystemVerilog data path is hand-written.The passage marks HLS separately.Source: §III · p. 2
  • The HLS figures use standalone Vitis IP with a streaming interface and are not directly comparable to the parallel pipeline.Source: §III · p. 2
  • Each backend emits the same MXFP4Top core, wrapped identically and placed on the same xc7a100tcsg324-1 FPGA under a 100 MHz constraint.The flow uses Vivado 2025.1; reported metrics are post-route core utilization and timing.Source: §III · p. 2

IV. RESULTS AND DISCUSSION

Across the measured variants, HCLs match or undercut hand-written RTL in area, and every implementation closes timing. Differences reflect arithmetic lowering and width choices, while HLS trades additional flip-flops for a streaming interface.

IV. RESULTS AND DISCUSSION

  • Every variant closes at 100 MHz with positive slack, and Fmax remains within 101–103 MHz; SystemVerilog has the highest LUT count at 11.0k, while every HCL matches or undercuts its area.The design is area-bound, and Clash and Bluespec are the smallest variants.Source: §IV · p. 2
  • A decoded E2M1 width of 16 bits makes Clash and Bluespec infer 16×16 DSP multipliers, while 6-bit declarations keep the other variants' products in LUT and CARRY logic.The hand-written RTL also forces the products into fabric.Source: §IV · p. 2
  • HLS uses about 11.1k flip-flops—three times the pipelined variants—and the most LUTs, while providing a streaming interface through FIFO-based DATAFLOW processes.The HCL variants use 1096 SRLs because their reset-less registers pack into SRLs.Source: §IV · p. 2
  • The comparison covers one kernel and one device, so absolute QoR numbers may change on other targets; tool maturity remains a language-specific risk.The study also notes there is no common normalization path between languages.Source: §IV · p. 2

V. CONCLUSION

On a regular pipeline, HCLs match hand-written RTL quality of results with far less code, so language choice should follow ecosystem fit and interface needs rather than area or timing.

V. CONCLUSION

  • On a regular pipeline, HCLs deliver hand-written RTL quality of results with far less code; remaining differences reflect arithmetic lowering and low-level typing, not the algorithm.The comparison uses a controlled, single-kernel experiment.Source: §V · p. 2
  • Because QoR does not separate languages on a regular pipeline, choose based on designer background, ecosystem fit, and interface needs rather than area or timing.The paper names Chisel for the RISC-V ecosystem and SpinalHDL for native streaming and bus interfaces.Source: §V · p. 2
  • The authors plan to extend the study to control-bound and memory-bound kernels, more devices, and an ASIC flow.These extensions would test whether the results depend on the application and hardware.Source: §V · p. 2
Loading 2609.18792v2…