HDL Abstraction Levels

Event-Driven Abstraction

• Examples: Verilog, VHDL, LLHD (behavioral subset)
• Primitives: Digital state, event-triggered state updates, delays
• Domain: "Continuous" time, 2/4 valued signals
• Utility: Behavioral modeling of mixed-signal/digital IPs, RTL design* (only a subset can be mechanically translated to hardware)

Register-Transfer Level

• A subset of what a generic event-driven abstraction can describe
• Examples: FIRRTL, LLHD (structural subset), CIRCT HW dialect, Lava, Chisel, PyMTL3
• Primitives: Flops/SRAMs, boolean/arithmetic ops
• Domain: Discrete time, 2/4 valued signals
• Utility: Synchronous digital circuit design

Dataflow

• Examples: DFiant, TL-Verilog, PipelineC
• Primitives: Token streams, ordered operations, dataflow state
• Domain: Tokens in → tokens out
• Utility: Dataflow circuits, automated pipelining

Lightweight HLS

• Examples: Calyx IR, XLS
• Primitives: Digital state, imperative control blocks, scheduling, binding
• Domain: Control block statements
• Utility: Controllable HLS (explicit state, guided optimization)

Heavyweight HLS

• Examples: Legup, Vivado HLS, Catapult HLS
• Primitives: SystemC/C++
• Domain: Transaction-level
• Utility: Mostly automated state/control construction and optimization

The Emerging Multi-Abstraction World

Multi-Abstraction IRs

• CIRCT now has multiple dialects
• RTL: hw, seq, comb
• Dataflow: handshake, esi
• Lightweight HLS: ssp, calyx

There is a desire to use a suitable abstraction level for a given hardware block / model

Mixed Abstraction HDLs

• Each dialect is isolated (for simulation and design), but we could define interaction semantics between them
• HDLs only target a specific dialect: mixing abstractions isn't well supported outside blackboxing

The next iteration of HDLs should strive to support mixing abstractions in design

Mixing RTL and Higher-Level Abstractions

• Transaction-level modeling and latency-insensitive interfaces are a canonical solution to the integration question
• At a finer design granularity, this breaks down when we want to share state between RTL and higher-level descriptions
• Simulation performance can be improved

Mixing RTL and Event-Based Abstractions

• Many common circuit constructs (clock generators/muxes, async resets) are easier to describe in the event-driven paradigm
• Verilog's scheduling algorithm provides a starting point for mixing gate-level and evented blocks

Mixed-Abstraction HDLs

• How do the abstractions interact with each other, even when crossing multiple levels?
• What API do hardware designers want? For what circuits is abstraction most useful?

Other Implementation Questions for HDLs

HDL Primitives

What primitives belong in an IR/HDL?

• SRAMs (with what features?), CAMs
• Should PDK primitives be directly representable or must they be blackboxed?

Preserving Semantics Through IR Lowering

IRs try to be minimal, but HDLs try to capture design semantics. How do we pass intent to synthesis?

If we could design a synthesis frontend from scratch, what semantics are most valuable to preserve from RTL or above?

Modules: What Are they Good For?

• Modules are used for 1) instantiation, 2) parameterization boundary, 3) adding hierarchy
• Let's consider the analogies - modules:functions, parameters:function arguments, hierarchy:call stack

Are modules a good abstraction? Can we infer them? Can we remove the need for XMRs?

Incremental Elaboration for HDLs

• As hardware generators grow, elaboration becomes an iteration bottleneck
• Run-to-run caching requires analysis of generator source code, not just simple function memoization

How do we make run-to-run caching and incremental elaboration viable? Can content-addressable languages help?

Questions

• What are the considerations when designing mixed-abstraction HDLs?
• What primitives belong in an HDL / IR?
• How can we preserve semantics through to synthesis?
• Are modules still a good circuit abstraction in a mixed-abstraction world?
• How can we design an HDL with automated incremental elaboration?