hardcaml hardcaml custom open source FPGA SSD with hardcaml FPGA book on hitchikers guide to FPGA
all this things: https://intel.github.io/rohd-website/
open source FPGA silicon : https://github.com/MidstallSoftware/aegis
https://anil.recoil.org/notes/fpgas-hardcaml https://anil.recoil.org/ideas/tracing-hdl-with-effects https://anil.recoil.org/ideas/computational-storage-for-vector-dbs
claude conversation:
what will we achive which hardcaml can’t do with this thing or in genreal comparsion with other hdl in the ecoyssytem from dart to haskell clash
https://anil.recoil.org/ideas/tracing-hdl-with-effects
Great read — this is a research proposal by Anil Madhavapeddy (Cambridge) for an MPhil project exploring OCaml 5 effects as a foundation for a tracing-style HDL. Let me break down exactly what this achieves vs. HardCaml, and how it positions in the broader ecosystem.
The Core Idea: Tracing vs. Building
The fundamental distinction is how the circuit graph gets constructed.
HardCaml today — combinator / data-structure style: You write OCaml that builds up a circuit as a data structure. Your OCaml program’s output is the circuit. This requires heavy use of the OCaml module system (functors, first-class modules, typed interfaces) to compose components. It’s powerful but has a steep learning curve — you’re always mentally managing two layers: the OCaml meta-level and the hardware object-level.
The effects-based tracing HDL — direct execution style: You write OCaml that directly looks like the circuit it describes. You evaluate OCaml code, and the effect handlers intercept and record what happened — building the circuit graph as a side effect of running the program. The circuit emerges from tracing execution, not from explicitly constructing a data structure.
What This Buys Over HardCaml Specifically
1. Ergonomics & accessibility HardCaml’s module-system-heavy approach is a productivity wall. It makes very heavy use of the module system to build up the circuit description as an OCaml data structure recoil, which means you need to be fluent in OCaml’s more advanced features (functors, module signatures, first-class modules) before you can be productive. The effects approach lets you write code that reads like ordinary imperative/functional computation — the tracing machinery is transparent.
2. Control-flow memoization via effects This is the deeper technical win. Effect handlers can intercept recursive calls and memoize their circuit-graph expansions, which means shared subgraphs don’t get duplicated. In a plain combinator HDL you have to manually thread sharing; here the handler does it structurally.
3. Restricting recursion properly Arbitrary recursion in hardware is a problem (it implies infinite logic). Effects let you intercept recursive calls and decide how to handle them — either unrolling a fixed number of times, requiring explicit register boundaries, or rejecting unbounded recursion statically. This is a semantic guarantee you can enforce via the handler rather than relying on programmer discipline.
4. Fixed-length vectors ergonomically Hardware is full of [N]bit types. HardCaml encodes these but it’s verbose. The proposal explicitly targets this as an ergonomics win to explore.
Comparison Across the Ecosystem
| HDL | Host language | Style | Key strength | Key weakness |
|---|---|---|---|---|
| Verilog / VHDL | Domain-specific | Structural/RTL | Industry standard, tool support | Weak abstraction, verbose, no types |
| HardCaml | OCaml | Combinator / data-structure | Strong typing, Jane Street production use, module polymorphism | Module-system learning cliff, two-layer mental model |
| Clash | Haskell | Tracing (type-directed) | Looks like Haskell functions, REPL, fixed-length Vec types, type inference | GHC type-level complexity, long compile times, Haskell ecosystem barrier |
| Chisel | Scala | Embedded DSL / combinator | JVM ecosystem, industry adoption, good tooling | Scala complexity, Spark-style boilerplate, runtime errors |
| SpinalHDL | Scala | Combinator | Cleaner than Chisel, good abstractions | Niche, small community |
| Amaranth (nMigen) | Python | Combinator | Accessible, fast iteration, Python ecosystem | Dynamic typing catches errors late, Python perf for large designs |
| Lava / Kansas Lava | Haskell | Combinator (arrows) | Theoretically clean | Effectively abandoned |
| This proposal (OCaml effects HDL) | OCaml 5 | Tracing via effects | See below | Research prototype — not production |
The Clash Comparison Is Central
Clash uses a number of advanced Haskell type-level features to encode fixed-length vectors and has an interactive REPL that allows for exploration without requiring a separate test bench. recoil
Clash is the closest spiritual ancestor. It achieves the “write hardware like functions” feel through Haskell’s lazy evaluation + GHC’s rewriting + type-level naturals for Vec n a. The tracing HDL proposal wants to achieve the same feel in OCaml, but through a structurally different mechanism:
- Clash traces by exploiting Haskell’s lazy graph reduction — the program graph is the circuit graph, extracted by GHC’s normalizer. You’re fighting GHC internals.
- Effects HDL traces by using explicit delimited continuations (effect handlers) to intercept evaluation. This is semantically cleaner, more inspectable, and doesn’t depend on compiler internals.
The OCaml approach could be more predictable than Clash because you don’t rely on GHC’s optimizer doing the right thing — the tracing boundary is explicitly defined by the effect handler.
The Dart Angle
There’s no serious Dart HDL in the ecosystem. The closest thing would be using Dart for FPGA scripting/tooling (e.g. ROHD from Intel uses Dart as the host), which is more in the Amaranth territory — accessible dynamic language, combinator style. It gains Python-like ergonomics but loses the type-level guarantees that make Clash/HardCaml interesting. The effects proposal is at the opposite end: it wants more semantic power and correctness guarantees, not less.
What Would Genuinely Be Novel
If the effects approach works, the real contribution is:
- A new point in the design space: tracing-style HDL that doesn’t require a lazy language or compiler internals to work, but instead uses first-class algebraic effects as the mechanism.
- Effect handlers as a hardware/software duality tool: the same OCaml code could be run natively for simulation (handler = execute normally), or traced for synthesis (handler = build circuit graph), or partially evaluated (handler = mixed). One program, multiple interpretations — this is the “finally tagless” / multi-stage dream done cleanly.
- Recursion control as a first-class citizen, not a linting afterthought.
The open question is whether OCaml 5 effects are expressive enough to handle the multi-shot continuation patterns needed for circuit sharing and unrolling. The memo.ml example in the effects-examples repo suggests yes, but at scale in hardware design it remains to be proven.
what would be good project to implment in this hdl to get idea about how good ocaml5 effects are there, like open source fpga or some other thing or suggest something good
This is a great question. You want something that stresses the effect system in interesting ways — not just “does it work” but “where does it shine or crack.” Let me think through this carefully.
What Makes a Good Test Case
You want a project that exercises:
- Structural sharing — same subgraph reused many times (tests memoization via effects)
- Controlled recursion — natural recursion that must be unrolled to fixed depth
- Fixed-length vector arithmetic — the ergonomics win over HardCaml
- Multiple interpretations — same code simulated, synthesized, and maybe formally verified
Tier 1: Best Bang for Effort
A Systolic Array for Matrix Multiply
This is the perfect first serious project. A systolic array is a grid of identical processing elements (PEs) where data flows rhythmically between neighbors.
Why it’s ideal:
- The PE is defined once, instantiated N×M times — directly tests whether effect-based sharing deduplicates the graph properly or explodes it
- The grid wiring is naturally expressed as a recursive function over indices — tests controlled recursion unrolling
- It’s the exact architecture inside TPUs, and is a hot target for open-source FPGA ML accelerators (like FINN)
- Small enough to complete, deep enough to be real
What you’d learn about OCaml effects: whether memoization via effects correctly identifies structurally identical PE instances, and whether the tracing produces a flat efficient netlist rather than N×M duplicate subgraphs.
A Pipelined RISC-V Core (RV32I)
Not a full core — just the 5-stage pipeline: Fetch → Decode → Execute → Memory → Writeback.
Why it’s ideal:
- Pipeline hazard logic is naturally expressed as conditional forwarding — great test of how control flow in the host OCaml maps to mux logic in the traced circuit
- Register file is a fixed-length vector of 32 registers — directly tests the Vec ergonomics
- There are excellent open-source reference implementations (PicoRV32, VexRiscv, SERV) to validate against
- The RISC-V spec is clean and minimal — you spend time on the HDL problem, not architecture archaeology
What you’d learn: how well recursive/structured decode logic traces, and whether the effect handler correctly handles the stateful pipeline registers vs. combinational logic distinction.
Tier 2: Sharper Tests of Specific Effect Properties
A Parametric FIR Filter Bank
A bank of N FIR filters sharing tap coefficients.
Why interesting: this is the canonical test for structural sharing. In a naive combinator HDL you’d get N×M multipliers. With correct memoization effects, shared constant-coefficient multipliers should collapse. This is a very targeted stress test of the memo effect specifically — you’d know within 200 lines whether the approach works or has fundamental issues.
A SHA-256 / AES-128 Core
Cryptographic cores are beloved FPGA targets and have:
- Highly regular round structures (natural recursion to unroll)
- Fixed 32/64-bit word widths everywhere (Vec ergonomics)
- Well-known reference outputs for testing
The round function is defined once and applied N times — a direct test of whether for-style unrolling via effects produces correct pipelined or iterative hardware. There’s also an open-source reference in every HDL imaginable to compare netlists against.
A UART / SPI Controller
Deceptively good for testing the simulation vs. synthesis duality. A UART is a simple state machine, but:
- You want to run it in OCaml natively with a mock byte stream (simulation handler)
- Then trace it to Verilog (synthesis handler)
- Then maybe hook it to a formal tool to verify the baud rate arithmetic (verification handler)
Same OCaml code, three handlers, three interpretations. This is the cleanest possible demo of the effects-as-multiple-backends idea and fits in ~500 lines.
Tier 3: Ambitious / Research-Grade
A Sparse Attention Accelerator
Given the FPGA+vector-DB usecase Anil mentions on the same site, implementing a hardware block for sparse dot-product attention would be genuinely novel. The challenge: irregular sparsity patterns mean the circuit structure itself becomes data-dependent — a hard case for any tracing HDL.
Connecting to OpenROAD / Yosys
Rather than targeting Verilog output → vendor tools, you could target the RTLIL (internal format of Yosys, the open-source synthesis tool) directly from your effect-traced AST. This would make the whole flow open: OCaml effects → RTLIL → OpenROAD → GDS. No proprietary tools anywhere.
Concrete Recommendation
Start with the FIR filter bank (2–3 days, laser-focused on the memo effect), then graduate to the systolic array (the real project). These two together will tell you definitively whether OCaml 5 effects are genuinely better than Clash’s lazy-graph approach or HardCaml’s explicit modules — specifically on the sharing and recursion problems that matter most in real synthesis.
The UART is the right companion project to validate the multi-handler / multi-interpretation story, which is arguably the most novel claim in the whole proposal.