AiEDA/iDATA

Dataset

<p align="center"> <img src="iDATA.png" width="30%" alt="iDATA" /> A dataset of AI + EDA </p>

iDATA is a dataset of AI + EDA, which can be used to train AI models for design PPA prediction, PPA-aware physical design, and related tasks.

Dataset structure

Describe the dataset structure.

aes/
├── iEDA_route_process_data/    # Process data exported by iEDA-iRT 2D routing
├── syn_netlist/                # The synthesized netlist files、sdc files
├── place/          # The place stage def、sdc、vectors
└── route/          # The route stage def、sdc、vectors
    ├── rpt/        # The spef files
    ├── vectors/    # Stage-specific feature data
    ├── aes_a_route_congestion_best.def      # Routed def
    ├── aes_a_route_congestion_best.v        # Routed verilog
    └── ...    # more routed def/sdc

The def and verilog file name contain:

• —'a' meaning that the synthesized netlist is used area effort strategy.
• —'b' meaning that the synthesized netlist is used to ppa balance strategy.
• —'n' meaning that the synthesized netlist is used to no optimize strategy.
• —'p' meaning that the synthesized netlist is used to power effort strategy.
• —'t' meaning that the synthesized netlist is used to timing effort strategy.
• —'congestionbest_' meaning the place stage def is the best one with the lowest congestion.
• —'congestionworst_' meaning the place stage def is the worst one with the highest congestion.
• —'HPWLbest_' meaning the place stage def is the best one with the lowest HPWL.'
• —'HPWLworst_' meaning the place stage def is the worst one with the highest HPWL.
• —'_invs' meaning the physical design tool using commercial tool.
• —Besides the above four, default placement tool results are also output, e.g., 'aesaplace'.

The iEDA_route_process_data/ directory contains routing process data for 25 layouts: 5 netlists from the same design × 5 placements per netlist.

The vectors/ directory contains feature data for each strategy design.

Dataset creation

Source data

The source data is collected from oscc-ip, iscas89, OpenRoad, and OpenLane.

Data processing

The data processing uses the AiEDA toolkit.The following steps show how to use the toolkit to process the data:

• —SDC preprocessing: run python AiEDA/test/process_sdc_files.py --dataset-dir <dataset_dir> to automatically generate placement and routing SDC files with/without set_propagated_clock [all_clocks] (written to place/ and route/, respectively).
• —Batch placement runs: execute python AiEDA/test/test_sky130_place.py --design-list <json> (add --summary-out, --first-class-only, etc. if needed). The script drives iEDA according to the workspace, Verilog, SDC, and SPEF entries in the design list to perform floorplan→route; outputs are saved in each workspace under output/iEDA/. The design list is an array where each item must include at least design, workspace, verilog, and sdc, and may optionally include spef, clk_port_name, etc. Example:

  [
    {
      "design": "gcd",
      "workspace": "/path/to/workspaces",
      "verilog": "/path/to/syn_netlist/gcd.v",
      "sdc": "/path/to/syn_netlist/gcd_place.sdc",
      "spef": "",
      "clk_port_name": ["clk"]
    }
  ]

• —Batch extract placement features: run python AiEDA/test/batch_extract_place_features.py --dataset-dir <dataset_dir> --design-type <such as _a_place_congestion_best> [--patch-row-step N --patch-col-step M]. The design type is the name pattern of def. For each design, this script calls DataGeneration.generate_vectors(..., is_placement_mode=True) on place/*.def files and writes results to output/iEDA/vectors/place.
• —Batch extract routing features: run python AiEDA/test/batch_extract_route_features.py --dataset-dir <dataset_dir> --design-type <such as _a_route_congestion_best> [--patch-row-step N --patch-col-step M]. The design type is the name pattern of def. This reads DEF/SDC/SPEF from the routing stage and generates features under output/iEDA/vectors/route.

Dataset Description

Foundation Data: Net

• —Example File Path: vectors/nets/net_0.json
• —Data Generation Mechanism:
• —The Vectorization::buildFeature function is called to invoke buildLayoutData and buildGraphData to construct the foundational data.
• —generateFeature is called to generate net features, including timing features, DRC features, and statistical features.
• —Finally, the data is saved via _data_manager.saveData, where Net data is saved to the nets directory using the VecLayoutFileIO::saveJsonNets method.
• —Batch processing mode is supported; depending on the batch_mode parameter, a single file can save one or multiple nets.

• —Data Structure Example:

  {
    "id": 0,
    "name": "Net Name",
    "feature": {
      "llx": 79680,
      "lly": 68880,
      "urx": 82320,
      "ury": 74880,
      "wire_len": 11040,
      "via_num": 6,
      "drc_num": 0,
      "drc_type": [],
      "R": 19.71428571428571,
      "C": 0.0034665075873600007,
      "power": 1.1747088838172315e-07,
      "delay": 0.029491537147148576,
      "slew": 0.009644028041781348,
      "aspect_ratio": 2,
      "width": 2640,
      "height": 6000,
      "area": 15840000,
      "volume": 31680000,
      "layer_ratio": [0.0, 0.0, 0.2800000011920929, ...],
      "place_feature": {
        "pin_num": 2,
        "aspect_ratio": 2,
        "width": 2195,
        "height": 3507,
        "area": 7697865,
        "l_ness": 1.0,
        "hpwl": 5702,
        "rsmt": 5702
      }
    },
    "pin_num": 2,
    "pins": [
      {
        "id": 0,
        "i": "Cell Instance Name",
        "p": "Pin Name",
        "driver": 1
      }
    ],
    "wire_num": 11,
    "wires": [
      {
        "id": 0,
        "feature": {
                "wire_width": 140,
                "wire_len": 960,
                "wire_density": null,
                "drc_num": 0,
                "R": 0.8571428571428577,
                "C": 4.6356008480000124e-05,
                "power": 8.727133642824888e-07,
                "delay": 0.0022083051501257146,
                "slew": 6.621690001873404e-11,
                "congestion": 4.5,
                "drc_type": []
        },
        "wire": {
                "id1": 742163,
                "x1": 81360,
                "y1": 74880,
                "real_x1": 81360,
                "real_y1": 75055,
                "r1": 312,
                "c1": 339,
                "l1": 2,
                "p1": -1,
                "id2": 1316755,
                "x2": 81360,
                "y2": 74880,
                "real_x2": 81360,
                "real_y2": 75055,
                "r2": 312,
                "c2": 339,
                "l2": 4,
                "p2": -1,
                "via": 5
          },
        "path_num": 1,
        "paths": [
          {
                    "id1": 742163,
                    "x1": 81360,
                    "y1": 74880,
                    "real_x1": 81360,
                    "real_y1": 75055,
                    "r1": 312,
                    "c1": 339,
                    "l1": 2,
                    "p1": -1,
                    "id2": 1316755,
                    "x2": 81360,
                    "y2": 74880,
                    "real_x2": 81360,
                    "real_y2": 75055,
                    "r2": 312,
                    "c2": 339,
                    "l2": 4,
                    "p2": -1,
                    "via": 5
          }
        ],
        "patch_num": 2,
        "patchs": [528, 529]
      }
    ],
    "routing_graph": {
      "vertices": [
            {
                "id": 0,
                "is_pin": 0,
                "is_driver_pin": 0,
                "x": 81360,
                "y": 75055,
                "layer_id": 2
            }
      ],
      "edges": [
            {
                "source_id": 0,
                "target_id": 1,
                "path": [
                    {
                        "x": 81360,
                        "y": 75055,
                        "layer_id": 2
                    },
                    {
                        "x": 82320,
                        "y": 75055,
                        "layer_id": 2
                    }
                ]
            }
      ]
    }
  }

• —Field Descriptions:

• —Data Usage:
• —Provides the geometric and electrical characteristics of nets for physical design analysis.
• —Supports timing analysis with key parameters like resistance, capacitance, delay, and slew.
• —Used for DRC checks and violation analysis.
• —Power estimation and optimization.
• —Routing density and congestion analysis.
• —Provides training data for machine learning models to predict net performance.

• —Data Characteristics:
• —Contains multi-level net information, from macroscopic bounding boxes to microscopic wire segment details.
• —Integrates geometric, electrical, and timing characteristics.
• —Supports feature analysis for both placement and routing stages.
• —Stored in JSON format for easy parsing and processing.
• —Provides a complete routing graph structure, facilitating graph-based analysis and algorithm optimization.

Foundation Data: Path

• —Example File Path: vectors/wire_paths/wire_path_1.json

• —Data Generation Mechanism:
• —First, foundational data is built using buildLayoutData and buildGraphData.
• —The buildFeatureTiming method of the VecFeature class is called for timing feature extraction.
• —eval_tp->runVecSTA() is executed to perform a detailed timing analysis.
• —Specifically, the reportWirePaths() function generates detailed path data by traversing paths in the timing graph.
• —Finally, the data is saved in JSON format to the wire_paths directory through file I/O operations.

• —Data Structure Example: Path data uses a JSON array format, organizing the nodes and delay arcs of a path in chronological order. Each element in the array is a JSON object representing an element in the path (a node or an arc).

  [
    {
      "node_0": {
        "Point": "dpath/b_reg/_147_:CLK (sky130_fd_sc_hs__dfxtp_1)",
        "Capacitance": 0.003,
        "slew": 0.0,
        "trans_type": "rise"
      }
    },
    {
      "inst_arc_0": {
        "Incr": 0.238
      }
    },
    {
      "node_1": {
          "Point": "dpath/b_reg/_147_:Q (sky130_fd_sc_hs__dfxtp_1)",
          "Capacitance": 0.018471882955040004,
          "slew": 0.134413,
          "trans_type": "rise"
      }
    },
    {
      "net_arc_1": {
          "Incr": 0.000476,
          "edge_0": {
              "wire_from_node": "dpath/b_reg/_147_:Q",
              "wire_to_node": "dpath/a_lt_b$in1[15]:847926",
              "wire_R": 0.0,
              "wire_C": 0.0,
              "from_slew": 0.134413,
              "to_slew": 0.134413,
              "wire_delay": 0.0
          },
          // more edges...
      }
    }
    // more nodes and arcs...
  ]

• —Field Descriptions:

• —Data Usage:
• —Timing Analysis: Provides detailed path delay information for analyzing and optimizing the design's timing performance.
• —Signal Integrity Assessment: Includes signal transition times and net RC parameters, supporting signal integrity analysis.
• —Power Analysis: Based on node capacitance and toggle rates, dynamic power can be calculated.
• —Path Visualization: The data structure facilitates the graphical representation and analysis of paths.
• —Timing Closure Verification: Used to verify that the design meets timing constraints.
• —Machine Learning Model Training: Provides training data for predicting path delays, signal integrity, and other issues.

• —Data Characteristics:
• —Temporal Order: Elements in the array are strictly arranged in the chronological order of signal propagation.
• —Alternating Structure: Nodes (node_*) and arcs (inst_arc_*/net_arc_*) appear alternately, forming a complete path.
• —Incremental IDs: The IDs of nodes and arcs increase sequentially along the path, making it easy to trace the signal flow.
• —Hierarchical Details: Net arcs contain nested, detailed wire segment information (edge_*), providing fine-grained interconnect characteristics.

Foundation Data: Graph

• —Example File Path: vectors/wire_graph/timing_wire_graph.json

• —Data Generation Mechanism:
• —Data Preparation: In the Vectorization::buildFeature method, _data_manager.buildLayoutData() is first called to build layout data, followed by _data_manager.buildGraphData() to construct the initial graph data structure.
• —Feature Extraction: The generateFeature() method is called to create a VecFeature object, and feature.buildFeatureTiming() generates timing-related features.
• —Timing Analysis: The runVecSTA method (called on an InitSTA::getInst() instance via eval_tp->runVecSTA()) performs a detailed timing analysis to calculate key parameters like arrival times and required times for nodes.
• —Data Saving: Finally, the _data_manager.saveData() method saves the generated Graph data as a JSON file.

• —Data Structure Example: Graph data is organized in JSON format, using a standard graph data structure to represent the net connection relationships in the chip design.

  {
      "nodes": [ // Array of nodes, representing pins, ports, and routing nodes
        {
            "id": "node_0",
            "name": "clk",
            "is_pin": false,
            "is_port": true,
            "node_feature": {
                "is_input": true,
                "fanout_num": 1,
                "is_endpoint": false,
                "cell_name": "NA",
                "sizer_cells": [],
                "node_coord": [
                    0.0,
                    0.0
                ],
                "node_slews": [
                    0.0,
                    0.0,
                    0.0,
                    0.0
                ],
                "node_capacitances": [
                    0.0,
                    0.0,
                    0.0,
                    0.0
                ],
                "node_arrive_times": [
                    1.1e+20,
                    1.1e+20,
                    1.1e+20,
                    1.1e+20
                ],
                "node_required_times": [
                    1.1e+20,
                    1.1e+20,
                    1.1e+20,
                    1.1e+20
                ],
                "node_net_load_delays": [
                    0.0,
                    0.0,
                    0.0,
                    0.0
                ],
                "node_toggle": 1.0,
                "node_sp": 0.5,
                "node_internal_power": 0.0,
                "node_net_power": 2.8232123814158402e-05
            }
        },
        // more nodes...
      ],  
      "edges": [ // Array of edges, representing connections between nodes
        {
            "id": "edge_0",
            "from_node": 510,
            "to_node": 746,
            "is_net_edge": false,
            "edge_feature": {
                "edge_delay": [
                    0.088476,
                    0.051862,
                    0.088476,
                    0.051862
                ],
                "edge_resistance": 0.0,
                "inst_arc_internal_power": 0.00011665750115296025
            }
        },
        // more edges...
      ]   
  }

• —Field Descriptions:
• —Nodes: Each node represents a connection point in the chip design, which could be a cell pin, a port, or a routing node. | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | string | Unique identifier for the node | - | "node4" | | `name` | string | Node name, usually containing instance and pin names | - | "clk0buf:X" | | `ispin | boolean | Whether it is a cell pin | - | true | | isport` | boolean | Whether it is a chip port | - | false | | `nodefeature` | object | Collection of node feature attributes, including timing and power info | - | - |
• —Node Features (node_feature): | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | is_input | boolean | Whether it is an input node (relative to the cell) | - | false | | fanout_num | integer | Fanout count, indicating the number of loads driven by this node | - | 17 | | is_endpoint | boolean | Whether it is an endpoint of a timing path | - | false | | cell_name | string | Cell name, if the node is a cell pin | - | "sky130fdschsbuf1" | | sizer_cells | array[string] | List of replaceable cells for cell sizing optimization | - | ["sky130fdschsbuf16", ...] | | node_coord | array[float] | Node coordinates (x, y) | DB Unit | [57.842, 61.732] | | node_slews | array[float] | Node slew times, includes values for four process corners | ns | [0.0, 0.0, 0.0, 0.0] | | node_capacitances | array[float] | Node capacitance values, includes values for four process corners | pF | [0.0, 0.0, 0.0, 0.0] | | node_arrive_times | array[float] | Signal arrival times at the node, includes values for four process corners | ns | [1.1e+20, 1.1e+20, ...] | | node_required_times | array[float] | Required arrival times at the node, includes values for four process corners | ns | [1.1e+20, 1.1e+20, ...] | | node_net_load_delays | array[float] | Node net load delays, includes values for four process corners | ns | [0.0, 0.0, 0.0, 0.0] | | node_toggle | float | Node toggle rate, indicating signal transitions per unit time | - | 1.0 | | node_sp | float | Signal probability, the probability of the signal being high | - | 0.5 | | node_internal_power | float | Node internal power, mainly cell internal power | W | 0.0 | | node_net_power | float | Node net power, mainly dynamic power on the net | W | 0.00012901 |

• —Edges: Each edge represents a connection between two nodes, which can be an internal cell connection or a net connection. | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | string | Unique identifier for the edge | - | "edge7960" | | `fromnode | integer | Start node ID (index in the nodes array) | - | 7586 | | tonode` | integer | End node ID (index in the `nodes` array) | - | 7587 | | `isnetedge` | boolean | Whether it is a net edge (true for net, false for internal cell connection) | - | true | | `edgefeature` | object | Collection of edge feature attributes, including delay and power info | - | - |

• —Edge Features (edge_feature): | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | edge_delay | array[float] | Edge delay values, includes values for four process corners | ns | [0.0, 0.0, 0.0, 0.0] | | edge_resistance | float | Edge resistance value, mainly for net edges | Ohms | 18.42857 | | inst_arc_internal_power| float | Instance arc internal power, mainly for internal cell edges | W | 0.0 |

• —Data Usage:
• —Timing Analysis: Provides a complete timing graph structure, supporting Static Timing Analysis (STA).
• —Power Optimization: Contains detailed power-related parameters, supporting power analysis and optimization.
• —Physical Design Verification: Offers the connection relationship between physical implementation and logical design, supporting design verification.
• —Machine Learning Feature Extraction: Provides structured chip design feature data for ML models, supporting prediction and optimization tasks.
• —Design Visualization: Supports converting the chip design into a visual graph structure for better understanding and analysis.

• —Data Characteristics:
• —STA Support: The Graph data includes complete timing-related information, supporting calculations and verifications related to Static Timing Analysis (STA).
• —Process Corner Coverage: Key parameters (like delay, slew, etc.) include values for four process corners, supporting full process corner analysis.
• —Hierarchical Structure: Data is organized by nodes and edges from graph theory, clearly expressing the connection relationships in the chip design.
• —Multi-dimensional Features: Each node and edge contains multi-dimensional features like timing, power, and geometric location, supporting comprehensive analysis and optimization.

Foundation Data: Patch

• —Example File Path: vectors/patchs/patch_0.json

• —Data Generation Mechanism:
• —The Vectorization::buildFeature function calls the buildPatchData method to construct the Patch data.
• —The data generation process is managed by VecDataManager and specifically implemented by VecPatchDataManager.
• —VecPatchInit is responsible for initializing the Patch grid and populating it with net and wire segment information.
• —Finally, the data is saved as a JSON file via VecLayoutFileIO::saveJsonPatchs.

• —Data Structure Example:

  {
      "id": 0,
      "patch_id_row": 0,
      "patch_id_col": 0,
      "llx": 0,
      "lly": 0,
      "urx": 4320,
      "ury": 4320,
      "row_min": 0,
      "row_max": 18,
      "col_min": 0,
      "col_max": 18,
      "cell_density": 0.8981481481481481,
      "pin_density": 40,
      "net_density": 0.12371399176954732,
      "macro_margin": 255180,
      "RUDY_congestion": 0.00029195559407049423,
      "EGR_congestion": 3.0,
      "timing": 0.0,
      "power": 3.2690654345212375e-07,
      "IR_drop": 0.0,
      "sub_nets": [
          {
              "id": 626,
              "llx": 1000,
              "lly": 0,
              "urx": 4320,
              "ury": 4320
          },
          // More sub-nets ...
      ],
      "patch_layer": [
          {
            "id": 4,
            "feature": {
                "wire_width": 140,
                "wire_len": 3120,
                "wire_density": 0.023405349794238684,
                "congestion": 2.0
            },
            "net_num": 1,
            "nets": [
              {
                "id": 650,
                "wire_num": 2,
                "wires": [
                    {
                        "id": 6600,
                        "feature": {
                            "wire_len": 3120
                        },
                        "path_num": 1,
                        "paths": [
                            {
                                "id1": 1151867,
                                "x1": 720,
                                "y1": 1200,
                                "real_x1": 720,
                                "real_y1": 1200,
                                "r1": 5,
                                "c1": 3,
                                "l1": 4,
                                "p1": -1,
                                "id2": 1158835,
                                "x2": 720,
                                "y2": 4320,
                                "real_x2": -1,
                                "real_y2": -1,
                                "r2": 18,
                                "c2": 3,
                                "l2": 4,
                                "p2": -1
                            }
                        ]
                    },
                    // More wire segments...
                  ]
              } 
            ]
          },
          // More patch_layers...
      ]
  }

• —Field Descriptions:
• —Global Information | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | Integer | Unique identifier for the patch, as an integer sequence number | - | 0 | | patch_id_row | Integer | Row index of the patch in the grid | - | 0 | | patch_id_col | Integer | Column index of the patch in the grid | - | 0 | | llx | Integer | Lower-left x-coordinate of the patch | Database Unit | 0 | | lly | Integer | Lower-left y-coordinate of the patch | Database Unit | 0 | | urx | Integer | Upper-right x-coordinate of the patch | Database Unit | 4320 | | ury | Integer | Upper-right y-coordinate of the patch | Database Unit | 4320 | | row_min | Integer | Minimum row number of nodes within the patch | - | 0 | | row_max | Integer | Maximum row number of nodes within the patch | - | 18 | | col_min | Integer | Minimum column number of nodes within the patch | - | 0 | | col_max | Integer | Maximum column number of nodes within the patch | - | 18 | | cell_density | Float | Cell density within the patch, value range [0, 1] | - | 0.898148 | | pin_density | Float | Pin density within the patch | Number of pins | 40 | | net_density | Float | Net density within the patch | - | 0.123714 | | macro_margin | Integer | Maximum margin distance to a macro cell within the patch | Database Unit | 255180 | | RUDY_congestion | Float | Congestion estimation value based on the RUDY model | - | 0.000292 | | EGR_congestion | Float | Congestion estimation value based on the EGR model | - | 3.0 | | timing | Float | Timing information | ns | 0.0 | | power | Float | Power information | W | 3.26907e-07 | | IR_drop | Float | IR drop information | V | 0.0 | | sub_nets | Array | Information about sub-nets contained within the patch | - | [Array of sub-net objects] | | patch_layer | Array | Detailed information for each layer of the patch | - | [Array of layer objects] |

• —Sub-net Information (`sub_nets`): Each element in the sub_nets array is a sub-net, defining the overlapping area of a net with the patch, as follows: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | Integer | Unique identifier for the sub-net | - | 626 | | llx | Integer | Lower-left x-coordinate of the sub-net | Database Unit | 1000 | | lly | Integer | Lower-left y-coordinate of the sub-net | Database Unit | 0 | | urx | Integer | Upper-right x-coordinate of the sub-net | Database Unit | 4320 | | ury | Integer | Upper-right y-coordinate of the sub-net | Database Unit | 4320 |

• —Layer Information (`patch_layer`): Each element in the patch_layer array represents a layer within the patch, defined as follows: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | Integer | Layer ID, corresponding to a metal layer in the physical design | - | 4 | | feature | Object | Layer feature information | - | See table below | | net_num | Integer | Number of nets contained in the layer | - | 1 | | nets | Array | List of nets in the layer | - | [Array of net objects] |

• —Layer Features (`feature`) | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | wire_width | Integer | Wire segment width | Database Unit | 140 | | wire_len | Integer | Total length of wire segments | Database Unit | 3120 | | wire_density | Float | Wire density | - | 0.023405 | | congestion | Float | Congestion level of this layer | - | 2.0 |

• —Net Information (`nets`): Each element in the nets array represents a net, defined as follows: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | Integer | Unique identifier for the net | - | 650 | | wire_num | Integer | Number of wires in the net | - | 2 | | wires | Array | List of wires | - | [Array of wire objects] |

• —Wire Information (`wires`): Each element in the wires array represents a wire segment, defined as follows: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | Integer | Unique identifier for the wire | - | 6600 | | feature | Object | Wire feature information | - | {"wirelen": 3120} | | `pathnum | Integer | Number of paths contained in the wire | - | 1 | | paths` | Array | List of paths | - | [Array of path objects] |

• —Path Information (`paths`): Each element in the paths array represents a segment of a wire's path, defined as follows: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id1 | Integer | Unique identifier for the start point | - | 1151867 | | x1, y1 | Integer | Grid coordinates of the start point | Database Unit | 720, 1200 | | real_x1, real_y1 | Integer | Actual physical coordinates of the start point | Database Unit | 720, 1200 | | r1, c1 | Integer | Row and column of the grid where the start point is located | - | 5, 3 | | l1 | Integer | Layer ID where the start point is located | - | 4 | | p1 | Integer | Pin index of the start point, -1 for non-real pins | - | -1 | | id2 | Integer | Unique identifier for the end point | - | 1158835 | | x2, y2 | Integer | Grid coordinates of the end point | Database Unit | 720, 4320 | | real_x2, real_y2 | Integer | Actual physical coordinates of the end point | Database Unit | 720, 4320 | | r2, c2 | Integer | Row and column of the grid where the end point is located | - | 18, 3 | | l2 | Integer | Layer ID where the end point is located | - | 4 | | p2 | Integer | Pin index of the end point, -1 for non-real pins | - | -1 | | via | Integer | Via ID (optional, exists only for cross-layer connections) | - | 10 (Via number) |

• —Data Usage:
• —Physical Layout Analysis: Provides detailed physical characteristics of different regions in a chip design, supporting designers in macroscopic layout evaluation.
• —Layout Visualization: The data structure facilitates the graphical display and analysis of layout regions.
• —Performance Optimization Guidance: Based on path information and electrical characteristics, it provides detailed physical foundation data for timing performance optimization.
• —AI Model Training Data: Provides structured physical design feature data for deep learning models, supporting AI tasks like routing prediction and congestion analysis.

• —Data Characteristics:
• —Patch data is divided into grid-like patch units based on physical design regions.
• —Each patch contains information for multiple layers, and each layer includes detailed geometric and electrical attributes of nets, wires, and paths.
• —The data is organized hierarchically from macro to micro: patch -> layer -> net -> wire -> path.
• —Path information precisely describes the connection points on a wire, including coordinates, layer, and grid position.

Foundation Data: Instance

• —Example File Path: vectors/instances/instances.json

• —Data Generation Mechanism:
• —The Vectorization::buildFeature function calls the _data_manager.saveData method to save all data.
• —The saveData method internally calls the VecLayoutFileIO::saveJson function.
• —The saveJson function calls the saveJsonInstances method specifically to generate Instance data.
• —Finally, the data is saved in JSON format to the specified directory.

• —Data Structure Example: The instances.json file uses the following structure:

  {
    "instance_num": 1448, // Total number of instances
    "instances": [
      {
        "id":0,
        "cell_id":236,
        "name":"ctrl/_17_",
        "cx":78480,
        "cy":61605,
        "width":1440,
        "height":3330,
        "llx":77760,
        "lly":59940,
        "urx":79200,
        "ury":63270
        },
      // More instances...
    ]
  }

• —Field Descriptions:

The fields for each instance are described as follows: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | Integer | Unique identifier for the instance | - | 1 | | cell_id | Integer | ID of the cell master to which the instance belongs | - | 1001 | | name | String | Instance name | - | "sky130fdschsand21_0" | | cx | Float | x-coordinate of the instance's center point | Database Unit | 1234.5 | | cy | Float | y-coordinate of the instance's center point | Database Unit | 5678.9 | | width | Float | Instance width | Database Unit | 420.0 | | height | Float | Instance height | Database Unit | 180.0 | | llx | Float | Lower-left x-coordinate of the instance | Database Unit | 1024.5 | | lly | Float | Lower-left y-coordinate of the instance | Database Unit | 5588.9 | | urx | Float | Upper-right x-coordinate of the instance | Database Unit | 1444.5 | | ury | Float | Upper-right y-coordinate of the instance | Database Unit | 5768.9 |

• —Data Usage:
• —Physical Layout Representation: The instance data precisely describes the physical location and size of each standard cell in the design.
• —Timing Analysis Support: The location information of instances is fundamental for calculating wire lengths and interconnect delays.
• —Routability Analysis: The distribution of instances is used to evaluate layout quality and routing difficulty.
• —AI Model Training: Provides real physical design instance layout data for machine learning models.

• —Data Characteristics:
• —Comprehensiveness: Contains information for all instances in the design, with no omissions.
• —Precision: Coordinate and size information is accurate to the database unit.
• —Associativity: Linked to cell library information via cell_id.
• —Uniform Structure: All instances use the same data structure, facilitating batch processing.
• —Extensibility: The JSON format supports the addition of extra instance attributes.

Foundation Data: Instance Graph

• —Example File Path: vectors/instance_graph/timing_instance_graph.json

• —Data Generation Mechanism:
• —The Vectorization::buildFeature function calls the generateFeature method.
• —The generateFeature method internally calls the VecFeature::buildFeatureTiming function.
• —The buildFeatureTiming function calls eval_tp->getTimingInstanceGraph() to obtain the instance graph data.
• —Finally, the data is saved in JSON format to the specified directory via the SaveTimingInstanceGraph function.

• —Data Structure Example:

The timing_instance_graph.json file uses the following structure:

  {
    "nodes": [        
      {
        "id": "node_0",
        "name": "ctrl/_34_",
        "leakage_power": 1.6979909062047418e-10
      },
      // More nodes...
    ],
    "edges": [
      {
        "id": "edge_0",
        "from_node": 0,
        "to_node": 1
      },
      // More edges...
    ]
  }

• —Field Descriptions:

• —Nodes: Each node object represents an instance and contains the following fields: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | String | Unique identifier for the node, format "nodenumber" | - | "node0" | | name | String | Instance name | - | "ctrl/34" | | leakage_power | Float | Leakage power of the instance | W | 1.697e-10 |

• —Edges: Each edge represents the connection relationship between two instances and contains the following fields: | Field Name | Data Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | id | String | Unique identifier for the edge, format "edgenumber" | - | "edge1037" | | from_node | Integer | Index of the driving node (corresponds to the index in the nodes array) | - | 640 | | to_node | Integer | Index of the receiving node (corresponds to the index in the nodes array) | - | 188 |

• —Data Usage:
• —Timing Analysis: The instance graph provides all instances and their connection relationships in the design, which can be used for timing path analysis and delay prediction.
• —Power Estimation: Contains leakage power information, which can be used for overall power estimation.
• —Physical Constraint Study: Reflects the connection density between instances, which helps in studying the impact of physical constraints on the design.
• —AI Model Training: Provides instance-level connection relationship and power data for machine learning models.

• —Data Characteristics:
• —Structured Representation: Uses a graph data structure to clearly represent the connection relationships between instances.
• —Lightweight Design: Edges contain only basic connection information, facilitating fast processing and analysis.
• —Includes Power Information: Each node includes leakage power data, which is convenient for power analysis.
• —Global View: Provides a global view of the instance connections for the entire design.

Foundation Data: Cell

• —Example File Path: vectors/tech/cells.json

• —Data Generation Mechanism:
• —The Vectorization::buildFeature function calls _data_manager.buildLayoutData to construct the basic layout data.
• —After data construction is complete, _data_manager.saveData is called to save the data.
• —During the saving process, the VecLayoutFileIO::saveJson method calls the saveJsonCells method.
• —The saveJsonCells method retrieves cell data from _layout->get_cells().get_cell_map() and saves it to the cells.json file.

• —Data Structure Example:

  {
    "cell_num": integer,      // Total number of cell_master units
    "cells": [            // Array of cells
      {
        "id": integer,       // Cell ID
        "name": "string", // Cell name
        "width": integer,    // Cell width
        "height": integer    // Cell height
      },
      // More cell masters...
    ]
  }

• —Field Descriptions: | Field Name | Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | cell_num | integer | Total number of cells in the cell library | - | 416 | | cells | array | Array containing information for all cells | - | [{}, ...] | | id | integer | Unique identifier for the cell | - | 415 | | name | string | Cell name, including technology information and functional description | - | "sky130sram1rw1r44x648" | | width | integer | Physical width of the cell | Database Unit (e.g., nm) | 445240 | | height | integer | Physical height of the cell | Database Unit (e.g., nm) | 237415 |

• —Data Usage:
• —Physical Design Reference: Provides physical dimension information for standard cells and macro cells for placement and routing.
• —Area Estimation: Used for chip area calculation and density analysis.
• —Power Analysis: Serves as base data for power calculation.
• —Timing Optimization: Provides cell-level references for timing analysis.

• —Data Characteristics:
• —Completeness: Contains information on all available standard cells and macro cells.
• —Physical Accuracy: Provides precise physical dimension parameters.
• —Process-Related: The data reflects cell characteristics under a specific technology node.
• —Structured Storage: Uses JSON format for easy parsing and processing by programs.
• —Extensibility: The data structure is simple and clear, making it easy to add new cell attributes.

Foundation Data: Technology

• —Example File Path: vectors/tech/tech.json

• —Data Generation Mechanism:
• —The Vectorization::buildFeature function calls _data_manager.buildLayoutData to construct the basic layout data.
• —After data construction is complete, _data_manager.saveData is called to save the data.
• —During the saving process, the VecLayoutFileIO::saveJson method calls the saveJsonTech method.
• —The saveJsonTech method retrieves layer data from _layout->get_layout_layers().get_layout_layer_map() and via data from _layout->get_via_name_map(), saving them to the tech.json file.

• —Data Structure Example:

  {
    "layer_num": integer,  // Number of technology layers
    "layers": [        // Array of layer information
      {
        "id": integer,   // Layer number
        "name": "string" // Layer name
      },
      // More layers...
    ],
    "via_num": integer,   // Number of via types
    "vias": [          // Array of via information
      {
        "id": integer,   // Via number
        "name": "string", // Via name
        "bottom": {   // Bottom metal enclosure area coordinates
          "llx": integer,
          "lly": integer,
          "urx": integer,
          "ury": integer
        },
        "cut": {      // Via cut area coordinates
          "llx": integer,
          "lly": integer,
          "urx": integer,
          "ury": integer
        },
        "top": {      // Top metal enclosure area coordinates
          "llx": integer,
          "lly": integer,
          "urx": integer,
          "ury": integer
        },
        "row": integer,  // Number of via rows
        "col": integer,  // Number of via columns
        "bottom_direction": "string", // Offset direction of the cut relative to the bottom enclosure
        "top_direction": "string"     // Offset direction of the cut relative to the top enclosure
      },
      // More vias...
    ]
  }

• —Field Descriptions:
• —Layer Information Fields | Field Name | Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | layer_num | integer | Total number of layers in the technology | - | 11 | | layers | array | Array of detailed information for all layers | - | [{}, ...] | | id | integer | Sequential number of the layer (from bottom to top) | - | 10 | | name | string | Layer name (metal layer, via layer, etc.) | - | "met5" |

• —Via Information Fields | Field Name | Type | Description | Unit | Example Value | | :--- | :--- | :--- | :--- | :--- | | via_num | integer | Total number of via types | - | 32 | | vias | array | Array of detailed information for all via types | - | [{}, ...] | | id | integer | Unique identifier for the via type | - | 0 | | name | string | Via type name | - | "L1M1PR" | | `bottom` | object | Bounding box coordinates of the bottom metal enclosure area | Database Unit | {"llx": -85, "lly": -85, "urx": 85, "ury": 85} | | `cut` | object | Bounding box coordinates of the via cut area | Database Unit | {"llx": -85, "lly": -85, "urx": 85, "ury": 85} | | `top` | object | Bounding box coordinates of the top metal enclosure area | Database Unit | {"llx": -145, "lly": -115, "urx": 145, "ury": 115} | | `row` | integer | Number of rows of via cuts | - | 1 | | `col` | integer | Number of columns of via cuts | - | 1 | | `bottomdirection | string | Connection direction for the bottom layer (C-Center, N-North, S-South, E-East, W-West) | - | "C" | | top_direction` | string | Connection direction for the top layer (C-Center, N-North, S-South, E-East, W-West) | - | "C" |

• —Data Usage:
• —Physical Design Rule Checking: Provides detailed parameters for layers and vias to verify if the design complies with technology rules.
• —Routing Guidance: Serves as technology constraint input for automatic routing tools.
• —Design Visualization: Provides accurate layer and via representations for design visualization.
• —Timing Analysis: Provides necessary technology parameters for signal integrity and timing analysis.

• —Data Characteristics:
• —Technology Accuracy: Accurately reflects layer and via characteristics for a specific technology node.
• —Completeness: Includes all necessary physical layers and via types.
• —Structured Representation: Uses JSON format for easy parsing and processing by programs.
• —Complete Spatial Information: Provides precise geometric coordinates for different parts of each via.
• —Directional Information: Includes directional information for via connections, which helps in understanding routing topology.

iEDArouteprocess_data

gcd/iEDA_route_process_data/gcd_a_place/
└── raw_data/                         # input files for 2D routing
    ├── gcd_a_place_preroute.def.gz   # .def format 
    └── gcd_a_place_preroute.v.gz     # .v format
├── demand_map_50.csv                 # Routing demand changes at intervals of routing windows (default: 50 nets per window).
├── demand_map_100.csv                
├── demand_map_150.csv                
├── demand_map_200.csv                
├── demand_map_250.csv                
├── demand_map_300.csv                
├── demand_map_final.csv              # Final routing demand map after completing 2D routing.
├── net_map.json                      # Detailed routing information for each net, including net name, path, x-y coordinates, and routing layer.
├── net_route_sequence.csv            # 2D routing order: row-by-row from top to bottom, with net feature information
└── supply_map_planar.csv             # Total routing resources after 3D-to-2D projection.

Data Owner

iEDA Team

License

GPL