DOCSEARCHbyAlgolia
Submit Docs

CIRCT (Circuit Intermediate Representations Compilers and Tools)

repository·main·Indexed 24 days ago

https://github.com/llvm/circt

An experimental project applying MLIR and LLVM methodologies to hardware design tools to provide a modular, library-based infrastructure for open hardware tooling. Includes tools such as circt-opt, firtool, and circt-lec for logical equivalence checking, as well as the pycde Python design entry package and support for Verilog-to-MLIR flows via the Slang frontend.

Tokens
85.9K
Snippets
125
Records
427
Agent score
81%

What's inside CIRCT

  1. Overview of the 'hw' Dialect

    main
    The hw dialect in CIRCT provides a generic representation of hardware (HW) that is intended to be independent of any specific use-case. It serves as a foundational layer for hardware modeling within the CIRCT ecosystem, defining core operations, types, and attributes used to describe hardware structures.

  2. Overview of the 'firrtl' Dialect

    main
    The firrtl dialect is used in CIRCT to facilitate the lowering process from Chisel code to Verilog. It provides a structured representation of FIRRTL (Flexible Intermediate Representation for RTL) operations, including structural components, declarations, statements, expressions, and intrinsics. For deeper details on the underlying specification, refer to the FIRRTL GitHub page.

  3. ESI cosim wire protocol (v3) overview

    main

    The ESI cosim runtime uses a WebSocket connection to facilitate communication between a client (e.g., a Python harness) and a server. The protocol consists of two types of frames:

    1. Control frames: WebSocket text frames containing a JSON object. These are used for RPC-style methods like hello, subscribe, and unsubscribe.
    2. Data frames: WebSocket binary frames containing a single ESI message. These are used for high-throughput data transfer.

    Transport Details:

    • Endpoint: ws://<host>:<port>/esi/cosim/v3.
    • Connection: Single WebSocket connection per client. The server allows at most one connected client at a time.
    • Discovery: The server writes its bound port to a cosim.cfg file in its working directory using the format port: <number>.
    • Security: TLS (wss://) is not used in v3; both ends are expected to run on the same host.

  4. Use the Simulation Dialect for simulator-specific operations

    main
    The sim dialect provides a high-level representation for operations that interact with hardware simulators such as Verilator, VCS, or Arc. It is designed to make simulator-specific constructs easy to analyze and transform within the compiler by providing compact operations for complex logic.

  5. Use the Verif Dialect for hardware verification

    main
    The Verif dialect in CIRCT provides a set of operations designed to express verification concerns within hardware designs. It allows developers to include assertions and define mechanisms for interacting with hardware components specifically to verify their correct functional behavior.

  6. Understand the Arc Dialect's purpose and simulation model

    main

    The Arc dialect provides operations and types to represent state transfer functions (arcs) in a circuit. Its primary purpose is to provide an intermediate representation optimized for simulation.

    It transforms hardware descriptions from the HW, Seq, and Comb dialects into a flattened form where:

    • Module hierarchies are flattened.
    • Combinational logic is represented as callable "arcs" (state transfer functions).
    • Sequential elements are modeled explicitly.

    The arcilator simulation tool uses this dialect to compile Arc IR into LLVM-based binary objects for high-performance simulation.

  7. Understand the CIRCT design philosophy

    main

    CIRCT (Circuit IR Compilers and Tools) is built on the LLVM/MLIR framework to solve two primary challenges in modern computer architecture: designing complex, heterogeneous systems-on-chip (SoCs) and programming them.

    CIRCT uses MLIR dialects to represent various levels of hardware abstraction. This approach allows different design languages to be lowered into common dialects, enabling shared optimization efforts across different design languages and target architectures. The goal is to unify the abstractions used for both accelerator design (building the hardware) and accelerator programming (writing software for the hardware).

  8. Overview of the LLHD Dialect

    main
    The LLHD (Low-Level Hardware Description) dialect provides operations and types for interacting with an event queue in event-based simulations. It is designed to describe how signals change over time in response to other signal changes and the advancement of physical time. This model aligns with how established hardware description languages like SystemVerilog and VHDL use event queues to describe combinational logic, sequential logic, and test benches.

  9. Overview of CIRCT Formal Verification Tooling

    main

    CIRCT provides infrastructure for implementing formal verification tools, such as logical equivalence checking, model checking, and symbolic execution. The architecture is designed to allow compiler engineers to implement custom verification tools by leveraging existing dialects and passes.

    Verification Workflow:

    1. Problem Specification: An explicit operation is inserted into the IR to specify the verification problem (e.g., verif.lec for Logical Equivalence Checking or verif.bmc for Bounded Model Checking).
    2. Lowering/Encoding: These operations are lowered to an encoding in an SMT solver, an interactive theorem prover, or a BDD. Currently, SMT is the primary supported backend.
    3. Backend Export: SMT encodings can be exported to SMT-LIB or lowered to LLVM IR that interfaces with solvers like Z3.

    Available Tools:

    • Logical Equivalence Checker (LEC): Used to verify that two hardware designs are functionally identical.
    • Bounded Model Checker (BMC): Used to verify properties within a bounded number of cycles.

  10. What is the Elastic Silicon Interconnect (ESI) dialect?

    main

    The Elastic Silicon Interconnect (ESI) dialect is designed to standardize and abstract communication in FPGA/ASIC design. It addresses two primary issues in hardware design:

    1. ABI/Signaling Abstraction: It provides a standardized interface that separates the physical signaling layer from the message layer. This allows for the automation of signaling protocols, latency-insensitive interfaces, and clock domain crossings.
    2. Hardware-Centric Type System: It defines a rich type system to provide strong static type safety across interconnects, moving away from informally specified data types in datasheets.

    By using ESI, developers can automate tasks such as inter-language communication, type checking at interface boundaries, automatic gearboxing for different bandwidths, and software API generation for PCIe or network bridges.

  11. What is the Handshake dialect and its core principle

    main
    The Handshake dialect is a dataflow IR designed to describe independent, unsynchronized processes. Its core principle is that these processes communicate data through First-in First-out (FIFO) communication channels. This model can be implemented using various hardware or software backends, such as synchronous logic or processors.

  12. Track inlined modules with `dbg.scope`

    main

    While hw.module and hw.instance provide implicit scopes, you can use the dbg.scope operation to explicitly model the hierarchy of an inlined module. This allows you to group all debug variables belonging to the inlined module under a single scope, preserving the original structural view even after the instance operation is removed.

    // Before inlining, we represent the inlined module 'Bar' as a scope
%0 = dbg.scope "bar", "Bar"

// Use the 'scope' operand to associate variables with that scope
dbg.variable "x", %a scope %0 : i42
dbg.variable "squared", %1 scope %0 : i42