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.
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:
HierarchyBase- traverse cell hierarchies
HierarchyEdit- edit cell hierarchies
NetlistBase- traverse netlists
NetlistEdit- edit netlists
LayoutBase- access layout shapes
LayoutEdit- edit layout shapes
L2NBase- access the links between layout shapes and netlist
L2NEdit- edit the links between layout shapes and netlists
Read more about netlists and layouts in the following modules:
Chip struct implements the above traits and hence can be used as a default data base structure.
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
Two dimensional geometrical primitives (polygons, rectangles, etc.) are re-exported from the
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
pub use iron_shapes;
pub use iron_shapes_booleanop;
- Blanket implementations of hierarchy traits for reference types,
- 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 🔒Experimental
- Traits for representation of circuit-level netlists.
preludehelps to import most commonly used modules.
- Acquire performance metrics of single data-base functions.
- Container structs for user defined properties.
RcStringis a simple data structure for the representation of strings. In contrast to
RcStringcan be efficiently cloned. It is intended to be used in cases where objects are indexed by a human readable name.
- Add fast region queries to layouts.
- 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.