Jose Renau | UCSC OSPO

HAgent

Tue, 11 Feb 2025 00:00:00 +0000

HAgent is a platform to build AI hardware agent engine to support multiple components in chip design, such as code generation, verification, debugging, and tapeout.

HAgent is build as a compiler for for Hardware Agents, it interfaces with typical EDA tools like compilers, synthesis, and verification. There are several projects around enhancing HAgent.

BugFarm hagent step

Objective: Develop a HAgent step (pass) to create bugs in a given design.

Description: Using LLMs (Hagent APIs), the goal is to add “bugs” to input Verilog design. The goal is for other tools passes that need to fix bugs, to use this infrastructure as a bug generator. There is a MCY (https://github.com/YosysHQ/mcy) that does something similar but it does not use verilog and create a very different Verilog output. The BugFarm is supposed to have somewhat similar functionality but edit the Verilog directly which results in a code with just a few edits. Like MCY, there has to be a step to confirm that the change affects results. The project should benchmarks and compare with MCY.

Skills Needed: Python, Verilog, and understand agents
Difficulty: Medium
Size: Medium
Mentors: Jose Renau, Farzaneh Rabiei Kashanaki

HDEval Competition Repository

Objective: Create a platform for HDL programming challenges and community engagement.

Description: Develop a repository where users can solve HDL problems in Verilog, Chisel, PyRTL, etc. Implement a points system for successful solutions. Allow users to submit new problems (code, specifications, verification, and tests) that are not easily solvable by LLMs. Automate solution testing and provide feedback on submissions.

The submissions consist of 4 components: code, specification, verification, and tests. It should be possible to submit also examples of bugs in code/specification/verification/tests during the design.

If the code is different from Verilog, it should include the HDL (chisel, PyRTL,…) and also the Verilog.

The specification is free form. For any given specification, an expert on the area should be able to generate code, verification, and tests. Similarly, from any pair. Any expert should be able to generate the rest. For example, from verification and tests, it should be able to generate the code and specification.

Typical specifications consist of a plan, API, and a sample usage.

Skills Needed: Web design, some hardware understanding
Difficulty: Medium
Size: Medium
Mentors: Jose Renau, Farzaneh Rabiei Kashanaki

Integrate Silicon Compiler

Objective: Silicon Compiler is an open-source Python library that allows to interface with many EDA tools. The idea is to integrate it with HAgent to allow prompts/queries to interface with it.

Description: The agentic component requires to check with silicon compiler that the generated Python compiles but also that has reasonable parameters. This will require a react loop for compiler errors, and likely a judge loop for testing for reasonable options/flow with feedback from execution. Since there is not much training examples, it will require a few shot with a database to populate context accordingly.

The end result should allow to select different tools and options trhough silicon compiler.

Skills Needed: Backend chip design
Difficulty: High
Size: Medium
Mentors: Jose Renau

Comodore 64 or MSX or Gameboy

Objective: Create a prompt-only specification to build a hardware accelerated for the target platform (Comodore 64, MSX or Gameboy). The generated code should focus on Verilog, but it is fine to also target some other HDL. In all the cases, the project should include a generated Verilog integrated with some emulator for verification.

Description: Using Hagent, create an HDLEval benchmark (set of prompts) that provide the necessary information to create the Verilog implementation. HDLEval prompts usually consists of a high-level PLAN or specification, an API to implement, and a few examples of usage for the given API.

The result of running the bencharmk, a generated Verilog runs program in the emulator and the Verilog to compare correctness. The platform should have an already existing emulator vice-emu or mGBA to perform cosimulation against the generated specification.

Skills Needed: Verilog for front-end design
Difficulty: High
Size: Large (175 or 350 hours)
Mentors: Jose Renau

LiveHD

Thu, 01 Feb 2024 00:00:00 +0000

The goals is to enable a more productive flow where the ASIC/FPGA designer can work with multiple hardware description languages like CHISEL, Pyrope, or Verilog.

There are several projects, some compiler infrastructure around LiveHD. Others around how to interface LLMs to improve chip design productivity.

There are the following projects available:

Slang with LiveHD
Hardware Hierarchical Dynamic Structures (hdds)
HDLEval for LLMs
C++ Profiler Optimizer with LLMs
Decompiler from Assembly to C++ with LLMs

Slang with LiveHD

Project Idea

slang is one of the best open source Verilog front-ends available. LiveHD uses slang, but only a subset of Verilog is supported. The goal is to add more slang features.

Project Deliverable

The slang/LiveHD interface creates LiveHD IR (LNAST IR). The plan is to keep extending the translation to support more features. This is a project that allows small steps. The goal is to support all Verilog 2001, and potentially some System Verilog features.

Topics: SysteVerilog, Compilers
Skills Needed: Knowledge of Verilog, C++17, some compiler background.
Difficulty: Medium
Size: Large
Mentor: Jose Renau, Sakshi Garg

Hardware Hierarchical Dynamic Structures (hdds)

Project Idea

hdds aims to build efficient tree and graph data structures commonly used by hardware compilers. A key difference is the hierarchical nature, and patterns.

Project Deliverable

There are 2 main components: Graph and Tree.

For each, there is a hierarchical implementation that allows to connect tree/graphs in a hieararchy. For example, a graph can call another graph with input and outputs like a Verilog module calls other Verilog modules.

Both classes should have iterators for traversing in topological sort.

Topics: Data structures for compilers
Skills Needed: Data structures, C++17
Difficulty: Medium
Size: Large
Mentor: Jose Renau, Sakshi Garg

HDLEval for LLMs

Project Idea

LLMs can be used to create new hardware. The goal of this project is to create multiple prompts so that LLM/compiler designers can have examples to improve their flows.

Project Deliverable

The idea is to create many sample projects where a “input” creates a Verilog artifact. The specification should not assume Verilog as output because other HDLs like Chisel could be used.

The goal is to create many sample circuits that are realistic and practical. The description can have

Topics: Verilog, LLMs
Skills Needed: Verilog or Chisel
Difficulty: Low
Size: Small or medium
Mentor: Jose Renau

C++ Profiler Optimizer with LLMs

Project Idea

Fine-tune, and/or RAG, a LLM to leverage profiling tools so that it can provide code optimization recommendations for C++ and possibly Rust code.

Project Deliverable

Create a Python package (poetry?) called aiprof that analyzes the execution of a C++ or Rust program and provide code change recommendations to improve performance.

aiprof ./binary

aiprof uses perf tools but also other tools like redspy, zerospy, and loadspy to find problematic code areas and drive the GPT optimizer.

The plan is to find several examples of transformations to have a database so that a model like CodeLlama or mixtral can be fine-tuned with code optimization recomendations.

Topics: C++, perf tools
Skills Needed: C++17, Linux performance counters
Difficulty: Medium
Size: Large
Mentor: Jose Renau

Decompiler from Assembly to C++ with LLMs

Project Idea

There are several decompilers from assembly to C like ghidra and retdec. The idea is to enhance both outputs to feed an LLM to generate nicer C++ code.

Project Deliverable

ghidra and retdec generate C code out of assembly. The idea is to start with these tools as baseline, but feed it to a LLM to generate C++ code instead of plain C.

Create a Python package (poetry?) called aidecomp that integrates both decompilers. It allows to target C or C++17.

To check that the generated code is compatible with the function translated, a fuzzer could be used. This allows aidecomp to iterate the generation if the generated code is not equivalent.

Topics: C++, decompilers
Skills Needed: C++17
Difficulty: Medium
Size: Large
Mentor: Jose Renau

LiveHD (2022)

Mon, 07 Nov 2022 10:15:56 -0700

Projects for LiveHD. Lead Mentors: Jose Renau and Sheng-Hong Wang.

HIF Tooling


Title	HIF tooling
Description	Tools around Hardware Interchange Format (HIF) files
Mentor(s)	Jose Renau
Skills	C++17
Difficulty	Medium
Size	Medium 175 hours
Link

HIF (https://github.com/masc-ucsc/hif) stands for Hardware Interchange Format. It is designed to be a efficient binary representation with simple API that allows to have generic graph and tree representations commonly used by hardware tools. It is not designer to be a universal format, but rather a storate and traversal format for hardware tools.

LiveHD has 2 HIF interfaces, the tree (LNAST) and the graph (Lgraph). Both can read/write HIF format. The idea of this project is to expand the hif repository to create some small but useful tools around hif. Some projects:

hif_diff + hif_patch: Create the equivalent of the diff/patch commands that exist for text but for HIF files. Since the HIF files have a more clear structure, some patches changes are more constrained or better understood (IOs and dependences are explicit).
hif_tree: Print the HIF hierarchy, somewhat similar to GNU tree but showing the HIF hieararchy.
hif_grep: capacity to grep for some tokens and outout a hif file only with those. Thena hif_tree/hif_cat can show the contents.

Mockturtle


Title	Mockturtle
Description	Perform synthesis for graph in LiveHD using Mockturtle
Mentor(s)	Jose Renau
Skills	C++17, synthesis
Difficulty	Medium
Size	Medium 175 hours
Link

There are some issues with Mockturtle integration (new cells) and it is not using the latest Mockturtle library versions. The goal is to use Mockturtle (https://github.com/lsils/mockturtle) with LiveHD. The main characteristics:

Use mockturtle to tmap to LUTs
Use mockturtle to synthesize (optimize) logic
Enable cut-rewrite as an option
Enable hierarchy cross optimization (hier:true option)
Use the graph labeling to find cluster to optimize
Re-timing
Map to LUTs only gates and non-wide arithmetic. E.g: 32bit add is not mapped to LUTS, but a 2-bit add is mapped.
List of resources to not map:
- Large ALUs. Large ALUs should have an OpenWare block (hardcoded in FPGAs and advanced adder options in ASIC)
- Multipliers and dividers
- Barrell shifters with not trivial shifts (1-2 bits) selectable at run-time
- memories, luts

Query Shell


Title	Query Shell
Description	Create a console app that interacts with LiveHD to query parameters about designs
Mentor(s)	Jose Renau
Skills	C++17
Difficulty	Medium
Size	Medium 175 hours
Link

Based on replxx (like lgshell)
Query bits, ports… like
- https://github.com/rubund/netlist-analyzer
- https://www.jameswhanlon.com/querying-logical-paths-in-a-verilog-design.html
It would be cool if subsections (selected) parts can be visualized with something like https://github.com/nturley/netlistsvg
The shell may be expanded to support simulation in the future
Wavedrom/Duh dumps

Wavedrom and duh allows to dump bitfield information for structures. It would be interesting to explore to dump tables and bit fields for Lgraph IOs, and structs/fields inside the module. It may be a way to integrate with the documentation generation.

Example of queries: show path, show driver/sink of, do topo traversal,….

As an interesting extension would be to have some simple embedded language (TCL or ChaiScript or ???) to control queries more easily and allow to build functions/libraries.

Lgraph and LNAST check pass


Title	Lgraph and LNAST check pass
Description	Create a pass that check the integrity/correctness of Lgraph and LNAST
Mentor(s)	Jose Renau
Skills	C++17
Difficulty	Medium
Size	Large 350 hours
Link

Create a pass that checks that the Lgraph (and/or LNAST) is semantically correct. The LNAST already has quite a few tests (pass.semantic), but it can be further expanded. Some checks:

No combinational loops
No mismatch in bit widths
No disconnected nodes
Check for inefficient splits (do not split buses that can be combined)
Transformations stages should not drop names if same net is preserved
No writes in LNAST that are never read
All the edges are possible. E.g: no pin ‘C’ in Sum_op

unbitwidth


Title	unbitwidth
Description	Not all the variables need bitwidth information. Find the small subset
Mentor(s)	Jose Renau
Skills	C++17
Difficulty	Medium
Size	Medium 175 hours
Link

This pass is needed to create less verbose CHISEL and Pyrope code generation.

The LGraph can have bitwidth information for each dpin. This is needed for Verilog code generation, but not needed for Pyrope or CHISEL. CHISEL can perform local bitwidth inference and Pyrope can perform global bitwidth inference.

A new pass should remove redundant bitwidth information. The information is redundant because the pass/bitwidth can regenerate it if there is enough details. The goal is to create a pass/unbitwidth that removes either local or global bitwidth. The information left should be enough for the bitwidth pass to regenerate it.

Local bitwidth: It is possible to leave the bitwidth information in many places and it will have the same results, but for CHISEL the inputs should be sized. The storage (memories/flops) should have bitwidth when can not be inferred from the inputs.
Global bitwidth: Pyrope bitwidth inference goes across the call hierarchy. This means that a module could have no bitwidth information at all. We start from the leave nodes. If all the bits can be inferred given the inputs, the module should have no bitwidth. In that case the bitwidth can be inferred from outside.

LiveHD (2023)

Mon, 07 Nov 2022 10:15:56 -0700

Projects for LiveHD.
Lead Mentors: Jose Renau and Sakshi Garg.
Contributor(s): Shahzaib Kashif

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 CHISEL, Pyrope, or Verilog.

There are several projects available around LiveHD. A longer explanation and more project options are available at projects. Contact the mentors to find a project that fits your interests.

A sample of helpful projects:

Mockturtle


Title	Mockturtle
Description	Perform synthesis for graph in LiveHD using Mockturtle
Mentor(s)	Jose Renau and Sakshi Garg
Skills	C++17, synthesis
Difficulty	Medium
Size	Medium 175 hours
Link

Mockturtle (https://github.com/lsils/mockturtle) is a synthesis tool partially integrated with LiveHD. The goal of this task is to iron out bugs and issues and to use the LiveHD Tasks API to parallelize the synthesis.

Main features:

The current synthesis divides the circuit in partitions. Each partition can be synthesized in parallel.
Support hierarchical synthesis to optimize cross Lgraphs (cross verilog module optimization)

The goal is to use Mockturtle (https://github.com/lsils/mockturtle) with LiveHD. The main characteristics:

Use mockturtle to tmap to LUTs
Use mockturtle to synthesize (optimize) logic
Enable cut-rewrite as an option
Enable hierarchy cross optimization (hier:true option)
Use the graph labeling to find cluster to optimize
Re-timing
Map to LUTs only gates and non-wide arithmetic. E.g: 32bit add is not mapped to LUTS, but a 2-bit add is mapped.
List of resources to not map:
- Large ALUs. Large ALUs should have an OpenWare block (hardcoded in FPGAs and advanced adder options in ASIC)
- Multipliers and dividers
- Barrell shifters with not trivial shifts (1-2 bits) selectable at run-time
- memories, luts

LiveHD Console


Title	LiveHD Console
Description	Create a console app that interacts with LiveHD to query parameters about designs
Mentor(s)	Jose Renau and Sakshi Garg
Skills	C++17
Difficulty	Medium
Size	Medium 175 hours
Link

Current LiveHD uses replxx but it a no longer maintained shell/console. The result is that it fails in newer versions of OSX.

There is an alternative Crossline (https://github.com/jcwangxp/Crossline). This affects main/main.cpp and nothing else.

In addition to replace the current console with auto-completion, the plan is to add “query” capacity to visualize some of the LiveHD internals.

Query bits, ports… like
- https://github.com/rubund/netlist-analyzer
- https://www.jameswhanlon.com/querying-logical-paths-in-a-verilog-design.html
It would be cool if subsections (selected) parts can be visualized with something like https://github.com/nturley/netlistsvg
The shell may be expanded to support simulation in the future
Wavedrom/Duh dumps

Example of queries: show path, show driver/sink of, do topo traversal,….

Compiler error generation pass


Title	Lgraph and LNAST check pass
Description	Create a pass that check the integrity/correctness of Lgraph and LNAST
Mentor(s)	Jose Renau and Sakshi Garg
Skills	C++17
Difficulty	Medium
Size	Large 350 hours
Link

Create a pass that checks that the Lgraph (and/or LNAST) is semantically correct. The LNAST already has quite a few tests (pass.semantic), but it can be further expanded. Some checks:

No combinational loops
No mismatch in bit widths
No disconnected nodes
Check for inefficient splits (do not split buses that can be combined)
Transformations stages should not drop names if same net is preserved
No writes in LNAST that are never read
All the edges are possible. E.g: no pin ‘C’ in Sum_op