Views¶

Views can modify the implementation of a network interface by

adding interface methods that are not supported by the implementation,
changing the implementation of interface methods, and
deleting interface methods.

Views implement the network interface and can be passed like a network to an algorithm. Several views are implemented in mockturtle.

topo_view: Ensure topological order¶

Header: mockturtle/views/topo_view.hpp

template<class Ntk, bool sorted = is_topologically_sorted_v<Ntk>> class topo_view¶

Ensures topological order for of all nodes reachable from the outputs.

Overrides the interface methods foreach_node, foreach_gate, size, num_gates.

This class computes on construction a topological order of the nodes which are reachable from the outputs. Constant nodes and primary inputs will also be considered even if they are not reachable from the outputs. Further, constant nodes and primary inputs will be visited first before any gate node is visited. Constant nodes precede primary inputs, and primary inputs are visited in the same order in which they were created.

Since the topological order is computed only once when creating an instance, this view disables changes to the network interface. Also, since only reachable nodes are traversed, not all network nodes may be called in foreach_node and foreach_gate.

Required network functions:

get_constant
foreach_pi
foreach_po
foreach_fanin
incr_trav_id
set_visited
trav_id
visited

Example

// create network somehow; aig may not be in topological order
aig_network aig = ...;

// create a topological view on the network
topo_view aig_topo{aig};

// call algorithm that requires topological order
cut_enumeration( aig_topo );

depth_view: Compute levels and depth¶

Header: mockturtle/views/depth_view.hpp

template<class Ntk, class NodeCostFn = unit_cost<Ntk>, bool has_depth_interface = has_depth_v<Ntk> && has_level_v<Ntk> && has_update_levels_v<Ntk>> class depth_view¶

Implements depth and level methods for networks.

This view computes the level of each node and also the depth of the network. It implements the network interface methods level and depth. The levels are computed at construction and can be recomputed by calling the update_levels method.

It also automatically updates levels, and depth when creating nodes or creating a PO on a depth_view, however, it does not update the information, when modifying or deleting nodes, neither will the critical paths be recalculated (due to efficiency reasons). In order to recalculate levels, depth, and critical paths, one can call update_levels instead.

Required network functions:

size
get_node
visited
set_visited
foreach_fanin
foreach_po

Example

// create network somehow
aig_network aig = ...;

// create a depth view on the network
depth_view aig_depth{aig};

// print depth
std::cout << "Depth: " << aig_depth.depth() << "\n";

mapping_view: Add mapping interface methods¶

Header: mockturtle/views/mapping_view.hpp

template<typename Ntk, bool StoreFunction = false, bool has_mapping_interface = implements_mapping_interface_v<Ntk, StoreFunction>> class mapping_view¶

Adds mapping API methods to network.

This view adds methods of the mapping API methods to a network. It always adds the functions has_mapping, is_cell_root, clear_mapping, num_cells, add_to_mapping, remove_from_mapping, and foreach_cell_fanin. If the template argument StoreFunction is set to true, it also adds functions for cell_function and set_cell_function. For the latter case, this view requires more memory to also store the cells’ truth tables.

Required network functions:

size
node_to_index

Example

// create network somehow
aig_network aig = ...;

// in order to apply mapping, wrap network in mapping view
mapping_view mapped_aig{aig};

// call LUT mapping algorithm
lut_mapping( mapped_aig );

// nodes of aig and mapped_aig are the same
aig.foreach_node( [&]( auto n ) {
  std::cout << n << " has mapping? " << mapped_aig.is_cell_root( n ) << "\n";
} );

cut_view: Network view on a single rooted cut¶

Header: mockturtle/views/cut_view.hpp

template<typename Ntk> class cut_view : public mockturtle::immutable_view<Ntk>¶

Implements an isolated view on a single cut in a network.

This view can create a network from a single cut in a larget network. This cut has a single output root and set of leaves. The view reimplements the methods size, num_pis, num_pos, foreach_pi, foreach_po, foreach_node, foreach_gate, is_pi, node_to_index, and index_to_node.

This view assumes that all nodes’ visited flags are set 0 before creating the view. The view guarantees that all the nodes in the view will have a 0 visited flag after the construction.

Required network functions:

set_visited
visited
get_node
get_constant
is_constant
make_signal

mffc_view: Network view on a (M)FFC¶

Header: mockturtle/views/mffc_view.hpp

template<typename Ntk> class mffc_view : public mockturtle::immutable_view<Ntk>¶

Implements an isolated view on the MFFC of a node.

The network is constructed from a given root node which is traversed towards the primary inputs. Nodes are collected as long they only fanout into nodes which are already among the visited nodes. Therefore the final view only has outgoing edges to nodes not in the view from the given root node or from the newly generated primary inputs.

The view reimplements the methods size, num_pis, num_pos, foreach_pi, foreach_po, foreach_node, foreach_gate, is_pi, node_to_index, and index_to_node.

The view requires that the nodes’ values contain their reference counts, i.e., they are assigned their fanout size. The values are restored by the view.

Required network functions:

get_node
decr_value
value
foreach_fanin
is_constant
node_to_index

immutable_view: Prevent network changes¶

Header: mockturtle/views/immutable_view.hpp

template<typename Ntk> class mockturtle::immutable_view : public Ntk ¶

Deletes all methods that can change the network.

This view deletes all methods that can change the network structure such as create_not, create_and, or create_node. This view is convenient to use as a base class for other views that make some computations based on the structure when being constructed. Then, changes to the structure invalidate these data.

Subclassed by mockturtle::cut_view< Ntk >, mockturtle::mapping_view< Ntk, StoreFunction, false >, mockturtle::mffc_view< Ntk >, mockturtle::topo_view< Ntk, false >, mockturtle::window_view< Ntk >

Public Functions

inline immutable_view(Ntk const &ntk)¶

Default constructor.

Constructs immutable view on another network.

fanout_view: Compute fanout¶

Header: mockturtle/views/fanout_view.hpp

template<typename Ntk, bool has_fanout_interface = has_foreach_fanout_v<Ntk>> class fanout_view¶

Implements foreach_fanout methods for networks.

This view computes the fanout of each node of the network. It implements the network interface method foreach_fanout. The fanout are computed at construction and can be recomputed by calling the update_fanout method.

Required network functions:

foreach_node
foreach_fanin

window_view: Network view on a window¶

Header: mockturtle/views/window_view.hpp

template<typename Ntk> class window_view : public mockturtle::immutable_view<Ntk>¶

Implements an isolated view on a window in a network.

This view creates a network from a window in a large network. The window is specified by three parameters: 1.) inputs are the common support of all window nodes, they do not overlap with gates (i.e., the intersection of inputs and gates is the empty set). 2.) gates are the nodes in the window, supported by the inputs (i.e., gates are in the transitive fanout of the inputs, 3.) outputs are signals (regular or complemented nodes) pointing to nodes in gates or inputs. Not all fanouts of an output node are already part of the window.

The second parameter gates has to be passed and is not automatically computed (for example in contrast to cut_view), because there are different strategies to construct a window from a support set. The outputs could be automatically computed.

The window_view implements three new API methods: 1.) belongs_to: takes a node (or a signal) and returns true if and only if the corresponding node belongs to the window 2.) foreach_internal_fanout: takes a node and invokes a predicate on all fanout nodes of the node that belong to the window 3.) foreach_exnteral_fanout: takes a node and invokes a predicate on all fanouts of the node that do not belong to the window

binding_view: Add bindings to a technology library¶

Header: mockturtle/views/binding_view.hpp

template<class Ntk> class binding_view : public Ntk ¶

Adds bindings to a technology library and mapping API methods.

This view adds methods to create and manage a mapped network that implements gates contained in a technology library. This view is returned by the technology mapping command map. It can be used to report statistics about the network and write the network into a verilog file. It always adds the functions has_binding, remove_binding, add_binding, add_binding_with_check, get_binding, get_binding_index, get_library, compute_area, compute_worst_delay, report_stats, and report_gates_usage.

Required network functions:

size
foreach_node
foreach_fanin
is_constant
is_pi

Example

// create network somehow
aig_network aig = ...;

// read cell library in genlib format
std::vector<gate> gates;
lorina::read_genlib( "file.genlib", genlib_reader( gates ) )
tech_library tech_lib( gates );

// call technology mapping to obtain the view
binding_view<klut_network> res = map( aig, tech_lib );

// prints stats and gates usage
res.report_stats();
res.report_gates_usage();

// write the mapped network in verilog
write_verilog( res, "file.v" );

names_view: Assign names to signals and outputs¶

Header: mockturtle/views/names_view.hpp

template<class Ntk> class names_view : public Ntk ¶

cnf_view: Creates a CNF while creating a network¶

Header: mockturtle/views/cnf_view.hpp

template<typename Ntk, bool AllowModify, bill::solvers Solver> class mockturtle::cnf_view : public mockturtle::detail::cnf_view_impl<cnf_view<Ntk, AllowModify, Solver>, Ntk, AllowModify, Solver>¶

A view to connect logic network creation to SAT solving.

When using this view to create a new network, it creates a CNF internally while nodes are added to the network. It also contains a SAT solver. The network can be solved by calling the solve method, which by default assumes that each output should compute true (an overload of the solve method can override this default behaviour and apply custom assumptions). Further, the methods model_value and pi_vmodel_alues can be used to access model values in case solving was satisfiable. Finally, methods var and lit can be used to access variable and literal information for nodes and signals, respectively, in order to add custom clauses with the add_clause methods.

The cnf_view can also be wrapped around an existing network by setting the AllowModify template parameter to true. Then it also updates the CNF when nodes are deleted or modified. This comes with an addition cost in variable and clause size.

Public Functions

inline bill::lit_type lit(node const &n) const¶: Returns the literal associated to a node.

template<typename _Ntk = Ntk, typename = std::enable_if_t<!std::is_same_v<typename _Ntk::signal, typename _Ntk::node>>> inline bill::lit_type lit(signal const &f) const¶: Returns the literal associated to a signal.

inline std::optional<bool> solve(bill::result::clause_type const &assumptions, uint32_t limit = 0)¶

Solves the network with a set of custom assumptions.

This function does not assert any primary output, unless specified explicitly through the assumptions.

The function returns nullopt, if no solution can be found (due to a conflict limit), or true in case of SAT, and false in case of UNSAT.

Parameters

assumptions – Vector of literals to be assumped when solving
limit – Conflict limit (unlimited if 0)

inline std::optional<bool> solve(int limit = 0)¶

Solves the network by asserting all primary outputs to be true.

The function returns nullopt, if no solution can be found (due to a conflict limit), or true in case of SAT, and false in case of UNSAT.

Parameters: limit – Conflict limit (unlimited if 0)

inline bool model_value(node const &n) const¶: Return model value for a node.

template<typename _Ntk = Ntk, typename = std::enable_if_t<!std::is_same_v<typename _Ntk::signal, typename _Ntk::node>>> inline bool model_value(signal const &f) const¶: Return model value for a node (takes complementation into account).

inline void block()¶: Blocks last model for primary input values.

inline uint32_t num_vars() const¶: Number of variables.

inline uint32_t num_clauses() const¶: Number of clauses.

inline void add_clause(bill::result::clause_type const &clause)¶: Adds a clause to the solver.

inline void add_clause(std::vector<signal> const &clause)¶: Adds a clause from signals to the solver.

template<typename ...Lit, typename = std::enable_if_t<std::disjunction_v<std::conjunction<std::is_same<Lit, bill::lit_type>...>, std::conjunction<std::is_same<Lit, signal>...>>>> inline void add_clause(Lit... lits)¶

Adds a clause to the solver.

Entries are either all literals or network signals.

color_view: Manages traversal IDs¶

Header: mockturtle/views/color_view.hpp

template<typename Ntk> class mockturtle::color_view : public Ntk ¶

Manager view for traversal IDs (in-place storage).

Traversal IDs, called colors, are unsigned integers that can be assigned to nodes. The corresponding values are stored in-place in the flags of the underlying of the network.

Public Functions

inline uint32_t new_color() const¶: Returns a new color and increases the current color.

inline uint32_t current_color() const¶: Returns the current color.

inline void clear_colors(uint32_t color = 0) const¶: Assigns all nodes to color

inline auto color(node const &n) const¶: Returns the color of a node.

template<typename _Ntk = Ntk, typename = std::enable_if_t<!std::is_same_v<typename _Ntk::signal, typename _Ntk::node>>> inline auto color(signal const &n) const¶: Returns the color of a node.

inline void paint(node const &n) const¶: Assigns the current color to a node.

inline void paint(node const &n, uint32_t color) const¶: Assigns color to a node.

inline void paint(node const &n, node const &other) const¶: Copies the color from other to n

template<typename Pred> inline bool eval_color(node const &n, Pred &&pred) const¶: Evaluates a predicate on the color of a node.

template<typename Pred> inline bool eval_color(node const &a, node const &b, Pred &&pred) const¶: Evaluates a predicate on the colors of two nodes.

template<typename Pred> inline bool eval_fanins_color(node const &n, Pred &&pred) const¶: Evaluates a predicate on the colors of the fanins of a node.

template<typename Ntk> class mockturtle::out_of_place_color_view : public Ntk ¶

Manager view for traversal IDs (out-of-place storage).

Traversal IDs, called colors, are unsigned integers that can be assigned to nodes. The corresponding values are stored out-of-place in this view.

Public Functions

template<typename Pred> inline bool eval_color(node const &n, Pred &&pred) const¶: Evaluates a predicate on the color of a node.

template<typename Pred> inline bool eval_color(node const &a, node const &b, Pred &&pred) const¶: Evaluates a predicate on the colors of two nodes.

template<typename Pred> inline bool eval_fanins_color(node const &n, Pred &&pred) const¶: Evaluates a predicate on the colors of the fanins of a node.