Crate libreda_db

source ·
Expand description

This crate is a database for VLSI physical design. The core components are traits that define how netlist and layouts can be accessed and modified. Additionally the crate provides default implementations of those traits for representation of chip layouts and netlists.

Core parts

An important part of this crate are trait definitions that describe the access methods of cell hierarchies, netlists and layouts. The idea is that most algorithms should not be implemented for concrete types but for this traits. For instance an algorithm that analyzes a netlist without looking at the layout might be implemented for all types that implement the NetlistBase trait. In many cases this allows to be agnostic of the actual netlist implementation. Hence the algorithm implementation might be more portable.

A fundamental idea is that all things (cells, instances, pins, nets, shapes, etc.) have unique identifiers. The type of the identifiers is generically defined as an associated type of the traits. In practice the identifiers might be for example integers but they can also some sort of smart pointer.

The following are important traits which define how netlist and layouts can be accessed and modified:

Read more about netlists and layouts in the following modules:

The Chip struct implements the above traits and hence can be used as a default data base structure.

Netlist/layout wrappers

Additional functionality can be added to netlists and layout structures with the following wrappers:

  • Undo - Make modifications reversible
  • FlatView - Create an on-the-fly flattened view of a hierarchical structure.


Reading and writing data base structures is generally left to other crates such as libreda-oasis, libreda-lefdef, …

Geometric primitives

Two dimensional geometrical primitives (polygons, rectangles, etc.) are re-exported from the iron_shapes crate.

There is no complete standard way to deal with technology related data. A proposal on how to also create an abstraction layer for technology data such as rules is here:

  • technology - interfaces for accessing technology related information such commonly used DRC rules



  • Blanket implementations of hierarchy traits for reference types, Rc, Arc and Box.
  • Chip data structure holding netlist and layout together. Chip implements the L2NEdit trait and hence qualifies for representing netlists fused with a layout. Chip can also be used solely as a netlist structure or as a layout structure.
  • Helpers for deriving trait implementations of core traits.
  • Wrapper around a netlist which provides an on-the-fly flat view of a certain cell. The presented view is flattened until leaf cells. Internally this works by using component IDs that are actually paths through the hierarchy.
  • Concept of ‘hierarchy’ which is used in layouts and netlists.
  • Data structure for creating indices related to some other type. This is used to create handles for data stored in hash maps.
  • Trait definitions for layouts fused with netlists.
  • Geometrical layout data structures.
  • library 🔒
  • Traits for representation of circuit-level netlists.
  • The prelude helps to import most commonly used modules.
  • Acquire performance metrics of single data-base functions.
  • Container structs for user defined properties.
  • RcString is a simple data structure for the representation of strings. In contrast to String, RcString can be efficiently cloned. It is intended to be used in cases where objects are indexed by a human readable name.
  • Experimental
  • Add fast region queries to layouts.
  • Experimental
  • slab_alloc 🔒
    Container with O(1) insertion, lookup and remove operations.
  • Traits and datastructures for the representation of technology related properties, especially design rules.
  • Re-export all traits defined in this crate.
  • Experimental: Wrapper around netlist, layout and L2N structures that allows undoing of operations.