FloorSet - a VLSI Floorplanning Dataset with Design Constraints of Real-World SoCs

Abstract.

Floorplanning for systems-on-a-chip (SoCs) and its sub-systems is a crucial and non-trivial step of the physical design flow. It represents a difficult combinatorial optimization problem. A typical large scale SoC with 120 partitions generates a search-space of $\sim 10^{250}$. As novel machine learning (ML) approaches emerge to tackle such problems, there is a growing need for a modern benchmark that comprises a large training dataset and performance metrics that better reflect real-world constraints and objectives compared to existing benchmarks. To address this need, we present $\mathtt{FloorSet}$  - two comprehensive datasets of synthetic fixed-outline floorplan layouts that reflect the distribution of real SoCs. Each dataset has $1M$ training samples and $100$ test samples where each sample is a synthetic floorplan. $\mathtt{FloorSet}$-Prime comprises fully-abutted rectilinear partitions and near-optimal wire-length. A simplified dataset that reflects early design phases, $\mathtt{FloorSet}$-Lite comprises rectangular partitions, with $<5\%$ white-space and near-optimal wire-length. Both datasets define hard constraints seen in modern design flows such as shape constraints, edge-affinity, grou** constraints, and pre-placement constraints. $\mathtt{FloorSet}$ is intended to spur fundamental research on large-scale constrained optimization problems. Crucially, $\mathtt{FloorSet}$ alleviates the core issue of reproducibility in modern ML driven solutions to such problems. $\mathtt{FloorSet}$  is available as an open-source repository for the research community.

1. Introduction

Circuit partitioning is the first step of the back-end physical design flow. It divides a flat, and large circuit netlist into more manageable partitions. This step defines area budgets specific to each partition, inter-partition connectivity constraints, connections to external terminals, and the respective positions of these external terminals. These outcomes define the requirements and constraints of the floorplanning step. Furthermore, the floorplanning task is governed by numerous placement constraints on a subset or all of the partitions. The goal of the floorplanning step is to determine optimal physical positions and shapes of the individual partitions comprising the SoC or a subsystem. The output from the floorplanning step serves as the starting point for the remainder of the physical design flow. Figure 1 shows the typical back-end design steps - our work directly addresses the first two steps of partition and sub-system placement.

Figure 1. Our work focuses on establishing realistic benchmarks $\mathtt{FloorSet}$, for the first two steps (shaded) of the design planning phase of the back-end flow.

Floorplan Constraints: The key challenge of the floorplanning formulation lies in the requirement to satisfy hard design constraints. Some important constraints are:

• Outline-constraint: Modern ASIC design relies on hierarchical (top-down) floorplanning, with a ”fixed-outline” constraint for the SoC and its sub-systems. A floorplan optimized for area without accounting for this constraint may fail to fit within the specified outline.

• Shape-constraints: These specify the acceptable range of width-to-height ratios of each partition’s bounding box.

• Boundary-constraints: These specify that a partition must align with a specific edge or corner of the floorplanning outline. This alignment is driven by external interfacing requirements or system-level thermal considerations.

• Grou**-constraints: These specify a set of partitions that must be physically abutted - e.g., those operating on the same voltage or requiring simultaneous power-off.

• Multi-instantiation constraints: These define multiple partitions as instances of a shared main partition - e.g., eight instances of a CPU core partition. Thus, all such instances must share the same shape.

• Pre-placement constraints: These specify pre-defined locations of partitions that are often derived from past designs.

Supervised Learning and Data Paucity: Lately, there has been remarkable advancement in deep learning, that construct large parametric approximators by combining simpler functions. Deep learning demonstrates exceptional performance - particularly in scenarios involving high-dimensional spaces and abundant data points. Therefore, learning-based approaches can serve as promising alternatives for complex combinatorial optimization problems. However, the lack of sufficient training layouts is a major impediment in utilizing supervised learning methods for floorplanning. Due to this, prior learning-based techniques are often restricted to reinforcement learning (RL) (kdd22; learnfp20; gplanner22; gfp22) to yield optimal floorplan layouts. However, such approaches struggle to simultaneously optimize the objectives and respect the hard design constraints for large-scale combinatorial optimization problems. This data paucity stems primarily from intellectual-property (IP) restrictions of the chip-design industry. Our work addresses this gap by generating a large corpus of synthetic layouts that are reflect the optimal placement statistics and design constraints of real, commercial SoCs. This dataset, $\mathtt{FloorSet}$, can serve as a comprehensive training and test set for ML based floorplanning algorithms.

Overview: The rest of the paper is organized as follows. Section 2 surveys the state of benchmarks and synthetic data in EDA. Section 3 describes our data generation pipeline, and the two dataset variants $\mathtt{FloorSet}$-Prime and $\mathtt{FloorSet}$-Lite. Section 4 summarizes the attributes of $\mathtt{FloorSet}$  and presents the complexity of the generated data. Finally, conclusions are discussed in Section 5.

2. Related Work

In recent years, an increasing number of works have applied ML to complex EDA problems (mleda23; mlcad22; dpan21). These works have targeted geometric problems (binpacking21), graph processing and optimization techniques(timinggnn22; dagsizer23), automated decision making (chipformer23; agnesia20; rlsizer21), vision-based approaches(pdn20; drc20) and natural language models (chipnemo24; chipchat23). Such ML-based solutions in the EDA flow mitigate the need for exhaustive design optimization iterations by judiciously pruning the solution space associated with sub-optimal design quality. The resulting advancements present significant strides in various design stages such as high-level logic design (hls20; hls22), circuit design (ls19; lo18), physical design (gfp22; gancts19; gr19; maskplace22), verification (verif23; fault21), and manufacturing aspects (asml) of conventional chip-design methodologies, offering notable opportunities for improvement.

EDA Benchmarks: There are several examples of open-source benchmarks for physical design tasks. E.g., IWLS 2005 benchmarks (iwls) provide a repository of $85$ synthesized RTL netlists that were collected from various public resources (opencores). For discrete gate-sizing contest, ISPD 2012 (ispd12) benchmarks annotate interconnect parasitics and timing constraints for 14 IWLS netlists. ISPD 2015 benchmarks (ispd15) provide a $65nm$ dataset that comprises eight designs with routing constraints and design rules, for the purpose of blockage-aware detailed routing-driven placement task. For the multi-deck standard cell placement legalization problem, ICCAD 2017 (iccad17) provides eight benchmarks in LEF and DEF format, along with soft placement constraints. They are derived from ISPD 2015 dataset. For the detailed routing contest of ISPD, ISPD 2018 benchmarks (ispd18) provide $10$ test designs in $32nm$ and $45nm$ nodes, extracted from two real designs. It also defines design rules such as spacing tables, end-of-line spacing rules, cut spacing rules, min-area rules, and routing preference rules. For the macro-placement task, the ISPD02 IBM-MS mixed-size placement dataset (ispd02) contains $18$ designs with both hard macros and standard cells. The TILOS-AI-Institute added four more designs to reproduce the results of the RL-based MacroPlacement algorithm (ct2021). Though these efforts help in reproducibility, the scale of these benchmarks make it unusable to train modern ML models for physical design.

Floorplanning Benchmarks: For the floorplanning task, prior datasets GSRC (gsrc) (n10, n30, n50, n100, n200, and n300), and MCNC (mcnc) (ami33, ami49, apte, xp, and xerox) offer a standardized way to validate floorplan optimization algorithms. However, these benchmarks also suffer from being small scale, making them unusable for ML applications. In addition, the constraints used in these benchmarks do not capture many modern SoC floorplan constraints such as pre-placed constraints, boundary constraints, multi-instantiated partitions, and pin and net topologies.

Synthetic Data in EDA: IP issues often make it difficult for commercial design companies to distribute their historical EDA data. Synthetic data offers a practical solution to this data paucity problem. However, for it to be usable, it needs to reflect the structural characteristics of real designs. Gupta et al. (eyecharts) proposed benchmark circuits (called eyecharts) of arbitrary size, to diagnose the weaknesses of existing gate-sizing algorithms, and to enable a systematic and quantitative comparison of sizing algorithms. In later works, Han et al. (gt14) use artificial combinational paths to extract the sign-off timing values for ground truths. The artificial circuits in their work are created by swee** the number of stages, fan-outs and segments, and cell types in timing paths. Kahng et al. (cornerpred) also use artificial circuits to train a regression model, to predict timing values at unobserved corners. Recently, PROBE2.0 (probe2) proposed an artificial circuit with a mesh-like netlist topology as a place-and-route (P&R) benchmark, for routability assessment. However, these artificial circuit timing paths do not reflect the distribution present in real circuits and, thus, do not capture the full complexity of real circuits. Kim et al. (kim23) address the aforementioned issues and introduce an artificial netlist generator (ANG) framework for constructing authentic P&R benchmarks suitable for ML. This framework generates gate-level netlists based on user-defined input parameters representing the topological attributes of realistic circuit. Our work shares a close affinity with the ANG framework, although we address the floorplanning task. To the best of our knowledge, we are the first to propose a large-scale dataset to enable ML techniques for floorplanning..

3. Methodology

3.1. Problem Formulation

The $\mathtt{FloorSet}$  benchmarks specifically target the first step of the floorplanning task within SoC and sub-system hierarchies, aiming to identify optimal shapes and positions for sub-systems and partitions while adhering to certain placement constraints. The inputs to perform floorplanning task at SoC and sub-system hierarchies constitute:

• area budgets of partitions or sub-systems.

• locations of external terminals of the system.

• netlist connectivity that define the connections between various components of the system.

• placement constraints that define pre-determined positions for some components of the system.

Figure 2. The bookshelf *.blocks file is modified to include fixed-outline dimensions, area budgets, shape constraints (aspect ratio range) and placement constraints.

The bookshelf format (bookshelf) is a widely adopted, open-source, and standardized representation of VLSI design data. The components of a floorplanning problem are captured in the *.blocks, *.nets and *.pl file formats of the bookshelf format. As shown in Figure 2, we modify the *.blocks to include component-wise placement constraints, area budgets, and fixed-outline dimensions. We include net weights in the *.nets file, shown in Figure 3. The *.pl file is unchanged and contains the $(x,y)$ locations of terminals.

Figure 3. The bookshelf *.nets file is modified to add net weights.

3.2. Distribution of Real Layouts

In this section, we outline the topological statistics derived from real industrial floorplans extracted from heterogeneous SoCs and their sub-systems, with configurations upto 100 partitions. These real floorplan layouts capture modern human-designed heterogeneous SoC and sub-system implementations in the industry. Due to the necessity of preserving the IP rights of these SoCs and their implementations, we are unable to disclose the exact layouts and their associated statistics. However, we provide the details of statistics that represent these realistic floorplan layouts. We extract $10$ parameters, listed in Table 1. These $10$ distributions allow us to systematically explore the design space and produce synthetic layouts that closely mimic real-world layouts.

The rationale for extracting these statistics is listed below:

• $\mathit{A_{parts}}$: The aspect ratio range defines the acceptable width-to-height ratio of a component (partition or sub-system based on the hierarchy). For rectilinear partitions, we derive the aspect ratio from the bounding box of the rectilinear polygon. This parameter guarantees that the generated synthetic layouts exhibit realistic shapes.

• $\mathit{R_{terms}^{parts}}$: The ratio of terminal count to partition count captures the proportion of terminals relative to partitions within a hierarchy. This offers a method to represent the proportional distribution of partitions and terminals in the floorplan netlists, without biasing towards the absolute scale of terminal count.

• $\big{\{}\mathit{D_{parts}},\mathit{D_{terms}},\mathit{W_{parts}}\big{\}}$: To quantify the complexity of connectivity structure in layouts at SoC and sub-system hierarchies, we use density (complement of sparsity) parameters of the connectivity matrices (or adjacency matrices).

  $\mathit{D_{parts}}$ and $\mathit{D_{terms}}$: These parameters capture the interconnection complexity of the floorplan netlists and provide a scale-independent mechanism to capture inter-partition and partition-terminal net connectivity. It is common to have multiple net connections (up to few thousands) between a partition pair, and weighted nets capture the strength of such connections. To account for weights on nets, we also extract the net-weight distribution,$\mathit{W_{parts}}$, as a function of net-length. The net-lengths are normalized to the fixed-outline’s circumference, and net-weights are scaled to a range of 0-1.

• $\mathit{E_{parts}}$: This captures the relative distribution of components (or partitions) with edge-affinity (or boundary affinity). These components typically represent the input-output (IO) constrained partitions or sub-systems.

• $\big{\{}\mathit{N_{clusters}},\mathit{C_{parts}}\big{\}}:$ These capture the number of voltage islands and the number of components in these island regions.

• $\mathit{P_{parts}}$: The percentage of pre-placed partitions capture the relative distribution of partitions with pre-placement constraints. These are hard constraints on the positions of partitions that are either derived from prior design knowledge or known-optimal decisions.

• $\mathit{M_{parts}}$: The percentage of multi-instantiation constraints represents the proportion of partitions enforcing shape-sharing constraints in modular design flows. E.g., in a hierarchy, if four instances of a CPU core exist, they all share the same shape and area.

Table 1. Design parameters whose values are sampled from statistical distributions derived from real SoCs.

Parameter Description $\mathit{A_{parts}}$ Aspect ratio ($=\frac{W}{H}$) of a partition’s bounding box $\mathit{N_{terms}^{parts}}$ Number of terminals in a hierarchy relative to the partition count $\mathit{D_{parts}}$ Non-zero element percentage in the inter-partition connectivity matrix $\mathit{W_{parts}}$ Inter-partition weight distribution as a function of distance $\mathit{D_{terms}}$ Non-zero element percentage in the terminal partition connectivity matrix $\mathit{E_{parts}}$ Percentage of partitions with edge and corner constraints $\mathit{C_{parts}}$ Percentage of partitions with grou** (or clustering) constraints $\mathit{N_{clusters}}$ Number of clusters in a hierarchy $\mathit{P_{parts}}$ Percentage of partitions with preplaced positions $\mathit{M_{parts}}$ Percentage of partitions with multi-instantiation constraint

3.3. $\mathtt{FloorSet}$-Prime: Rectilinear Partitions

Figure 4. The distribution of parameters (Table 1) and the custom configuration file serve as inputs for the data generation pipeline. The output layouts are formatted in the standard bookshelf format and Pytorch tensor format.

Figure 5. Overview of the five-step $\mathtt{FloorSet}$  data generation framework, illustrating the sequential processes involved in the methodology: 1. Collection and extraction of target layout distributions, 2. Partitioning shapes with the target area budgets, 3. Annotation of terminal locations, 4. Annotation of connectivity matrix (weighted), and 5. Annotation of placement.

In this section, we present the mechanism to generate synthetic layouts, using the floorplan statistics extracted from real layouts. Figure 4 provides an overview of the $\mathtt{FloorSet}$generation framework at a high-level. The circuit statistics extracted are utilized as an input for our data generation framework. In addition, the second input to the $\mathtt{FloorSet}$data generation pipeline is a custom input configuration file (shown in Figure 4), that contains the following settings:

• num_layouts: to specify the number of floorplan layouts to be generated.

• foutline_shape: to sweep the desired shape of the fixed-outline.

• num_partitions: to sweep the target partition count.

• rectilinear_flag: to enable or disable rectilinear partitions in the layout.

• placement_constraints_flag: to enable or disable annotation of hard placement constraints.

• dataset_mode flag: to select between the available dataset pipelines ($\mathtt{FloorSet}$-Prime and $\mathtt{FloorSet}$-Lite).

The output of this data generation framework comprises layouts in Bookshelf and Pytorch tensor formats, representing diverse instances of floorplan problems. Expanding on the previous Figure 4, Figure 5 explains the $\mathtt{FloorSet}$  data generation framework using the following five important steps that are described below: Parameter Extraction, Partition Sampling, Terminal Sampling, Connectivity Sampling and Constraints Sampling.

The pseudocode of $\mathtt{FloorSet}$  data generation pipeline is presented in Algorithm 1. To recap, the inputs to the framework are target distributions extracted from real floorplan circuits, and input configuration file to sample the design parameters. The output of the Algorithm 1 is a repository of synthetic floorplan layouts in the Bookshelf format and a tensor-based representation that is compatible with data loader libraries commonly used in ML applications.

1. Parameter Extraction: From a repository of several industrial floorplan layouts sourced from diverse SoC and subsystem implementations, we extract statistical metrics (listed in Table 1) representative of the circuit characteristics inherent to modern SoC and sub-system layouts. These metrics establish the target distribution from which we sample to produce synthetic floorplan layouts. To capture connectivity characteristics, we extract the density (complement of sparsity) distribution of inter-partition ($\mathit{D_{parts}}$) and partition-terminal ($\mathit{D_{terms}}$) adjacency matrices. In addition, we extract the relative proportion of terminal-count ($\mathit{N_{terms}^{parts}}$) to represent the scale of terminal count as a function of partition count in a hierarchy, and the the distribution of net-weights as a function of net-lengths ($\mathit{W_{parts}}$). Moreover, statistics regarding partition-specific aspect ratios ($\mathit{A_{parts}}$) and placement constraints ($\mathit{E_{parts}}$, $\mathit{C_{parts}}$, $\mathit{N_{clusters}}$, $\mathit{P_{parts}}$, $\mathit{M_{parts}}$) are also extracted from real layouts. The extracted statistics serve as the input to Algorithm 1. Lines 1-2 initialize the ”Layouts” database and index variables. Line 3 is a loop for generating $n\_layouts$. We use tensor F representation internally, to store the layout information (line 4).

2. Partition Sampling: Following step 1, the next step (line 5) involves swee** (or extracting) the desired fixed-outline dimensions from the input configuration file. Using this sampled outline, the synthetic layout undergoes decomposition into individual partitions or subsystems. To introduce variability, a mesh-layout (line 7 of Algorithm 1) is created by employing a sequence of randomly sampled vertical and horizontal lines (line 6 of Algorithm 1). These randomly positioned vertical and horizontal lines segment the fixed-outline layout into rectangles, forming the initial partition grid. Subsequently, adjacent polygons are merged, to create partition shapes that match the desired target distribution of partition shapes. To ensure sufficient room for the creation of desired shapes and area budgets, we start with a large partition count ($4\times-6\times$ of the desired partition count) on the initial grid (line 6 of of Algorithm 1). The randomized selection of merging candidates and randomized initial grid creation offer a systematic approach to sampling numerous potential fully-abutted divisions of the fixed-outline layout, exposing complex but realistic use-cases. The details of the merging process is elaborated in Algorithm 2. As shown in line 2 and line 9 of Algorithm 2, polygons on the layout are iteratively merged until the desired shapes and partition count are achieved. If rectilinear_flag = 0 (line 4), the merging operation ensures that generated partitions are always rectangles. Conversely, when the flag is set to 1, there are no restrictions on the rectilinearity of the shapes. Each merging operation is committed if the merged partition operation improves the alignment between the current shape distribution and the target shape distribution (lines 7 and 8).

Figure 6. A sequence of merging operations, to generate the channel-less layout with desired shapes and area budgets.

3. Terminal Sampling: After the creation of the fully-abutted layout, we annotate the terminal positions on the outline (line 9 of Algorithm 1). Illustrated in Figure 7 and Algorithm 3, this terminal annotation process involves first placing a terminal at a random location along the outline (line 3 of Algorithm 3). Subsequently, other terminals are incrementally placed (line 6 of Algorithm 3), while adhering to the normalized-pitch considerations (line 8 of Algorithm 3) and meeting the total terminal-count quota.

Figure 7. A sequence of terminal-annotation operations, to place terminals on the layout from Step 1.

4. Connectivity Sampling: Following the placement of desired partition shapes (or sub-systems), and terminal locations, we create the connectivity between partitions and terminals (line 10 of Algorithm 4). The details of connectivity annotation are explained in Algorithm 4. While decomposing the fixed outline into individual partitions implicitly ensures area-optimal layouts, a optimal-by-construct annotation of connectivity is necessary to generate an optimal or near-optimal connectivity matrix. To achieve this, we utilize the pair-wise distance matrix among all partition pairs, as well as partition and terminal combinations (lines 4-5 of Algorithm 4). The inverse of the distance matrix yields the ”similarity matrix,” which denotes the proximity of modules in $2$D Manhattan space (lines 6-7 of Algorithm 4). Since the optimal layouts tend to place heavily connected partitions closer, annotating connections using the similarity matrix as the probabilities (line 8-9 of Algorithm 4) offers a rational approach to ensuring the near-optimality of generated connections. In addition, we also sample inter-partition net-weights from the target distribution that captures net-weights as a function of inter-partition distance. using the similarity matrix. Figure 8 visually explain the annotation of weighted inter-partition nets and partition-terminal nets, that meet the target sparsity for inter-partition and partition-net connections.

Figure 8. Using the layouts with partition and terminals placed, connections are added using probabilities proportional to the closeness (Manhattan distance) of components.

5. Constraint Sampling: The output from Step 4 embodies the circuit characteristics of real layouts in terms of near-optimal connectivity and optimal area. Line 11 of Algorithm 1 is the constraint annotation step, where the desired placement constraints are annotated on the area and wire-length optimal layouts. The resulting layout manifests as a hard-constrained floorplanning instance with optimal area and nearly optimal wire-length characteristics. Further details on constraint annotation are provided in Algorithm 5. Utilizing the connectivity information and the optimal positions of individual partitions, boundary constraints such as corner partitions and edge partitions are annotated (line 7 of Algorithm 5). In real circuits, it is commonly observed that the majority of pre-placed partitions reside towards the periphery, and therefore we annotate pre-placed constraint, with a higher affinity for partitions that are placed on the periphery of the layout (line 8 of Algorithm 5). Line 9 of Algorithm 5 annotates the clustering constraint on a subset of partitions that are strongly connected (physical-adjacency requirement). Finally, multi-instantiated constraints are enforced on a subset of partitions that share identical shape and area values (line 10 of Algorithm 5). Figure 9 illustrates the process of constraint annotation.

Figure 9. Using the layouts with optimal shapes and locations, placement constraints are annotated. We also use connectivity from Step 4, to determine edge affinity.

Algorithm 1 $\mathtt{FloorSet}$-Prime: Generating optimal layouts with constraint annotation

0:  Input Configuration: $I_{config}$ = num_layouts, foutline_shape, num_partitions, rectilinear_flag, placement_constraints, dataset_mode = Prime Target distribution: $(\mathit{A_{parts}},\mathit{N_{terms}^{parts}},\mathit{D_{parts}},\mathit{W_{parts}},\mathit{D_{terms}},$ $\mathit{E_{parts}},\mathit{C_{parts}},\mathit{N_{clusters}},\mathit{P_{parts}},\mathit{M_{parts}})$

1:  $Layouts=\emptyset$

2:  $index=0$

3:  while $index<num\_layouts$  do

4:     $\textbf{F}=\emptyset$ Internal geometric representation of the layout

5:     $W,H,n\_parts\leftarrow sample(foutline\_shape,num\_partitions)$ Fixed-outline dimensions & number of partitions

6:     $n\_grids\leftarrow random(4,6)*n\_parts$ Initial partition count

7:     $\textbf{F}\leftarrow createMESH(n\_grids,W,H)$ Random partitioning of the layout in to n_grids

8:     $\textbf{F}\leftarrow mergePARTITION(n\_parts,\mathit{A_{parts}},rectilinear\_flag,\textbf{F})$ Merging of partitions to get target shapes

9:     $\textbf{F}\leftarrow annotateTERMINALS(\mathit{N_{terms}^{parts}},n\_parts,term\_pitch\textbf{F})$ Annotate terminals on the outline of the layout

10:     $\textbf{F}\leftarrow annotateNETS(\mathit{D_{parts}},\mathit{D_{terms}},\mathit{W_{parts}},n\_parts,\textbf{F})$ Create connections among partitions and terminals

11:     if placement_constraints == 1 then

12:        $\textbf{F}\leftarrow annotateCONSTRAINTS(\mathit{E_{parts}},\mathit{C_{parts}},\mathit{N_{clusters}},\mathit{P_{parts}},$ $\mathit{M_{parts}},\textbf{F})$ Annotate placement constraints on the partitions

13:     $index+=1$

14:     $blocks,nets,pl\leftarrow convertBOOKSHELF(\textbf{F})$

15:     $Layouts[index]=[blocks,nets,pl,\textbf{F}]$

Algorithm 2 Merging of partitions: mergePARTITION

0:  $n\_parts,\mathit{A_{parts}},rectilinear\_flag,\textbf{F}$

1:  $part\_count=countPolygons(\textbf{F})$

2:  while $part\_count>n\_parts$ do

3:     $\textbf{F\_new}\leftarrow removeRandomEdge(\textbf{F})$

4:     if $rectilinear\_flag==0$ then

5:        if checkRectilinear(F_new) then

6:           continue

7:     if wassertsteinDist(F_new, T) ¡ wassertsteinDist(F, T) then

8:        $\textbf{F}\leftarrow\textbf{F\_new}$

9:        $part\_count=countPolygons(\textbf{F})$

10:  return F

Algorithm 3 Annotation of terminals: annotateTERMINALS

0:  $\mathit{N_{terms}^{parts}},n\_parts,\textbf{F}$

1:  $n\_terms=int(n\_parts*\mathit{N_{terms}^{parts}})$

2:  $term\_count=0$

3:  $W,H\leftarrow extractOutline(\textbf{F})$

4:  $term\_pitch=2*(W+H)/n\_terms$

5:  $tx,ty\leftarrow randomPointOnOutline(\textbf{F})$

6:  $term\_count+=1$

7:  $TermList[term\_count]=[tx,ty]$

8:  while $term\_count<n\_terms$ do

9:     $tx,ty\leftarrow randomPointOnOutline(\textbf{F})$

10:     if $minDist(TermList,[tx,ty])\geq term\_pitch$ then

11:        $term\_count+=1$

12:        $TermList[term\_count]=[tx,ty]$

13:  $\textbf{F}\leftarrow addTermLocs(TermList)$

14:  return F

Algorithm 4 Annotation of Connectivity: annotateNETS

0:  $\mathit{D_{parts}},\mathit{D_{terms}},\mathit{W_{parts}},\textbf{F}$

1:  $n\_b2b\_nets=int(n\_parts*\mathit{D_{parts}})$Number of inter-partition nets

2:  $n\_t2b\_nets=n\_nets*\mathit{D_{terms}}$ Number of partition-terminal nets

3:  $PDist\leftarrow pairwiseB2BDistance(\textbf{F})$

4:  $TDist\leftarrow pairwiseT2BDistance(\textbf{F})$Extract Manhattan distance

5:  $PSim\leftarrow 1-Normalize(PDist)$

6:  $TSim\leftarrow 1-Normalize(TDist)$Probabilities measured as inverse of distance

7:  $b2bConnectivity\leftarrow Sample(\textbf{F},size=n\_b2b\_nets,p=PSim)$

8:  $b2bweights\leftarrow Sample(\mathit{W_{parts}},size=n\_b2b\_nets,p=PSim)$

9:  $t2bConnectivity\leftarrow Sample(\textbf{F},size=n\_p2b\_nets,p=TSim)$

10:  $\textbf{F}\leftarrow addNets(b2bConnectivity,b2bweights,t2bConnectivity)$Sample net-weights and net-connections using probabilities

11:  return F

Algorithm 5 Annotation of Placement Constraints: annotateCONSTRAINTS

0:  $\mathit{E_{parts}},\mathit{C_{parts},\mathit{N_{clusters}},\mathit{P_{parts}},\mathit{M_{parts}}}\textbf{F}$

1:  $n\_boundary\_parts=int(n\_parts*\mathit{E_{parts}})$

2:  $n\_clustered\_parts=int(n\_parts*\mathit{C_{parts}})$

3:  $n\_preplaced\_parts=int(n\_parts*\mathit{P_{parts}})$

4:  $n\_multi\_inst\_parts=int(n\_parts*\mathit{M_{parts}})$

5:  $eDist\leftarrow inverseedgeDistances(\textbf{F})$

6:  $cDist\leftarrow connectivity(\textbf{F})$

7:  $\textbf{F\_e}\leftarrow getEdgeParts(\textbf{F})$

8:  $bParts\leftarrow Sample(\textbf{F\_e},size=n\_boundary\_parts,p=cDist)$

9:  $pParts\leftarrow Sample(\textbf{F},size=n\_preplaced\_parts,p=eDist)$

10:  $cParts\leftarrow deriveClusters(\textbf{F},n\_clustered\_parts,\mathit{N_{clusters}})$

11:  $mParts\leftarrow deriveMultiInst(\textbf{F},n\_multi\_inst\_parts)$

12:  $\textbf{F}\leftarrow addConstraints(bParts,cParts,pParts,mParts)$

13:  return F

Special case of $\mathtt{FloorSet}$-Prime (rectilinear_flag = 0): Although we observe that partition shapes or sub-system shapes in real circuits are rectilinear, the current literature is far from handing arbitrarily rectilinear partitions under hard constraints. Therefore, we provide a mechanism to generate a simpler case of the$\mathtt{FloorSet}$-Prime dataset by setting rectilinear_flag to $0$. The layouts thus generated will be fully abutted rectangular shapes. The near-optimal connectivity and annotation of hard constraints remain unchanged.

3.4. $\mathtt{FloorSet}$-Lite: Rectangular Partitions

Fully abutted, rectilinear shapes of partitions in a SoC or a sub-system typically emerge in the later stages of floorplanning. Such rectilinear shapes truly capture the complexity of industrial floorplanning formulation. However, in the initial design exploration stages, designers commonly begin with rectangular partitions, prioritizing finding optimal locations and early design goals (e.g., timing budgets and area requirements). At this stage, the assumption of rectangular partitions often results in the formation of channels or white-spaces. This use-case is also an important problem for design-space exploration, although less challenging than the fully-rectilinear counterpart. Therefore, we introduce an additional dataset, $\mathtt{FloorSet}$-Lite, to reflect such scenarios. The pseudocode of $\mathtt{FloorSet}$-Lite pipeline is shown in Algorithm 6. While $\mathtt{FloorSet}$-Prime decomposes the fixed-outline layout into fully-abutted rectilinear partitions, $\mathtt{FloorSet}$-Lite allows for gaps or whites-paces on the layout, to accommodate the rectangular assumption of partitions. As a result, we employ a slight change in the data generation pipeline to generate layouts with white-space while maintaining near-optimal characteristics of area and wire-length. It is well established that heuristic search algorithms such as Simulated Annealing (SA) excel at the unconstrained floorplanning problem (adya01; adya03), particularly when the joint objective of wire-length and area is removed. When the focus shifts solely to minimizing white-space, SA demonstrates exceptional performance. Therefore, as shown in line 6 of Algorithm 6, we use SA to generate a packing solution for rectangular partitions while respecting the provided fixed-outline aspect ratio. This solution is near-optimal by construction in terms of area, with some white-space (primarily because of the rectangular assumption). As shown in lines 7-11, the rest of the process (terminal annotation, connectivity annotation and placement-constraint annotation) is identical to that of $\mathtt{FloorSet}$-Prime. Similar to the $\mathtt{FloorSet}$-Prime flow, $\mathtt{FloorSet}$-Lite uses the configuration file (Figure 4) to generate 1M training samples and 100 validation test cases.

Algorithm 6 $\mathtt{FloorSet}$-Lite: Generating optimal layouts with constraint annotation

0:  Input Configuration: $I_{config}$ = num_layouts, foutline_shape, num_partitions, rectilinear_flag, placement_constraints, dataset_mode = Prime Target distribution: $(\mathit{A_{parts}},\mathit{N_{terms}^{parts}},\mathit{D_{parts}},\mathit{W_{parts}},\mathit{D_{terms}},$ $\mathit{E_{parts}},\mathit{C_{parts}},\mathit{N_{clusters}},\mathit{P_{parts}},\mathit{M_{parts}})$

1:  $Layouts=\emptyset$

2:  $index=0$

3:  while $index<num\_layouts$  do

4:     $\textbf{F}=\emptyset$ Internal geometric representation of the layout

5:     $W,H,n\_parts\leftarrow sample(foutline\_shape,num\_partitions)$ Fixed-outline dimensions & number of partitions

6:     $\textbf{F}\leftarrow runSA(W,H,n\_parts,\mathit{A_{parts}})$ Run Parquet (Simulated Annealing) for area optimization

7:     $\textbf{F}\leftarrow annotateTERMINALS(\mathit{N_{terms}^{parts}},n\_parts,term\_pitch\textbf{F})$

8:     $\textbf{F}\leftarrow annotateNETS(\mathit{D_{parts}},\mathit{D_{terms}},\mathit{W_{parts}},n\_parts,\textbf{F})$

9:     if placement_constraints == 1 then

10:        $\textbf{F}\leftarrow annotateCONSTRAINTS(\mathit{E_{parts}},\mathit{C_{parts}},\mathit{N_{clusters}},\mathit{P_{parts}},$ $\mathit{M_{parts}},\textbf{F})$

11:     $index+=1$

12:     $blocks,nets,pl\leftarrow convertBOOKSHELF(\textbf{F})$

13:     $Layouts[index]=[blocks,nets,pl,\textbf{F}]$

4. Experiments

4.1. Analysis of FloorSet

While the $1$M synthetic training layouts in $\mathtt{FloorSet}$-Prime and $\mathtt{FloorSet}$-Lite are intended for training ML models, we reserve the $100$ test cases in each dataset to be used as a standard benchmark. In each dataset, the following labels serve as performance metrics: (a) area, (b) weighted wire-lengths (inter-partition and partition-to-terminal), and (c) violation count for each of the five placement constraints. E.g., if tensor F represents the validation dataset, one can retrieve the metric list of test-case $i$ using F[$i$][”labels”]. The metric list has three components, in a list format [area, inter-partition wire-length, terminal-to-partition wire-length]. Since the dataset is devoid of constraint violations by construction, we do not explicitly store the violation count.

To underscore the complexity of $\mathtt{FloorSet}$, we run classical SA (btree06) with a constraint-penalty on the $\mathtt{FloorSet}$  validation set. Figure 10 presents scatter plots (left) for one data-point from the validation sets of $\mathtt{FloorSet}$-Prime (top) and $\mathtt{FloorSet}$-Lite (bottom). The relative area and wire-length are derived using the corresponding metrics from $\mathtt{FloorSet}$ as the baseline; the golden layout on this relative scale is indicated by the green dot at ($1$, $1$). For $\mathtt{FloorSet}$-Prime, we observe that the solutions are significantly sub-optimal in terms of wire-length and area. Crucially, all solutions exhibit constraint violations. While solutions obtained on $\mathtt{FloorSet}$-Lite’s problem are closer to the optimal in terms of area, minimizing wire-length and fixing constraint violations remain a big challenge. The desired behavior of any future baseline is to approach the green dots, while respecting the hard-constraints. Figure 10 also shows the layout images of the corresponding golden data. The top-right figure shows an example 25-partition $\mathtt{FloorSet}$-Prime layout (corresponding to the green dot on top-left figure). The bottom-right figure shows an example 65-partition $\mathtt{FloorSet}$-Lite layout (corresponding to the green dot on bottom-left figure). The synthetic layout of $\mathtt{FloorSet}$-Prime (top-right) closely resembles partition shapes in real-word layouts.

Figure 10. Scatter plots (left) and the corresponding constraint annotated optimal layouts (right) indicating the optimality gap and violations of hard constraints, when applying classical SA on a test cases picked from the validation set of $\mathtt{FloorSet}$-Prime (top) and $\mathtt{FloorSet}$-Lite (bottom). On $\mathtt{FloorSet}$-Lite, SA is able to find more area-optimal placements compared to $\mathtt{FloorSet}$-Prime - consistent with the former’s simplified rectangular partitions. However, almost all solutions discovered by SA on both datasets have constraint violations.

4.2. Distributions of $\mathtt{FloorSet}$ Characteristics

While Section 4.1 underscores the complexity of $\mathtt{FloorSet}$-Prime benchmarks and highlights the sub-optimal performance of existing methods, it remains essential to establish the resemblance between these complex synthetic layouts and real-world counterparts in terms of their circuit characteristics. Figure 11 compares the probability density function (PDF) of synthetic and real layouts using their shape and connectivity metrics. The left plot depicts the partition-level shape distribution by plotting the PDF with respect to the aspect ratios of individual partitions. The proximity of real PDF (red) and the $\mathtt{FloorSet}$-Prime PDF (black) is a clear indication of the resemblance between the shapes of synthetic and real layouts. Similarly, the plot on the right shows the PDF of inter-partition wire-length. The normalization of wire-length allows for a direct comparison. The closeness of the red and black curves illustrates that the synthetic layouts closely reflect the inherent connectivity distribution observed in real-world layouts.

Figure 11. Comparison between distributions of partition characteristics in $\mathtt{FloorSet}$  vs real designs. Distributions of aspect ratio (left) and inter-partition wire-length (right) in $\mathtt{FloorSet}$  closely match that of real SoC designs.

5. Conclusions

This paper introduces FloorSet, a VLSI floorplanning dataset that reflects the complexities and constraints of modern SoC design. Crucially, it provides large-scale training data that is necessary to develop modern ML techniques to solve floorplanning problems. $\mathtt{FloorSet}$-Lite, with near-optimal packing and wire-length for rectangular partitions, represents early stages of design. $\mathtt{FloorSet}$-Prime, with the added complexity of fully-abutted rectilinear blocks, represents the final stages of design. $\mathtt{FloorSet}$ is constructed by sampling outline and wire-length values from distributions derived from real, commercial SoC designs. We hope that $\mathtt{FloorSet}$ spurs novel solutions in the area of complex combinatorial optimization that significantly advance the field of EDA.