Parameterized Hardware Design with Latency-Abstract Interfaces

Rachit Nigam, Ethan Gabizon, Edmund Lam, Carolyn Zech, Jonathan Balkind and Adrian Sampson

When a hardware designer plugs a machine-generated module — say a floating-point adder from a core generator — into their chip, they face a bad choice — wire it up assuming its exact timing (fast, but the whole design breaks every time the generator changes that timing) or wrap it in a self-timed handshake (robust, but the handshake logic wastes chip area and slows the clock); this paper (Cornell, MIT, UC Santa Barbara) introduces latency-abstract interfaces, which get both — the module's timing is left as a compile-time unknown the generator fills in later, and a new language, Lilac, whose type system lets a child module report its timing back up to its parent and guarantees every configuration produces a hazard-free circuit, compiling the abstraction away into efficient fixed-timing hardware that uses 26 to 33 percent less area than the handshake version.

The argument in one glance

Problem

Plugging in a generated module forces a bad choice between fast and robust

Hardware designers increasingly build chips out of machine-generated modules — a floating-point adder from a core generator, a datapath from high-level synthesis, a block from an accelerator language. To wire such a module into the rest of the design, they need to know its interface, and in particular its timing: how many cycles it takes and how often it can accept new inputs. Two options exist. A latency-sensitive interface assumes the module's exact, fixed timing, which is efficient because everything just synchronizes on the shared clock — but it hard-codes that timing into the surrounding logic, so the moment the generator produces a module with different timing (because the designer asked for higher frequency, more precision, or a different chip), the whole design must be manually re-plumbed. A latency-insensitive interface instead wraps the module in a self-timed handshake so it can be swapped freely — but that handshake is pure overhead when the timing was actually fixed, wasting chip area and slowing the clock.
What people did

Wrap generated modules in a latency-insensitive handshake

The common practice is to give every generated module a latency-insensitive interface: a ready-valid handshake, with valid and ready signals, a small state machine to orchestrate them, and buffers to hold data in flight. Then when the generator changes the module's timing, only the local wrapper changes and the rest of the design is untouched.
Why it fell short

That handshake is pure overhead when the timing was never input-dependent

Latency-insensitive interfaces are genuinely necessary when a module's latency depends on its input, like a memory hierarchy. But a generated arithmetic module's latency is fixed once generated — it does not vary at runtime — so the handshake is solving a problem that does not exist, purely to tolerate timing the generator might change at design time. That decoupling is expensive: the paper measures the handshake needing three to four times more registers, roughly thirty percent more logic, and a fifth to a quarter lower clock frequency than the fixed-timing version, and on fast designs the handshake logic itself becomes the critical path. In a fully integrated design, this latency-insensitive overhead is pure waste.
This paper's idea

Make timing a compile-time unknown the generator fills in

The paper introduces latency-abstract interfaces: the module's timing is left abstract at design time — the designer writes code that works for any latency — but is resolved to a concrete, efficient fixed-timing interface when the generator is actually run during compilation. This needs two new things. Output parameters let a child module report a value, like its latency, back up to its parent, inverting the usual parent-to-child parameter flow so the generator can tell the design its timing. And Lilac, a new hardware language, uses a type system that tracks how parameters affect timing and formally guarantees that every configuration compiles to a circuit with no structural hazards — so the abstraction is safe and compiles away to efficient hardware.

Why this problem is worth solving

The whole difficulty lives in a two-way classification of how hardware modules keep time.

A hardware interface describes not just the widths of a module’s ports but its temporal behavior: how many cycles it takes to produce an output and how often it can accept a new input. A latency-sensitive interface states this timing as a fixed, input-independent fact — for instance, a four-cycle multiplier that can take a new input every other cycle — and modules connected this way simply synchronize using the shared clock, so it is efficient and adds no extra logic. A latency-insensitive interface instead carries explicit synchronization signals, classically a ready-valid handshake: the producer raises a valid signal when its data is meaningful, the consumer raises a ready signal when it can accept data, and a transaction happens when both are high in the same cycle. This lets modules whose latency genuinely varies with their input — a memory that may hit or miss — coordinate correctly. But the handshake costs real hardware: the extra signals, the state machines that drive them, and the buffers that hold data in flight all consume chip area and can lengthen the critical path. So the two interface styles trade efficiency against flexibility, and choosing wrongly means either brittleness or waste.

The reason designers so often choose the wasteful option is a mismatch between who knows the timing and who needs it.

Modern chips are increasingly assembled from modules produced by generators: floating-point core generators, high-level synthesis tools that compile a high-level description to hardware, and domain-specific accelerator languages. These generators decide a module’s timing based on their own inputs — asking a floating-point generator for a higher target frequency or a wider precision can change the resulting module’s latency and pipeline depth in ways the designer cannot predict without running the tool. A latency-sensitive interface would be efficient, but it forces the surrounding design to hard-code the generated module’s specific latency, so any change to the generator’s configuration means manually inspecting the new output and cascading the timing change through the design’s control logic — brittle and error-prone. Faced with that, designers reach for a latency-insensitive handshake purely to decouple from timing that is not actually input-dependent, only generator-dependent. They pay runtime overhead to solve a design-time problem, which is exactly the inefficiency latency-abstract interfaces aim to eliminate.

What people did before, and where it broke

Latency-sensitive integration with hard-coded timing. Run the generator, read off the module’s latency, and build the surrounding logic around that exact timing — for example inserting shift registers to delay one path so a pipeline stays balanced. Where it broke. It is efficient but brittle: any change the generator makes to the module’s timing forces invasive manual changes to the balancing and control logic, and it is not portable across chips or performance targets.
Latency-insensitive wrappers around every generated module. Give each module a ready-valid handshake so the rest of the design is decoupled from its timing. Where it broke. When the timing was never input-dependent, the handshake is pure overhead — three to four times the registers, about thirty percent more logic, and a fifth to a quarter lower frequency in the paper’s measurements — and it can become the critical path.
Top-down parameterization in mainstream languages. Parameterize the design by passing the generated module’s latency down from the parent, plumbing it through the hierarchy to size the balancing logic. Where it broke. Parameters in mainstream hardware languages only flow parent-to-child, but the generator, not the parent, determines the timing, so expressing this requires threading the latency awkwardly through every level and gives no clean encapsulation.
Trust the designer to keep parameterized timing correct. Write the parameterized balancing and scheduling logic by hand and hope it stays correct across configurations. Where it broke. Reasoning about how each parameter influences timing is subtle, and an off-by-one in the pipeline balancing causes a structural hazard — two operations colliding on one resource — that mainstream languages cannot catch, so bugs surface only in specific configurations.
The gap. No language let a designer write a module whose generated child’s timing is abstract at design time, have the child report that timing back up, and statically guarantee that every possible configuration compiles to a hazard-free, efficient fixed-timing circuit. That combination — flexibility at design time, efficiency at run time, with a correctness guarantee — is what Lilac provides.

How Lilac works

From a latency-abstract design to a checked, efficient circuit

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Make timing abstract at design time and concrete at compile time. The false dilemma is that a designer must commit, while writing the code, either to a fixed latency (efficient but brittle) or to a self-timed handshake (flexible but wasteful). Latency-abstract interfaces dissolve it by moving the decision in time: the design is written to work for any latency, treating the generated module’s timing as an unknown, and that unknown is filled in with a concrete value only when the generator actually runs during compilation, at which point the design lowers to an efficient fixed-timing circuit. So the flexibility is paid for once, at design time, and none of it survives into the hardware. Turning what looks like a runtime interface into a compile-time abstraction that erases itself, keeping the clean decoupling of a self-timed interface without its hardware cost, is the same spirit the latency-insensitive hardware-description work covered elsewhere on this site pursues, treating timing as something to be reasoned about and abstracted rather than paid for in gates on every connection.

Let the child report its timing upward with output parameters. The obstacle in existing languages is that parameters only flow downward, from a parent to the child it instantiates, but here it is the generated child that knows the timing and the parent that must adapt — the information flows the wrong way. Lilac adds output parameters, a compile-time construct by which a child module returns a value, such as its latency, back up to its parent, where the parent may not assume anything about it beyond stated constraints (at least one cycle, say). This inverted flow is exactly what lets the surrounding design schedule its multiplexers and size its pipeline-balancing shift registers in terms of a latency the generator will only reveal later. Introducing a mechanism for a lower-level component to hand structured information back up to the code that uses it, so the composition is encapsulated rather than manually threaded, is a small language idea with outsized leverage. Giving generated hardware a clean way to be integrated regardless of the exact form the generator produces is the same portability goal the high-level-synthesis work covered elsewhere on this site pursues, producing hardware modules that slot into a surrounding design without bespoke, per-configuration rework, and it is what makes the whole latency-abstract style expressible at all.

Guarantee, by typing, that every configuration is hazard-free. Abstraction over timing would be dangerous if it let subtle bugs slip through: get the pipeline balancing wrong and two operations collide on the same hardware resource in the same cycle, a structural hazard that may appear only for particular latencies. Lilac prevents this with a type system, built on timeline types, that statically tracks how each parameter influences the timing of every signal and, discharging its constraints with a solver, proves that no parameterization can produce a structural hazard or a resource-reuse violation. A design that would misbehave for some generated latency is rejected at compile time with an error, not shipped as a latent bug. Backing a flexible hardware construction with a static, machine-checked guarantee that every instance is well-formed is the same correct-by-construction discipline the formally-verified dataflow-circuit work covered elsewhere on this site is built on, insisting that the flexibility never comes at the price of a silently broken circuit.

Following an FPU through Lilac

Integrating a generated adder and multiplier of unknown latency

A trace, from the paper, of building a floating-point unit whose adder and multiplier come from the FloPoCo generator, whose latencies are unknown until the generator runs.

Step 1 of 5

Declare the generated modules with latency-abstract interfaces

The FPU instantiates a FloPoCo adder and multiplier. Each has an input parameter for bitwidth (as usual) and, crucially, an output parameter for its latency — abstract now, constrained to be at least one cycle, and to be resolved when FloPoCo runs. The interface also declares an event and the availability of its inputs and output in timeline types.

The designer writes code that must work for whatever latencies FloPoCo eventually produces.

Why it works

Abstracting timing at design time costs nothing at run time. Committing to fixed timing is brittle and a handshake is wasteful → but leaving timing abstract until the generator runs, then lowering to fixed timing, gives design-time flexibility with run-time efficiency → so the same design adapts to any generated latency yet ships as an efficient circuit with no handshake overhead.
Output parameters carry the timing the right direction. Mainstream parameters flow parent-to-child, but the generator determines the timing → but output parameters let the child report its latency up to the parent → so the surrounding design can schedule and balance around a latency it does not know when it is written, cleanly encapsulated.
Timeline types make the schedule statically knowable. Balancing a pipeline correctly requires knowing which cycle every signal is available → but timeline types state each signal’s availability relative to an event → so the compiler can compute the exact schedule and reason about it for every parameterization.
The type system turns hazards into compile errors. A pipeline-balancing bug is a structural hazard that may appear only for some latencies → but the type system proves, with a solver, that no parameterization collides on a resource → so a broken configuration is rejected at compile time instead of shipping as a latent bug.
Erasing the abstraction beats the handshake on real metrics. A latency-insensitive interface pays for signals, state machines, and buffers in every connection → but latency-abstract designs compile that away to fixed timing → so the paper measures 26 to 33 percent fewer resources and 6.8 percent higher frequency than the latency-insensitive equivalent.

What it costs (trade-offs and scope)

It applies where timing is generator-dependent, not input-dependent. Latency-abstract interfaces replace the convenience use of latency-insensitive interfaces — decoupling from timing a generator might change. They do not replace latency-insensitive interfaces where they are truly required, namely modules whose latency depends on their runtime input, like a memory hierarchy; those still need real handshakes.
The designer must still reason about parameterized timing. The approach inherits the difficulty of parameterized hardware design: the user writes balancing and scheduling logic in terms of abstract latencies and must think about how parameters influence timing. Lilac catches errors at compile time, which is a large help, but the mental model is more involved than hard-coding one latency.
It requires a new language and its type system. Using this means adopting Lilac and its timeline-type-based type system rather than a mainstream hardware description language; the guarantees come from that type system and from a solver discharging its constraints, so the benefits are tied to expressing designs in Lilac and to the solver handling the constraints that arise.
Correctness is structural, within its model. The formal guarantee is the absence of structural hazards and resource-reuse violations for every parameterization; it is a statement about timing and resource safety in Lilac’s model, not a proof of full functional correctness of the generated modules themselves, whose behavior is trusted as given.
Evaluation is on integrated generator-based designs. The reported gains come from implementing parameterized designs and integrating modules from real generators (a floating-point core generator, vendor IP, an accelerator language) and comparing against latency-insensitive equivalents; the 26-to-33-percent resource and 6.8-percent frequency figures are for these designs, and the benefit will vary with how much of a design is fine-grained integration where handshake overhead dominates.

The evaluation

Integrating a generated module three ways

Property	Hard-coded latency-sensitive	Latency-insensitive wrapper
Adapts when the generator changes timing
Hardware overhead
Correctness across configurations
How the child reports its timing		Hidden by the handshake
Measured versus latency-insensitive	Efficient but brittle

From the paper's evaluation. Latency-abstract designs in Lilac match the flexibility of latency-insensitive interfaces at design time while compiling to efficient fixed-timing hardware, using 26 to 33 percent fewer chip resources and achieving 6.8 percent higher maximum frequency than comparable latency-insensitive implementations across designs integrating real generators.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

The contribution is a clean resolution of a real, everyday dilemma in hardware design: whether to hard-code a generated module’s timing (efficient but brittle) or wrap it in a self-timed handshake (flexible but wasteful). Latency-abstract interfaces give both by moving timing to a compile-time abstraction, enabled by two ideas — output parameters, which let a child module report its latency up to its parent, and Lilac’s timeline-type-based type system, which statically guarantees that every parameterization compiles to a hazard-free circuit. The abstraction erases itself into efficient fixed-timing hardware, measured at 26 to 33 percent fewer resources and 6.8 percent higher frequency than the latency-insensitive equivalent. Read that with its scope: it targets the convenience use of latency-insensitive interfaces, not the cases where timing is genuinely input-dependent and a handshake is required; it asks the designer to reason about parameterized timing (with the type system as a safety net) and to adopt a new language; and its guarantee is structural timing and resource safety within Lilac’s model, not full functional correctness of the generated modules. Within those bounds it is an elegant piece of language design that turns a common source of hardware overhead into something the compiler eliminates.

Background

Why interfaces and timing are the crux of building chips from parts

It helps to see why so much rides on how modules connect. Chips have grown far too large to design monolithically, so they are assembled from parts — reused blocks, purchased IP, and, increasingly, modules spat out by generators and high-level synthesis tools. The promise of that composition is the same as in software: build once, reuse everywhere. But hardware composition has a dimension software mostly lacks — time. Two blocks that connect correctly in structure can still be wrong if their timing does not line up, because a pipeline that is a cycle out of balance silently corrupts data or collides on a resource. So the interface between hardware blocks must capture not just what data crosses it but when, and getting that timing contract right, cheaply, is a central and recurring challenge of modular hardware design. That world, where composing correct hardware out of independently-produced pieces and reasoning about their timing is the whole game, is the same one the correct-by-construction control-logic-synthesis work covered elsewhere on this site inhabits, generating hardware that provably meets a timing-aware specification rather than trusting a designer to wire it up correctly by hand. Latency-abstract interfaces contribute a way to make the timing contract flexible during design and free in the final circuit.

If you remember only three things

1. Hardware modules use latency-sensitive interfaces (fixed, known timing — efficient, synchronize on the clock) or latency-insensitive ones (self-timed handshakes — necessary when timing is input-dependent, but they cost extra signals, state machines, and buffers); designers routinely wrap externally generated modules in latency-insensitive handshakes not because timing is input-dependent but merely to decouple from timing the generator can change, paying three-to-four-times the registers and a fifth-to-a-quarter lower frequency in pure overhead.
2. This paper introduces latency-abstract interfaces, which leave a generated module's timing abstract at design time and resolve it to an efficient fixed-timing interface when the generator runs during compilation, via two mechanisms: output parameters, a compile-time construct letting a child module report a value like its latency back up to its parent (inverting the usual parent-to-child parameter flow), and Lilac, a new hardware language whose timeline-type-based type system tracks how parameters affect timing and formally guarantees every parameterization compiles to a circuit with no structural hazards.
3. The designer writes balancing and scheduling logic in terms of the abstract latencies, Lilac catches pipeline-balancing bugs at compile time and, using a solver, certifies hazard freedom across all configurations, then elaborates by running the generator and lowering to efficient fixed-timing hardware with no handshake; across designs integrating real generators, latency-abstract designs use 26 to 33 percent fewer chip resources and achieve 6.8 percent higher maximum frequency than comparable latency-insensitive implementations, while still requiring a new language and applying only where timing is generator-dependent rather than truly input-dependent.

Check yourself

Check your understanding

1. Why do designers wrap generated hardware modules in latency-insensitive interfaces even when it wastes resources?
2. What is a latency-abstract interface?
3. What are output parameters and why are they needed?
4. What does Lilac's type system guarantee, and what did the evaluation show?

Sources

The paper is “Parameterized Hardware Design with Latency-Abstract Interfaces” by Rachit Nigam (MIT CSAIL), Ethan Gabizon and Edmund Lam (Cornell University), Carolyn Zech (MIT CSAIL), Jonathan Balkind (University of California, Santa Barbara), and Adrian Sampson (Cornell University), published at ASPLOS 2026, DOI 10.1145/3779212.3790199.

This explainer is written from the full text of the authors’ arXiv version (arXiv:2401.02570). Everything above comes from the paper’s own sections: the introduction distinguishing latency-sensitive interfaces (fixed, input-independent timing, efficient because modules synchronize on the clock) from latency-insensitive interfaces (ready-valid handshakes needed when latency is input-dependent but costly in extra signals, state machines, and buffers), and the observation that designers use latency-insensitive interfaces as a convenience to decouple from externally generated modules (from IP and core generators, high-level synthesis, and accelerator languages) whose timing the generator can change, which is pure overhead in a fully integrated design; the motivating floating-point-unit example integrating a FloPoCo-generated adder and multiplier, with the latency-sensitive implementation requiring manual pipeline-balancing changes and the latency-insensitive one measured (Table 1) needing three to four times more registers, twenty-nine to thirty-one percent more look-up tables, and twenty-one to twenty-five percent lower maximum frequency; the definition of latency-abstract interfaces and the two enabling ideas — output parameters, a compile-time mechanism for child modules to return values (like latency) to parent modules, inverting the usual top-down parameter flow (Figure 3), and Lilac, a parameterized hardware description language built on timeline types (from Filament) with events and availability intervals, whose type system tracks how parameters influence timing and formally guarantees the absence of structural hazards and resource-reuse violations for every parameterization, using an SMT solver to discharge constraints; the worked FPU example in Lilac (Figure 5) where the naive implementation is rejected at compile time and the corrected version schedules the multiplexer and sizes shift registers using the adder’s latency output parameter, itself exposing an output parameter for its own latency; the elaboration process that runs the generators to obtain concrete parameter values and lowers to an efficient (Filament) latency-sensitive circuit; and the evaluation integrating real generators (FloPoCo, Vivado IP dividers, Aetherling) and reporting that latency-abstract designs use 26 to 33 percent fewer chip resources and achieve 6.8 percent higher maximum frequency than comparable latency-insensitive implementations.