DOCSEARCHbyAlgolia
Submit Docs

OpenLane 2 Documentation

repository·main·Indexed 18 days ago

https://github.com/chipfoundry/openlane2

An ASIC infrastructure library providing a complete implementation flow from RTL to GDSII. OpenLane 2 integrates industry-standard tools such as OpenROAD, Yosys, Magic, and Netgen to automate ASIC design and optimization. It supports installation via Nix, Docker, and pip, and provides a CLI for executing design flows using Process Design Kits (PDKs) and JSON configuration files.

Tokens
43.8K
Snippets
108
Records
210
Agent score
63%

What's inside OpenLane 2

  1. What is OpenLane 2

    main

    OpenLane 2 is an infrastructure library used to construct digital ASIC implementation flows. It allows designers to abstract underlying EDA tools (both open-source and commercial) and configure their behavior through a single configuration file.

    Key features include:

    • Reference Flow: Includes a Classic (BETA) flow built entirely with open-source EDA tools.
    • Extensibility: Flows can be extended or modified using Python scripts and utilities.
    • PDK Support: Currently supports all variants of the Skywater PDK and some variants of the GlobalFoundries PDK.

  2. What is OpenLane?

    main

    OpenLane is an infrastructure library used to construct digital ASIC physical implementation flows. It abstracts the behavior of various EDA (Electronic Design Automation) tools, allowing users to configure complex flows using a single configuration file.

    Key features include:

    • Reference Flow (Classic): A flow constructed entirely using open-source EDA tools.
    • Flexibility: Users can extend or modify flows by developing Python scripts (plugins) and utilities or by modifying the configuration file.
    • Open Source: Freely available for use and modification.

    Note: Using OpenLane requires basic knowledge of Digital Design, ASIC concepts, JSON format, and RTL (Register Transfer Level).

  3. Explore OpenLane tutorials and community resources

    main

    Beyond official documentation, several community resources are available for learning OpenLane:

    Official Documentation

    • OpenLane ReadTheDocs: The primary documentation source.
    • Caravel User Project ReadTheDocs: Essential for shuttle submissions.
    • Google Silicon Guides: A Colab-based tutorial for building a digital inverter.

    Community Guides

    • VLSI.jp: Provides introductions to OpenMPW and walkthroughs using RgGen.
    • Erick CB: Offers tutorials for OpenLane/OpenROAD in Spanish.

    Video Tutorials

    Various video resources cover topics such as:

    • OpenLane overviews and deep dives.
    • Exploring OpenDB and Sky130nm PDK.
    • Complete installation guides for OpenLane and Sky130nm PDK (e.g., via VSD on Udemy).

    Note: Be aware that video tutorials and webinars may become outdated as the tool evolves.

  4. How State manages design snapshots and metrics

    main

    An openlane.state.State object acts as a snapshot of the design at any given point in time. It tracks the paths to various design views (e.g., Netlist, DEF, GDS).

    Key requirements for State:

    • Keys: Must be of type openlane.state.DesignFormat.
    • Values: Must be either an openlane.config.Path or N-nested dictionaries where the leaf nodes are openlane.config.Path types.
    • Metrics: The state includes a metrics attribute used to capture and update design metrics, which can be read or updated by any step in a flow.

  5. Understand how OpenLane Flow configuration variables are composed

    main

    OpenLane provides built-in Flows that automate various RTL-to-GDSII processes. The configuration variables available for any given Flow are not a single list, but a composition of several groups:

    1. Common Flow Variables: Variables shared across most flows.
    2. Common PDK Variables: Variables related to the Process Design Kit used across flows.
    3. Flow-specific Configuration Variables: Variables unique to that specific Flow's logic.
    4. Step Configuration Variables: Variables belonging to all individual steps included within that Flow.

    To find the specific variables for a Flow, you should look for the documentation generated for that specific Flow name. If you need to interact with the underlying Python implementation of these flows, refer to the Flow class API reference.

  6. Understand DRC, LVS, and LVS/DRC-clean status

    main
    DRC (Design Rule Checks) ensures a design satisfies the physical rules set by a foundry. A design without violations is DRC-clean. LVS (Layout vs. Schematic) compares the physical layout against the engineering schematic to catch connection errors. A design without errors is LVS-clean. OpenLane uses Netgen for running LVS.

  7. Understand Timing Corners in OpenLane

    main

    To ensure chip functionality under varying conditions, OpenLane performs static timing analysis across different timing corners. A timing corner is a combination of four characteristics:

    1. Parasitic/Interconnect Corners: Variations in metal layer geometry affecting capacitance and resistance. Note that the default extraction utility, OpenROAD OpenRCX, only accounts for the interconnect corner.
    2. Transistor Corners (Process Corners): Variance in transistor carrier mobility. Denoted by s (slow), t (typical), or f (fast) for both NMOS and PMOS. For example, ff denotes fast NMOS and fast PMOS.
    3. Temperature: Higher temperatures generally cause slower transistor switching.
    4. Voltage: Higher voltages generally cause faster transistor switching.

    These are often summarized by the acronym PVT (Process, Voltage, Temperature).

  8. Understand OpenLane 2 mutability principles

    main

    OpenLane 2 classes follow two primary patterns for handling state to prevent side effects during context passing:

    1. Immutable Objects: These cannot be modified in-place. Any update must be performed by creating a copy of the object. They may provide read-only functions for convenience.
    2. Replicably Modifiable Objects: Used for non-trivial computations (e.g., Steps or Flows). These objects are allowed exactly one public modifier that adheres to these rules:
      • The modifier can alter properties but must not depend on the initial values of those properties (it should be able to overwrite them if called again).
      • The modifier must be idempotent (calling it again should return the same result, barring external factors like timestamps).
      • The implementation must be split into a public part (marked @final to prevent overriding and handle validation) and an internal part (freely subclassable but only callable by the public part).

    Example: In openlane.flows.Flow, the public part is start() and the internal part is run().

  9. Run steps asynchronously in a Flow

    main

    To run steps in parallel, use openlane.flows.Flow.start_step_async(). This method returns a Future object that encapsulates a State object.

    By passing these Future objects as state_in to subsequent steps, you create a dependency chain. The flow will automatically manage the execution order, running independent steps in parallel and waiting for required dependencies to complete before proceeding.

  10. Understand GDSII and layout viewing tools

    main
    GDSII (Graphic Design System II) is the industry-standard binary format for exchanging integrated circuit layout artwork. It contains geometric shapes and labels required by manufacturers. To view or edit these layouts (or DEF files), users can use tools like KLayout or Magic.

  11. Perform Signoff: DRC, LVS, STA, and Antenna Checks

    main

    Signoff is the final verification phase before tape-out. OpenLane includes steps for:

    Design Rule Checking (DRC)

    Checks if the layout satisfies foundry manufacturing rules. OpenLane uses both Magic.DRC and KLayout.DRC to cover different tool blind spots.

    • Viewing DRC errors: Open the layout in KLayout (--flow openinklayout), go to Tools ► Marker Browser, and open the DRC report file (found in [step_number]-magic-drc/reports/drc.klayout.xml or [step_number]-klayout-drc/report/drc.klayout.xml).

    Layout Versus Schematic (LVS)

    Compares the layout (GDSII/DEF) against the schematic (Verilog) using Netgen.LVS.

    • Success indicator: The netgen-lvs.log should end with Final result: Circuits match uniquely.
    • Error details: Check lvs.rpt for node comparison tables.

    Static Timing Analysis (STA)

    Identifies timing paths and calculates slack (setup/hold). The default flow runs OpenROAD.STAPostPNR for signoff.

    • Results: Check summary.rpt for metrics across different IPVT (Interconnect, Process, Voltage, Temperature) corners.
    • Key files: min.rpt (hold), max.rpt (setup), tns.* (Total Negative Slack), and wns.* (Worst Negative Slack).

    Antenna Check

    Checks for potential gate oxide damage caused by long metal segments. OpenLane uses OpenROAD.CheckAntennas and mitigates violations by inserting antenna diode cells.

  12. Understand Timing Paths in Digital Design

    main

    Timing closure requires identifying and fixing timing violations using Static Timing Analysis (STA). STA tools (like OpenSTA) calculate the Actual Arrival Time (AAT) and Required Arrival Time (RAT) for every path. A violation occurs when there is negative slack (data arrives after the required time for setup, or before the required time for hold).

    There are four primary types of timing paths:

    • Input to output (in-to-out)
    • Input to flip-flop (in-to-reg)
    • Flip-flop to output (reg-to-out)
    • Flip-flop to Flip-flop (reg-to-reg): In this path, the first flip-flop is the 'data release' flip-flop and the second is the 'data capture' flip-flop.