LiveHD: Live Hardware Development

Summary

LiveHD is a "compiler" infrastructure for hardware design optimized for synthesis and simulation. The goals is to enable a more productive flow where the ASIC/FPGA designer can work with multiple hardware description languages like Pyrope or Verilog. In the past, it supported CHISEL, but the code is deprecated.

Goal

LiveHD: a fast and friendly hardware development flow that you can trust

To be "Fast", LiveHD aims to be parallel, scalable, and incremental/live flow.

To be "friendly", LiveHD aims to build new models to have good error reporting.

To "trust", LiveHD has CI and many random tests with logic equivalence tests (LEC).

:warning: LiveHD is beta under active development and we keep improving the API. Semantic versioning is a 0.+, significant API changes are expect.

LiveHD Framework

LiveHD stands for Live Hardware Development. By live, we mean that small changes in the design should have the synthesis and simulation results in a few seconds.

As the goal of "seconds," we do not need to perform too fine grain incremental work. Notice that this is a different goal from having an typical incremental synthesis, where many edges are added and removed in the order of thousands of nodes/edges.

LiveHD is optimized for synthesis and simulation. The main components of LiveHD includes LGraph, LNAST, integrated 3rd-party tools, code generation, and "live" techniques. The core of LiveHD is a graph structure called LGraph (Live Graph). LGraph is built for fast synthesis and simulation, and interfaces other tools like Yosys, ABC, OpenTimer, and Mockturtle. LNAST stands for language neutral AST, which is a high-level IR on both front/back-end of LGraph. LNAST helps to bridge different HDLs and HLS into LiveHD and is useful for HDLs/C++ code generation.

Contribute to LiveHD

Contributors are welcome to the LiveHD project. This project is led by the MASC group from UCSC.

Open and pending work is tracked in the todo/ hub — one page per task, grouped by topic (LiveHD, Pyrope, Verilog). If you want to contribute or seek MS/undergraduate thesis projects, please contact renau@ucsc.edu to query about them.

The repository's documentation layout (where the todo hub, directory READMEs, agent rules, and the external docs site live, and when to read each) is described in STRUCTURE.md.

You can also donate to the LiveHD project. The funds will be used to provide food for meetings, equipment, and support to students/faculty at UCSC working on this project.

The instructions for installation and internal LiveHD passes can be found at Documentation

If you are not one of the code owners, you need to create a pull request as indicated in CONTRIBUTING.md.

Publications

For more detailed information and paper reference, please refer to the following publications. If you are doing research or projects corresponding to LiveHD, please send us a notification, we are glad to add your paper.

1. A Multi-threaded Fast Hardware Compiler for HDLs, Sheng-Hong Wang, Hunter Coffman, Kenneth Mayer, Sakshi Garg, and Jose Renau. International Conference on Compiler Construction (CC), February 2023.

2. LiveHD: A Productive Live Hardware Development Flow, Sheng-Hong Wang, Rafael T. Possignolo, Haven Skinner, and Jose Renau, IEEE Micro Special Issue on Agile and Open-Source Hardware, July/August 2020.

3. LiveSim: A Fast Hot Reload Simulator for HDLs, Haven Skinner, Rafael T. Possignolo, Sheng-Hong Wang, and Jose Renau, International Symposium on Performance Analysis of Systems and Software (ISPASS), April 2020. (Best Paper Nomination)

4. SMatch: Structural Matching for Fast Resynthesis in FPGAs, Rafael T. Possignolo and Jose Renau, Design Automation Conference (DAC), June 2019.

5. LiveSynth: Towards an Interactive Synthesis Flow, Rafael T. Possignolo, and Jose Renau, Design Automation Conference (DAC), June 2017.

LGraph

6. LGraph: A Unified Data Model and API for Productive Open-Source Hardware Design, Sheng-Hong Wang, Rafael T. Possignolo, Qian Chen, Rohan Ganpati, and Jose Renau, Second Workshop on Open-Source EDA Technology (WOSET), November 2019.

7. LGraph: A multi-language open-source database for VLSI, Rafael T. Possignolo, Sheng-Hong Wang, Haven Skinner, and Jose Renau. First Workshop on Open-Source EDA Technology (WOSET), November 2018. (Best Tool Nomination)

LNAST

8. LNAST: A Language Neutral Intermediate Representation for Hardware Description Languages, Sheng-Hong Wang, Akash Sridhar, and Jose Renau, Second Workshop on Open-Source EDA Technology (WOSET), 2019.

Pyrope

Pyrope is the primary HDL for LiveHD. LiveHD ships a Pyrope language server (LSP) so editors and coding agents get live compile diagnostics (syntax, name, type, bit-width) on .prp files. See the design and remaining phases in todo/livehd/2n.html.

Language server

The server runs as lhd pyrope lsp over stdio (JSON-RPC). It is Pyrope-only (.prp); it never touches the Verilog/Yosys path.

Build it once:

bazel build -c dbg //lhd:lhd
# binary at: bazel-bin/lhd/lhd

prplsp launcher

Rather than hard-code a path, point your editor at the scripts/prplsp wrapper. It runs lhd pyrope lsp, but picks which lhd based on the directory the editor launched in:

• Inside a livehd checkout → that checkout's freshly-built bazel-bin/lhd/lhd, so iterating on the LSP needs no copy/reinstall.
• Anywhere else → the lhd found on your $PATH (the default install; an old lgshell install on $PATH still works as a legacy fallback).

So you keep one editor config everywhere. Install both prplsp and a default lhd on your $PATH — e.g. into ~/bin or ~/.local/bin:

cp scripts/prplsp ~/.local/bin/prplsp    # or: ln -s "$PWD/scripts/prplsp" ~/.local/bin/
cp bazel-bin/lhd/lhd ~/.local/bin/lhd    # the fallback used outside a checkout

Quick sanity check (it should print a framed JSON-RPC reply, then exit):

printf 'Content-Length: 58\r\n\r\n{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
  | ./scripts/prplsp

What it provides today (Phase A): real-time diagnostics via textDocument/publishDiagnostics (and the LSP 3.17 pull model). Hover, go-to definition/references, and document symbols are planned (see the contract).

Claude Code

"Install the LSP Pyrope server in Claude Code" — follow the four numbered steps below verbatim. They are idempotent; re-running them is safe.

Claude Code picks up an LSP server from a plugin. The simplest and persistent way is a skills-directory plugin: a folder under ~/.claude/skills/ containing a .claude-plugin/plugin.json. Claude Code auto-loads it in every project as pyrope-lsp@skills-dir — no marketplace, no /plugin install, no per-session --plugin-dir flag.

The same ~/.claude/skills/ directory also holds the pyrope skill (it teaches Claude how to write and check Pyrope), so Step 2 installs it alongside the LSP plugin — both become personal-scope and work in every project.

Step 1 — make sure prplsp and lhd are on your $PATH. See prplsp launcher above. Quick check:

command -v prplsp && command -v lhd     # both must print a path

Step 2 — install the pyrope skill (one time). From the root of your livehd checkout, copy the bundled skill into your personal skills directory:

mkdir -p ~/.claude/skills
cp -r .claude/skills/pyrope ~/.claude/skills/pyrope

Step 3 — create the plugin (one time). Copy-paste this whole block:

mkdir -p ~/.claude/skills/pyrope-lsp/.claude-plugin
cat > ~/.claude/skills/pyrope-lsp/.claude-plugin/plugin.json <<'JSON'
{
  "name": "pyrope-lsp",
  "description": "Pyrope language server (lhd pyrope lsp via the prplsp wrapper) — live compile diagnostics for .prp files",
  "version": "0.1.0",
  "lspServers": {
    "pyrope": {
      "command": "prplsp",
      "args": [],
      "extensionToLanguage": { ".prp": "pyrope" }
    }
  }
}
JSON

Step 4 — load and verify. Restart Claude Code (or run /reload-plugins), then:

claude plugin validate ~/.claude/skills/pyrope-lsp   # → ✔ Validation passed
claude plugin list                                   # → pyrope-lsp@skills-dir   ✔ loaded
claude plugin details pyrope-lsp@skills-dir          # → LSP servers (1)  pyrope
ls ~/.claude/skills/pyrope/SKILL.md                  # → the pyrope skill is installed

That's it. Editing a .prp file now surfaces Pyrope diagnostics to Claude automatically (error code, message, and line range), and the pyrope skill is available for writing/checking Pyrope. Both are personal scope, so they work in every project with no per-repo setup.

Notes:

• The lspServers config lives inline in plugin.json (current schema). An equivalent standalone .lsp.json in the plugin root also works. The schema evolves — if claude plugin validate complains, check the current plugin reference.
• claude plugin init pyrope-lsp --with lsp scaffolds the same folder via the CLI; if you use it, replace the generated manifest with the block in Step 2.
• To stop using it: claude plugin disable pyrope-lsp@skills-dir (or delete the folder). There is no uninstall — nothing was installed from a marketplace. To remove the skill too: rm -rf ~/.claude/skills/pyrope.
• For an in-IDE session (VS Code / JetBrains), Claude reads the editor's Problems panel via the built-in ide MCP server instead, so point your IDE's Pyrope LSP at prplsp too (see the Neovim wiring below for the pattern).

Neovim (0.11+)

scripts/pyrope.lua is a ready-made lazy.nvim plugin spec that wires up the whole experience: the .prp filetype, tree-sitter syntax highlighting (via tree-sitter-pyrope), // comment support, and the prplsp language server. Drop it into your plugins directory, restart, and run :TSInstall pyrope once:

cp scripts/pyrope.lua ~/.config/nvim/lua/plugins/pyrope.lua

If you don't use lazy.nvim (or only want the language server), the minimal wiring is just:

vim.filetype.add({ extension = { prp = "pyrope" } })

vim.api.nvim_create_autocmd("FileType", {
  pattern = "pyrope",
  callback = function(args)
    vim.lsp.start({
      name      = "livehd",
      cmd       = { "prplsp" },  -- on $PATH; uses the in-checkout build when editing livehd
      -- launch in the file's dir so prplsp detects an enclosing livehd checkout
      cmd_cwd   = vim.fn.fnamemodify(args.file, ":h"),
      root_dir  = vim.fn.getcwd(),
    })
  end,
})

Diagnostics appear through Neovim's built-in vim.diagnostic UI (:lua vim.diagnostic.setqflist() to list them).

prpfmt auto-formatting is independent of the language server above — wire it up separately via conform.nvim.

Isabelle Translation

See pass/isabelle/README.md for the pass.isabelle validation flow, CVA6 cache/memory LEC status, certificate-proof workflow, and Isabelle heap-build rules.