Partition based packer

[behnam-rs]

Description

Our approach combines the benefits of partitioning-based and seed-based packing algorithms (VPR). It consists of two main steps 1) a partitioning step to hierarchically divide the circuit into subcircuits, and 2) a seed-based packing step that clusters all subcircuits concurrently.

An optimal clustering solution should have a low number of clusters, high intra-cluster connections, and low inter-cluster connections. To achieve this, we employ partitioning algorithms designed for hypergraphs, where hyperedges connect more than two vertices. Logic circuits are an example of hypergraphs, with logic blocks as vertices and nets as hyperedges.

The hypergraph partitioning algorithms split the hypergraph into configurable partitions, minimizing interconnecting hyperedges between them. One well-known algorithm for this purpose is hmetis.

To adapt hmetis for molecule clustering in VPR, we split the circuit into partitions such that the number of molecules in each partition is equal to the clb (configurable logic block) capacity. However, packing molecules into a clb has more constraints than just the clb capacity. To address this, we increase the number of molecules in each partition and then use the seed-based packing algorithm inside VPR to pack the molecules within each partition. The molecules in each partition are packed only to the molecules present in that partition.

Related Issue

Motivation and Context

The current packer in VPR employs a greedy algorithm by sorting molecules into a seed array based on a configurable option (--cluster_seed_type). In each iteration, it selects the best unpacked molecule from the seed array, generates a new cluster for it, and then adds other unpacked molecules to this new cluster using a greedy algorithm. However, due to its greedy nature, the algorithm fails to explore the search space effectively, leading to the problem of getting stuck in local minima.

How Has This Been Tested?

Via our bench-marking, this feature bring better QOR.

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[vaughnbetz]

Interesting PR! Can you add QoR data on the VTR, Titan and Koios benchmark suites? See https://docs.verilogtorouting.org/en/latest/README.developers/#evaluating-quality-of-result-qor-changes for a detailed how-to guide.