LiveHD (2022)

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

HIF Tooling

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

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

• 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

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

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.