PaperlayerView exact revision on arXiv

Source-linked AI summary

Low-level optimizations in high-level HDLs: Is there a benefit?

Oliver Keszocze, Tjark Petersen, Arved Friedemann, Matthias Bo Stuart

arXiv:2609.37021v1cs.AR

TL;DR

The paper investigates whether higher-level HDL abstractions add logic overhead, an issue with little measurement evidence. It implements an unsigned bit-serial MAC in Clash using different design choices and compares it with hand-written Verilog. Some Clash language and type choices have minimal area impact, while Verilog implementations use less area in practically all cases.

  • Problem

    Whether higher-level circuit abstractions add logic overhead remained a concern with little measurement evidence.

    Source: §1 · p. 1

  • Method

    The authors implement an unsigned bit-serial MAC in Clash with low-level optimizations and compare its synthesized designs with hand-written Verilog.

    Source: §1 · p. 2, §5.1 · p. 11

  • Results

    Mealy-machine versus state-monad and BitVector versus Vec choices have minimal area impact, while hand-written Verilog circuits use less area than Clash designs in practically all cases.

    Source: Variations within the Clash Designs · p. 12, Clash vs. Verilog · p. 14

  • Takeaways & Limitations

    For the investigated circuits, designers can use either Mealy-machine or state-monad descriptions and either BitVector or Vec types with little concern for synthesized circuit size.

    Source: Variations within the Clash Designs · p. 12

    The evaluation focuses on synthesized area; latency, throughput, power, and energy are also important metrics but are not assessed here.

    Source: §6 · p. 15

Abstract

from arXiv · show

This paper explores the applicability of functional programming to the design of Application-specific Integrated Circuits (ASICs). We investigate the impact of designing ASICs using high-level, abstract Hardware Description Language (HDL) features versus employing low-level optimizations on the area of the synthesized circuits. The aim is to determine whether using low-level optimizations is beneficial and, if so, whether it is worth the added implementation effort. To carry out the investigation, we implement an unsigned bit-serial multiply-accumulate (MAC) unit in 16 different configurations using the functional HDL Clash. We make use of both low-level bit-manipulation techniques as well as Clash's high-level constructs for circuit design. The experimental evaluation shows that some high-level constructs of Clash have negligible influence on the resulting circuit size, suggesting that using the full power of functional programming is a viable approach to hardware design. To evaluate the impact of the used HDL itself, we also implemented versions of the MAC in Verilog. The experiments clearly show that there seems to be an inherent overhead in using Clash compared to Verilog code written by a seasoned engineer.

1 Introduction and Related Work

The paper examines whether higher-level circuit abstractions add logic overhead, a concern for which little measurement evidence was available. It studies a small Clash MAC design with low-level optimizations and compares it with hand-written Verilog.

1 Introduction and Related Work

  • The study addresses the limited experimental evidence on whether higher abstraction adds circuit logic overhead by measuring synthesized ASIC implementations.It examines a tiny but non-trivial coprocessor described in a functional language, with and without low-level optimizations.Source: §1 · p. 1
  • Clash and related HDLs permit more flexible, abstract hardware descriptions than Verilog or VHDL, while Clash is based on Haskell and embraces functional programming.The paper distinguishes this work from high-level synthesis: it does not investigate HLS overhead relative to RTL.Source: §1 · p. 2
  • Prior work demonstrates Chisel for large SoCs, but the authors note little literature on small designs with low-level bit operations.They cite initial work on small designs and a similar study targeting FPGAs.Source: §1 · p. 2
  • The working example is an unsigned integer bit-serial multiply-accumulate unit in Clash, evaluated across abstraction levels and against hand-written Verilog.The aim is to implement the MAC as area-efficiently as possible and assess the impact of the HDL used.Source: §1 · p. 2

2 The Clash HDL

Clash uses Haskell-based functional descriptions to synthesize hardware, with finite data types and statically terminating recursion as key restrictions. The section presents Mealy-machine and state-monad approaches to sequential circuits.

2 The Clash HDL

  • Clash describes combinatorial circuits as pure functions and supports synthesis when data types are finite and recursion is statically known to terminate.Its fold construct can express a parity reduction as a logarithmic-depth XOR tree, letting designers express intent without specifying every technical detail.Source: §2 · p. 3

2.1 Mealy Machines

  • A Mealy machine combines state transition and output behavior in a function mapping current state and input to new state and output.Clash's mealy function turns that function and an initial state into a circuit; the function itself is combinatorial, so registers need not be defined manually.Source: §2.1 · p. 4

2.2 State Monad-based Hardware

  • The state-monad approach describes sequential hardware in a style that often more closely resembles the algorithm, making code easier to understand and maintain.Clash provides mealyS for this approach, which avoids explicitly passing mutable state in the described code.Source: §2.2 · pp. 4–5

3 Sequential Arithmetic

The paper describes a low-resource sequential multiplier that computes unsigned products through bit-wise operations and iterative accumulation. Its rounds process multiplier bits, while carry propagation and data advancement structure the computation.

3 Sequential Arithmetic

  • Each partial-product bit is an AND of operand bits, and a single full-adder iteratively combines it with the current product bit and incoming carry.Registers hold the factors and partial product in the low-resource implementation.Source: §3 · p. 5
  • The outer loop processes bits of Y by round, while the inner loop processes bits of X and adds each bit-wise product to the current product bit and carry.After each round, carry moves to the next product bit, which is known to be zero; the example uses X = 6 and Y = 3.Source: §3 · p. 5
  • The paper identifies the advancement of X and Y as design choices, while omitting the subsequent sequential accumulation step because it offers no further optimization potential.The data-advancement methods are discussed in the following section.Source: §3 · p. 5

4 Implementation

The implementation uses an unsigned bit-serial MAC in Clash and explores design choices spanning state modeling, data representation, counters, and product access. It tests the resulting designs using Haskell testing frameworks and simulations, with exhaustive inputs for smaller widths and random inputs for larger widths.

4 Implementation

  • The MAC accepts n- and m-bit operands and an n + m-bit accumulator value, and outputs the last product and accumulator with valid bits.The abstract multiplication iterates over multiplier and multiplicand bit positions, accumulating bit-wise products and propagating carry between rounds.Source: §4 · pp. 5–7

4.1 Mealy Machine vs. State Monad

  • State-monad modeling gives the MAC an imperative-like linear flow with implicit state, while Mealy modeling matches state-input pairs to compute next state and output.The authors posit that the state-monad approach may suit designers used to imperative languages and might shorten design cycles.Source: §4.1 · p. 7

4.2 Data Type of the Product

  • BitVector and Vec represent the product differently, but the authors expect both to reduce to the same Verilog type and produce no significant circuit difference.Vec supports arbitrary element types and a richer API, including folding operations.Source: §4.2 · pp. 7–8

4.3 Data Type of the Counters

  • Index counters use binary encoding with ⌈log2(n)⌉ bits; one-hot counters use n bits and avoid an adder but require manually implemented overflow logic.The authors expect one-hot counters to become unwieldy at larger widths.Source: §4.3 · p. 8

4.4 Accessing and Updating Data

  • Index-based product access resembles array indexing but requires multiplexing; rotation-based access uses shifted least-significant bits and makes the Clash code difficult to understand.The rotation-based method requires careful product-register rotation and resetting between rounds.Source: §4.4 · p. 9

4.5 Overview of the Designs

  • The design space contains 16 configurations combining choices of state modeling, product type, counter encoding, and product-update method.The code to generate all designs is publicly available.Source: §4.5 · p. 10

4.6 Testing the Clash Designs

  • Clash designs are tested as Haskell programs, including property-based checks that generate random inputs and validate specified properties.For n ≤ 8, all 2^(n+n) inputs are simulated; for n > 8, tests use 200 randomly generated inputs, and the tests assume the Clash compiler is bug-free.Source: §4.6 · pp. 10–11

5 Experimental Evaluation

The evaluation compares matched-interface Clash and handwritten Verilog MAC implementations. Some Clash abstractions have little area impact, while architectural choices and the HDL implementation are associated with synthesized-area differences.

5.1 Verilog Designs

  • The Verilog MAC variants matched the Clash implementations’ interface timing behavior, and simulations verified the hand-written and Clash-compiled Verilog.The hand-written Verilog variants covered indexing versus rotating and base-2 versus one-hot counters.Source: §5.1 · p. 11

5.2 Experimental Setup

  • The authors synthesized both implementations with the SkyWater 130 nm PDK and Yosys, measuring total, sequential-cell, and logic-cell area across 27 bit-widths and 16 configurations.They stopped after synthesis to avoid area changes from later physical-design steps that they considered confounding factors.Source: §5.2 · p. 11

5.3 Evaluating the Design Choices

  • Design-choice area differences were evaluated relative to the mean over all sizes and plotted as a function of bit-width.The comparison varies one design choice at a time.Source: §5.3 · p. 12
  • Mealy versus state-monad modeling and BitVector versus Vec have minimal impact on the areas of the investigated Clash circuits.The authors conclude designers can choose either approach with little concern for synthesized circuit size in these circuits.Source: Variations within the Clash Designs · p. 12, Figure 1 · p. 12

Variations within the Clash Designs

  • In Clash, indexing produces larger area than rotating registers, consistent with mux trees scaling as O(N log2(N)) versus O(1)-sized shift-control logic.The relative-area comparison is shown in Fig. 2 (left).Source: §5.3 · p. 12, Figure 2 · p. 13
  • In Clash, base-2 counters use less area than one-hot counters; their register-width difference appears in sequential cells, while indexing-versus-rotation differences reside in logic.The relative-area counter comparison is shown in Fig. 2 (right).Source: Variations within the Clash Designs · p. 13, Figure 2 · p. 13

Variations within the Verilog Designs

Clash vs. Verilog

  • Hand-written Verilog circuits have lower area than Clash implementations in practically all cases, with the largest difference for multiplexing; why the gap arises remains unresolved.The authors attribute the result to fewer or smaller standard cells in the Verilog netlists, but do not determine whether the cause is the Clash implementation or compiler.Source: Clash vs. Verilog · p. 14

6 Conclusion & Outlook

The preceding results favor hand-written Verilog on state size and logic complexity, but the study cautions against judging language benefits by synthesized area alone. Interface size and unmeasured design-flow factors qualify the practical comparison, and broader HDL and tool comparisons remain future work.

6 Conclusion & Outlook

  • Prior results indicate smaller state and lower logic complexity for hand-written Verilog than Clash; Fig. 4 marks larger Clash area with positive values.The area difference varies across four architectural variations, with the largest difference for circuits using multiplexing.Source: §6 · p. 14, Figure 4 · p. 15
  • Area is the simplest metric to extract, but latency, throughput, power, and energy also matter; opposing trends were considered highly unexpected.The study reports synthesized-netlist area across more than a thousand circuits.Source: §6 · p. 15
  • When interface size dominates a circuit’s bounding box, higher-level languages’ development agility may outweigh closer-to-optimal designs; the proposed workflow needs further evaluation.The suggested flow starts with high-level descriptions, then uses profiling and targeted low-level optimizations or re-implementations where needed.Source: §6 · p. 15
  • Future work will compare Chisel and Amaranth, assess the effort needed for hand-written Verilog to match area, and compare open-source with commercial tools.The proposed additional comparisons are not evaluated in this study.Source: §6 · p. 15
Loading 2609.37021v1…