ORD-QA.jsonl

{"id": 1, "type": "functionality", "question": " How can one optimize the routing of a specific net in the design? Especially, we want to decrease the maximum path depth from the net driver to its loads.\n", "ref_num": 2, "reference": ["pin_placement_8", "global_routing_6"], "reference_content": ["id:pin_placement_8\n### Place Individual Pin\n\nThe `place_pin` command places a specific pin in the specified location with the specified size.\nIt is recommended that individual pins be placed before the `place_pins` command,\nas the routing tracks occupied by these individual pins will be blocked, preventing overlaps.\n\nTo place an individual pin:\n\n```tcl\nplace_pin \n    -pin_name pin_name\n    -layer layer\n    -location {x y}\n    [-pin_size {width height}]\n    [-force_to_die_boundary]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-pin_name` | The name of a pin of the design. |\n| `-layer` | The routing layer where the pin is placed. |\n| `-location` | The center of the pin (in microns). |\n| `-pin_size` | The width and height of the pin (in microns). |\n| `-force_to_die_boundary` | When this flag is enabled, the pin will be snapped to the nearest routing track, next to the die boundary. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:global_routing_6\n### Set Routing Alpha\n\nBy default the global router uses heuristic rectilinear Steiner minimum\ntrees (RSMTs) as an initial basis to construct route guides. An RSMT\ntries to minimize the total wirelength needed to connect a given set\nof pins.  The Prim-Dijkstra heuristic is an alternative net topology\nalgorithm that supports a trade-off between total wirelength and maximum\npath depth from the net driver to its loads. The `set_routing_alpha`\ncommand enables the Prim/Dijkstra algorithm and sets the alpha parameter\nused to trade-off wirelength and path depth.  Alpha is between 0.0\nand 1.0. When alpha is 0.0 the net topology minimizes total wirelength\n(i.e. capacitance).  When alpha is 1.0 it minimizes longest path between\nthe driver and loads (i.e., maximum resistance).  Typical values are\n0.4-0.8. You can call it multiple times for different nets.\n\n```tcl\nset_routing_alpha \n    [-net net_name] \n    [-min_fanout fanout]\n    [-min_hpwl hpwl]\n    [-clock_nets]\n    alpha\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net` | Net name. | \n| `-min_fanout` | Set the minimum number for fanout. | \n| `-min_hpwl` | Set the minimum half-perimetere wirelength (microns). | \n| `-clock_nets` | Flag to set routing alpha for clock nets. The default value is `False`, and the allowed values are bools. |\n| `alpha` | Set the trade-off value between wirelength and path depth. The allowed values are floats `[0, 1]`. |\n\nExample: `set_routing_alpha -net clk 0.3` sets the alpha value of 0.3 for net *clk*.\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Use the `set_routing_alpha` command. This command is used to set the alpha value for the specific net, which allows a trade-off between total wirelength (minimizing capacitance) and longest path between the driver and loads (minimizing resistance). The parameters for the command include `-net` which is the name of your net, and the `alpha` value which you would have to experiment with to achieve the desired trade-off. For example: \\n```tcl\\nset_routing_alpha -net net1 0.5\\n. Alternatively, you can directly use the command `place_pin` place the pin(s) of the net at suitable locations.\n"}
{"id": 2, "type": "functionality", "question": " How to introduce randomness to global routing for solution exploration?\n", "ref_num": 1, "reference": ["global_routing_8"], "reference_content": ["id:global_routing_8\n### Set Global Routing Randomness\n\nThe randomized global routing shuffles the\norder of the nets and randomly subtracts or adds to the capacities of\na random set of edges. \n\n```tcl\nset_global_routing_random \n    [-seed seed]\n    [-capacities_perturbation_percentage percent]\n    [-perturbation_amount value]\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-seed` | Sets the random seed (must be non-zero for randomization). |\n| `-capacities_perturbation_percentage` | Sets the percentage of edges whose capacities are perturbed. By default, the edge capacities are perturbed by adding or subtracting 1 (track) from the original capacity.  |\n| `-perturbation_amount` | Sets the perturbation value of the edge capacities. This option is only meaningful when `-capacities_perturbation_percentage` is used. |\n\nExample:\n`set_global_routing_random -seed 42 \\\n  -capacities_perturbation_percentage 50 \\\n  -perturbation_amount 2`\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " You can introduce randomness into global routing and control the percentage of edge capacities perturbed using the command ```tcl\\nset_global_routing_random \\n    [-seed seed]\\n    [-capacities_perturbation_percentage percent]\\n    [-perturbation_amount value]\\n```. -capacities_perturbation_percentage sets the percentage of edges whose capacities are perturbed, -perturbation_amount sets the perturbation value of the edge capacities.\n"}
{"id": 3, "type": "functionality", "question": " If a user would like to make changes to a design to reduce the WNS and TNS after placement, what steps should he take?\n", "ref_num": 4, "reference": ["flow-scripts-tutorial_13", "gate_resizing_3", "gate_resizing_8", "detailed_placement_5"], "reference_content": ["id:flow-scripts-tutorial_13\n\n## Viewing Results And Logs\n\n### Timing\n\nUsers can view flow results using the command interface from the shell or\nthe OpenROAD GUI to visualize further and debug. Learn more about the\n[GUI](https://openroad.readthedocs.io/en/latest/main/README.html#gui).\n\n```shell\nmake gui_final\n```\n\nUse the following commands in the `Tcl Commands` section of GUI:\n\n```tcl\nreport_worst_slack\nreport_tns\nreport_wns\n```\n\nNote the worst slack, total negative slack and worst negative slack:\n\n```\nworst slack -0.99\ntns -1.29\nwns -0.99\n```\n\nLearn more about visualizing and tracing time paths across the design\nhierarchy refer to the OpenROAD [GUI](https://openroad.readthedocs.io/en/latest/main/README.html#gui).\n\n", "id:gate_resizing_3\n### Estimate Parasitics\n\nEstimate RC parasitics based on placed component pin locations. If there are\nno component locations, then no parasitics are added. The resistance and capacitance\nvalues are per distance unit of a routing wire. Use the `set_units` command to check\nunits or `set_cmd_units` to change units. The goal is to represent \"average\"\nrouting layer resistance and capacitance. If the set_wire_rc command is not\ncalled before resizing, then the default_wireload model specified in the first\nLiberty file read or with the SDC set_wire_load command is used to make parasitics.\n\nAfter the `global_route` command has been called, the global routing topology\nand layers can be used to estimate parasitics  with the `-global_routing`\nflag.\n\n```tcl\nestimate_parasitics\n    -placement|-global_routing\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-placement` or `-global_routing` | Either of these flags must be set. Parasitics are estimated based after placement stage versus after global routing stage. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gate_resizing_8\n### Repair Design\n\nThe `repair_design` command inserts buffers on nets to repair max slew, max\ncapacitance and max fanout violations, and on long wires to reduce RC delay in\nthe wire. It also resizes gates to normalize slews.  Use `estimate_parasitics\n-placement` before `repair_design` to estimate parasitics considered\nduring repair. Placement-based parasitics cannot accurately predict\nrouted parasitics, so a margin can be used to \"over-repair\" the design\nto compensate. \n\n```tcl\nrepair_design \n    [-max_wire_length max_length]\n    [-slew_margin slew_margin]\n    [-cap_margin cap_margin]\n    [-max_utilization util]\n    [-verbose]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-max_wire_length` | Maximum length of wires (in microns), defaults to a value that minimizes the wire delay for the wire RC values specified by `set_wire_rc`. |\n| `-slew_margin` | Add a slew margin. The default value is `0`, the allowed values are integers `[0, 100]`. |\n| `-cap_margin` | Add a capactitance margin. The default value is `0`, the allowed values are integers `[0, 100]`. |\n| `-max_utilization` | Defines the percentage of core area used. |\n| `-verbose` | Enable verbose logging on progress of the repair. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:detailed_placement_5\n### Check Placement\n\nThe `check_placement` command checks the placement legality. It returns\n`0` if the placement is legal.\n\n```tcl\ncheck_placement\n    [-verbose]\n    [-disallow_one_site_gaps]\n    [-report_filename filename]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-verbose` | Enable verbose logging. |\n| `-disallow_one_site_gaps` | Disable one site gap during placement check. |\n| `-report_file_name` | File name for saving the report to (e.g. `report.json`. |\n\n## Commands\n\n"], "answer": " 1. run the command `report_wns` and `report_tns` to report the Worst Negative Slack (WNS) and Total Negative Slack (TNS). Document these initial values for comparison later. \\n\\n2. Estimate RC parasitics based on placed component pin locations by command `estimate_parasitics -placement`.\\n\\n 3. Run the timing optimization command such as `repair_design` with appropriated parameters, for example:\\n   ```tcl\\n   repair_design -max_wire_length 10 -slew_margin 20 -cap_margin 20 -max_utilization 70 -verbose\\n   ```\\n\\n4. Check whether the placement is legal after modifications by running `check_placement -verbose. \\n 5. Compare the timing performance (min/worst slack, TNS) before and after the design modifications.\n"}
{"id": 4, "type": "gui&installation&test", "question": " When working with the OpenROAD GUI, a user reported that the design doesn't load correctly after loading a new design through the odb API. What could be the possible reasons for this, and how can you resolve it?\n", "ref_num": 1, "reference": ["gui_8"], "reference_content": ["id:gui_8\n### Support\n\nDetermine is the GUI is active:\n\n```\ngui::enabled\n```\n\nAnnounce to the GUI that a design was loaded \n(note: this is only needed when the design was loaded through the odb API and not via ``read_def`` or ``read_db``):\n\n```\ngui::design_created\n```\n\nTo load the results of a DRC report:\n\n```\ngui::load_drc filename\n```\n\n## Commands\n\n"], "answer": " One possible reason could be that the GUI was not informed about loading a new design if it was loaded through the odb API and not via the `read_def` or `read_db` commands. The user needs to use the `gui::design_created` command specifically after loading a new design through the API to make sure the GUI is aware of the new design.\\n    \\n    For example:\\n\\n    ```tcl\\n    gui::design_created\\n    ```\\n\\n    Doing this will ensure the GUI accurately reflects the new design loaded through the odb API.\\n\\n.\n"}
{"id": 5, "type": "gui&installation&test", "question": " How can I install the OpenROAD tool with a debugging option and a specified Tcl library path, and then test the automatic code generation tool for OpenDB objects and Iterators?\n", "ref_num": 2, "reference": ["install_3", "code_generator_0"], "reference_content": ["id:install_3\n# Installing OpenROAD\n### Build using support script\n\n``` shell\n./etc/Build.sh\n# To build with debug option enabled and if the Tcl library is not on the default path\n./etc/Build.sh -cmake=\"-DCMAKE_BUILD_TYPE=DEBUG -DTCL_LIB=/path/to/tcl/lib\"\n```\n\nThe default install directory is `/usr/local`.\nTo install in a different directory use:\n\n``` shell\n./etc/Build.sh -cmake=\"-DCMAKE_INSTALL_PREFIX=<prefix_path>\"\n```\n\n", "id:code_generator_0\n# Automatic Code Generator\n\nThis is an automatic code generation tool for OpenDB objects and Iterators. To test the tool you can use the following command\n\n``` shell\npython3 gen.py --json schema.json --src_dir ../db --include_dir ../../include/odb --templates templates\n```\n\nWhere schema.json is the json file that includes the requirements, src is the source files directory, include is the include directory, and templates is the directory including the jinja templates for the classes.\n\n"], "answer": " 1. To install OpenROAD tool with a debugging option and a specified Tcl library path, you can use the following command: `./etc/Build.sh -cmake=\\\"-DCMAKE_BUILD_TYPE=DEBUG -DTCL_LIB=/path/to/tcl/lib\\\"`. You need replace `/path/to/tcl/lib` with the correct path of your Tcl library.\\n\\n2. After installing OpenROAD, you can test the automatic code generation tool for OpenDB objects and Iterators by using the following command: `python3 gen.py --json schema.json --src_dir ../db --include_dir ../../include/odb --templates templates`. Please make sure to replace `schema.json`, `../db`, `../../include/odb`, and `templates` with the correct paths.\\n\\nPotential issues that you may encounter include incorrect path specification and incompatible Tcl library. Please make sure that all paths are correctly specified and the Tcl library specified is compatible with the OpenROAD tool.\\n\\n\n"}
{"id": 6, "type": "vlsi_flow", "question": " As an experienced engineer using OpenROAD, suppose that we have placed pins and found there is several DRC violations occurred due to some pins overlapping. Additionally, there might be routing issues due to the pin positions on certain layers. How can we detect those issues, fix the pin placement, reroute the signal/clock, and verify the solution in OpenROAD considering timing?\n", "ref_num": 5, "reference": ["get_start_9", "flow-scripts-tutorial_28", "pin_placement_9", "flow-scripts-tutorial_22", "global_routing_2"], "reference_content": ["id:get_start_9\n# OpenROAD\n## Regression Tests\n\nThere are a set of executable regression test scripts in `./test/`.\n\n``` shell\n# run tests for all tools\n./test/regression\n\n# run all flow tests\n./test/regression flow\n\n# run <tool> tests\n./test/regression <tool>\n\n# run all <tool>-specific unit tests\ncd src/<tool>\n./test/regression\n\n# run only <TEST_NAME> for <tool>\ncd src/<tool>\n./test/regression <TEST_NAME>\n```\n\nThe flow tests check results such as worst slack against reference values.\nUse `report_flow_metrics [test]...` to see all of the metrics.\n\n``` text\n% report_flow_metrics gcd_nangate45\n                       insts    area util slack_min slack_max  tns_max clk_skew max_slew max_cap max_fanout DPL ANT drv\ngcd_nangate45            368     564  8.8     0.112    -0.015     -0.1    0.004        0       0          0   0   0   0\n```\n\nTo update a failing regression, follow the instructions below:\n\n```tcl\n# update log files (i.e. *ok)\nsave_ok <TEST_NAME>\n\n# update \"*.metrics\" for tests that use flow test\nsave_flow_metrics <TEST_NAME> \n\n# update \"*.metrics_limits\" files\nsave_flow_metrics_limits <TEST_NAME>\n```\n\n", "id:flow-scripts-tutorial_28\n\n### IO Pin Placement\n\nPlace pins on the boundary of the die on the track grid to minimize net\nwirelengths. Pin placement also creates a metal shape for each pin using\nmin-area rules.\n\nFor designs with unplaced cells, the net wirelength is computed considering\nthe center of the die area as the unplaced cells position.\n\nFind pin placement document [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/ppl/README.md).\n\nRefer to the built-in examples [here](https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/ppl/test).\n\nLaunch openroad GUI by running the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/ppl/test/\nopenroad -gui\n```\n\nRun [place_pin4.tcl](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/ppl/test/place_pin4.tcl) script to view\npin placement.\n\nplace_pin4.tcl:\n```shell\nsource \"helpers.tcl\"\nread_lef Nangate45/Nangate45.lef\nread_def gcd.def\n\nplace_pin -pin_name clk -layer metal7 -location {40 30} -pin_size {1.6 2.5} -force_to_die_boundary\nplace_pin -pin_name resp_val -layer metal4 -location {12 50} -pin_size {2 2} -force_to_die_boundary\nplace_pin -pin_name req_msg[0] -layer metal10 -location {25 70} -pin_size {4 4} -force_to_die_boundary\n\nplace_pins -hor_layers metal3 -ver_layers metal2 -corner_avoidance 0 -min_distance 0.12\n\nset def_file [make_result_file place_pin4.def]\n\nwrite_def $def_file\n\ndiff_file place_pin4.defok $def_file\n```\n\nFrom the GUI `Tcl commands` section:\n\n```tcl\nsource place_pin4.tcl\n```\n\nView the resulting pin placement in GUI:\n\n![place_pin](./images/place_pin.webp)\n\nIn OpenROAD GUI to enlarge `clk` pin placement, hold mouse right button\nas follows and draw sqaure box in specific location:\n\n![pin_zoom](./images/pin_zoom_RC.webp)\n\nNow `clk` pin zoom to clear view as follows:\n\n![pin_zoomed](./images/pin_zoomed.webp)\n\n", "id:pin_placement_9\n### Place All Pins\n\nUse the following command to perform pin placement:\n\n```tcl\nplace_pins \n    -hor_layers h_layers\n    -ver_layers v_layers\n    [-random_seed seed]\n    [-random]\n    [-corner_avoidance length]\n    [-min_distance distance]\n    [-min_distance_in_tracks]\n    [-exclude region]\n    [-group_pins pin_list]\n    [-annealing]\n    [-write_pin_placement file_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-hor_layers` | The layers to create the metal shapes of pins placed in horizontal tracks. It can be a single layer or a list of layer names. |\n| `-ver_layers` | The layers to create the metal shapes of pins placed in vertical tracks. It can be a single layer or a list of layer names. |\n| `-corner_avoidance` | The distance (in microns) from each corner within which pin placement should be avoided. |\n| `-min_distance` | The minimum distance between pins on the die boundary. This distance can be in microns (default) or in number of tracks between each pin. |\n| `-min_distance_in_tracks` | Flag that allows setting the min distance in number of tracks instead of microns. |\n| `-exclude` | A region where pins cannot be placed. Either `top|bottom|left|right:edge_interval`, which is the edge interval from the selected edge; `begin:end` for begin-end of all edges. |\n| `-group_pins` | A list of pins to be placed together on the die boundary. |\n| `-annealing` | Flag to enable simulated annealing pin placement. |\n| `-write_pin_placement` | A file with the pin placement generated in the format of multiple calls for the `place_pin` command. |\n\nThe `exclude` option syntax is `-exclude edge:interval`. The `edge` values are\n(top|bottom|left|right). The `interval` can be the whole edge, with the `*`\nvalue, or a range of values. For example, in `place_pins -hor_layers metal2\n-ver_layers metal3 -exclude top:* -exclude right:15-60.5 -exclude left:*-50`\nthree intervals are excluded: the whole top edge, the right edge from 15\nmicrons to 60.5 microns, and the left edge from its beginning to 50 microns.\n\n#### Developer Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-random_seed` | Specify the seed for random operations. |\n| `-random` | When this flag is enabled, the pin placement is random. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:flow-scripts-tutorial_22\n## OpenROAD GUI\n### DRC Viewer\n\nYou can use the GUI to trace DRC violations and fix them.\n\nView DRC violations post routing:\n\n```shell\nless ./reports/sky130hd/ibex/base/5_route_drc.rpt\n```\n\nAny DRC violations are logged in the `5_route_drc.rpt` file, which is\nempty otherwise.\n\nFrom OpenROAD GUI, Enable the menu options `Windows` -> `DRC Viewer`. A\n`DRC viewer` window is added on the right side (RHS) of the GUI. From\n`DRC Viewer` -> `Load` navigate to `5_route_drc.rpt`\n\n\nBy selecting DRC violation details, designers can analyze and fix them. Here\nuser will learn how a DRC violation can be traced with the `gcd` design. Refer\nto the following OpenROAD test case for more details.\n\n```shell\ncd ./flow/tutorials/scripts/drt/\nopenroad -gui\n```\n\nIn the `Tcl Commands` section of GUI:\n\n```tcl\nsource drc_issue.tcl\n```\n\nPost detail routing in the log, you can find the number of violations left\nin the design:\n\n```\n[INFO DRT-0199] Number of violations = 7.\n```\n\nBased on `DRC Viewer` steps load `results/5_route_drc.rpt`. GUI as\nfollows\n\n\n`X mark` in the design highlights DRC violations.\n\nFrom `DRC Viewer` on RHS `expand` -> `Short`\n\nThis shows the number of `violations` in the design. Zoom the design\nfor a clean view of the violation:\n\n\n`output53` has overlaps and this causes the `short violation`.\n\nOpen the input DEF file `drc_cts.def` to check the source of the\noverlap.\n\nNote the snippet of DEF file where `output51` and `output53` have\nthe same placed coordinates and hence cause the placement violation.\n\n```\n- output51 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 267260 136000 ) N ;\n- output53 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 267260 136000 ) N ;\n```\n\nUse the test case provided in `4_cts.def` with the changes applied for\nupdated coordinates as follows:\n\n```\n- output51 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 267260 136000 ) N ;\n- output53 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 124660 266560 ) N ;\n```\n\nClose the current GUI and re-load the GUI with the updated DEF to see\nfixed DRC violation in the design:\n\n```shell\nopenroad -gui\nsource drc_fix.tcl\n```\n\nIn the post detail routing log, the user can find the number of violations\nleft in the design:\n\n```\n[INFO DRT-0199] Number of violations = 0.\n```\n\nRouting completed with 0 violations.\n\n", "id:global_routing_2\n### Set Routing Layers\n\n```tcl\nset_routing_layers \n    [-signal min-max]\n    [-clock min-max]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-signal` | Set the min and max routing signal layer (names) in this format \"%s-%s\". |\n| `-clock` | Set the min and max routing clock layer (names) in this format \"%s-%s\". |\n\nExample: `set_routing_layers -signal Metal2-Metal10 -clock Metal6-Metal9`\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To solve this problem, follow these steps:\\n\\n1. Locate the overlap DRC issues\\nEnter following commands:\\n```shell\\nless ./reports/sky130hd/ibex/base/5_route_drc.rpt\\n```\\nCheck and analyze the reported DRC issues about pins.\\n\\n2. Fix pin placement\\n   Use place_pins with 'exclude' option to avoid potential overlaps and 'corner_avoidance' to avoid issues concerning placement close to the boundary.\\n```tcl\\nplace_pins -hor_layers Metal2-Metal10 -ver_layers Metal3-Metal9 -exclude top:* -exclude right:15-60.5 -exclude left:*-50 -corner_avoidance 0.05 -min_distance 0.12\\n```\\n\\n3. Reset the routing for signal and clock.\\n   Now we must ensure the routing layers are updated accordingly.\\n```tcl\\nset_routing_layers -signal Metal2-Metal10 -clock Metal6-Metal9\\n```\\n\\n4. Check placement and perform tests to ensure a legal placement result\\n```tcl\\ncheck_placement\\n```\\nAnd perform regression tests for a comprehensive check.\\n```shell\\n./test/regression flow\\n```\\n\\n\n"}
{"id": 7, "type": "functionality", "question": " Given that the user needs to build a power grid for the top level of an SoC design in OpenROAD, how can power/ground rings be added around a grid region for efficient power delivery and how can the user validate that the structures have been correctly implemented?\n", "ref_num": 2, "reference": ["power_distribution_network_generator_8", "flow-scripts-tutorial_21"], "reference_content": ["id:power_distribution_network_generator_8\n### Add Rings\n\nThe `add_pdn_ring` command defines power/ground rings around a grid region. The ring structure is built using two layers that are orthogonal to each other. A power/ground pair will be added above and below the grid using the horizontal layer, with another power/ground pair to the left and right using the vertical layer. These four pairs of power/ground stripes form a ring around the specified grid. Power straps on these layers that are inside the enclosed region are extended to connect to the ring.\n\n```tcl\nadd_pdn_ring \n    -layers layer_name\n    -widths width_value|list_of_2_values\n    -spacings spacing_value|list_of_2_values\n    [-grid grid_name]\n    [-core_offsets offset_value]\n    [-pad_offsets offset_value]\n    [-add_connect]\n    [-extend_to_boundary]\n    [-connect_to_pads]\n    [-connect_to_pad_layers layers]\n    [-starts_with POWER|GROUND]\n    [-nets list_of_nets]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-layers` | Specifies the name of the layer for these stripes. |\n| `-widths` | Value for the width of the stdcell rail. |\n| `-spacings` | Optional specification of the spacing between power/ground pairs within a single pitch. (Default: pitch / 2). |\n| `-grid` | Specifies the name of the grid to which this ring defintion will be added. (Default: Last grid created by `define_pdn_grid`). |\n| `-core_offsets` | Value for the offset of the ring from the grid region. |\n| `-pad_offsets` | When defining a power grid for the top level of an SoC, can be used to define the offset of ring from the pad cells. |\n| `-add_connect` | Automatically add a connection between the two layers. |\n| `-extend_to_boundary` | Extend the rings to the grid boundary. |\n| `-connect_to_pads` | The core side of the pad pins will be connected to the ring. |\n| `-connect_to_pad_layers` | Restrict the pad pins layers to this list. |\n| `-starts_with` | Use `POWER` or `GROUND`  for the first placed strap. Defaults to `GROUND`. |\n| `-nets` | Limit straps to just this list of nets. |\n\nExample usage: \n\n```tcl\nadd_pdn_ring -grid main_grid -layer {metal6 metal7} -widths 5.0 -spacings  3.0 -core_offset 5\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:flow-scripts-tutorial_21\n## OpenROAD GUI\n### Using Rulers\n\nA ruler can measure the distance between any two objects in the design or\nmetal layer length and width to be measured, etc.\n\nExample of how to measure the distance between VDD and VSS power grid click on:\n\n`Tools` -> `Ruler K`\n\nDistance between VDD and VSS layer is `11.970`\n\n"], "answer": " The user needs to initiate the add_pdn_ring command to define power/ground rings around a grid region. For instance:\\n\\n```tcl\\nadd_pdn_ring -grid main_grid -layer {metal6 metal7} -widths 5.0 -spacings  3.0 -core_offset 5\\n```\\n\\n Thereafter, the user can use OpenROAD GUI's 'Ruler K' to measure the distances and verify that the measurements align with the inputs given for the power/ground rings.\\n\\n\n"}
{"id": 8, "type": "gui&installation&test", "question": " For the OpenROAD platform, how can the user implement tap cell insertion into the RTL-to-GDS flow to help tie VDD and GND levels and avoid latch-up, and how can the result be displayed in the GUI?\n", "ref_num": 2, "reference": ["flow-scripts-tutorial_32", "flow-scripts-tutorial_2"], "reference_content": ["id:flow-scripts-tutorial_32\n\n### Tapcell insertion\n\nTap cells are non-functional cells that can have a well tie, substrate\ntie or both. They are typically used when most or all of the standard\ncells in the library contain no substrate or well taps. Tap cells help\ntie the VDD and GND levels and thereby prevent drift and latch-up.\n\nThe end cap cell or boundary cell is placed at both the ends of each\nplacement row to terminate the row. They protect the standard cell\ngate at the boundary from damage during manufacturing.\n\nTap cells are placed after the macro placement and power rail creation.\nThis stage is called the pre-placement stage. Tap cells are placed in a\nregular interval in each row of placement. The maximum distance between\nthe tap cells must be as per the DRC rule of that particular technology library.\n\nThe figures below show two examples of tapcell insertion. When only the\n`-tapcell_master` and `-endcap_master` masters are given, the tapcell placement\nis similar to Figure 1. When the remaining masters are give, the tapcell\nplacement is similar to Figure 2.\n\nRefer to the GUI figures to highlight well tap and end cap cells. The image\ndoes not differentiate and just shows a bunch of rectangles.\n\n| <img src=\"./images/tapcell_example1.svg\" width=450px> | <img src=\"./images/tapcell_example2.svg\" width=450px> |\n|:--:|:--:|\n| Figure 1: Tapcell insertion representation | Figure 2:  Tapcell insertion around macro representation |\n\nRefer to the following built-in example [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/tap/test/gcd_nangate45.tcl)\nto learn about Tap/endcap cell insertion.\n\ngcd_nangate45.tcl:\n```shell\nsource \"helpers.tcl\"\nread_lef Nangate45/Nangate45_tech.lef\nread_lef Nangate45/Nangate45_stdcell.lef\nread_def gcd_nangate45.def\n\nset def_file [make_result_file gcd_nangate45.def]\n\ntapcell -distance \"20\" -tapcell_master \"TAPCELL_X1\" -endcap_master \"TAPCELL_X1\"\n\nwrite_def $def_file\n\ndiff_file gcd_nangate45.defok $def_file\n```\n\nTo view this in OpenROAD GUI by running the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/tap/test/\nopenroad -gui\n```\n\nIn the `Tcl Commands` section of GUI\n\n```tcl\nsource gcd_nangate45.tcl\n```\n\nView the resulting tap cell insertion as follows:\n\n![Tap_Cell_Insertion](./images/tapcell_insertion_view.webp)\n\n", "id:flow-scripts-tutorial_2\n\n## Getting Started\n\nThis section describes the environment setup to build OpenROAD-flow-scripts\nand get ready to execute the RTL-to-GDS flow of the open-source\ndesign `ibex` using the `sky130hd` technology.\n\n`ibex` is a 32 bit RISC-V CPU core (`RV32IMC/EMC`) with a two-stage\npipeline.\n\n### Setting Up The Environment\n\nUse the `bash` shell to run commands and scripts.\n\n#### OpenROAD-flow-scripts Installation\n\nTo install OpenROAD-flow-scripts,  refer to the\n[Build or installing ORFS  Dependencies](https://openroad-flow-scripts.readthedocs.io/en/latest/#build-or-installing-orfs-dependencies)\ndocumentation.\n\nIn general, we recommend using `Docker` for an efficient user\nexperience. Install OpenROAD-flow-scripts using a docker as described\nhere [Build from sources using Docker](../user/BuildWithDocker.md).\n\n:::{Note}\nIf you need to update an existing OpenROAD-flow-scripts installation,\nfollow instructions from [here](../user/FAQS.md#how-do-i-update-openroad-flow-scripts).\n:::\n\nOpenROAD-flow-scripts installation is complete.\n\n"], "answer": " In the shell script, implement the tapcell command as shown:\\n\\n```tcl\\ntapcell -distance \\\"20\\\" -tapcell_master \\\"TAPCELL_X1\\\" -endcap_master \\\"TAPCELL_X1\\\"\\n```\\n\\nAfterward, if the user is interested in visualizing the result in the GUI, they should navigate to the OpenROAD tool root directory. Once inside the tap test directory, they can open the GUI and run the following commands:\\n\\n```tcl\\ncd ../tools/OpenROAD/src/tap/test/\\nopenroad -gui\\n```\\n\\nAfter the GUI is initiated:\\n\\n```tcl\\nsource gcd_nangate45.tcl\\n```\\nThis way, the resulting tap cell insertion can be visualized and inspected as per the user's preferences.\\n\\n\n"}
{"id": 9, "type": "functionality", "question": " In a scenario where the user needs to avoid using certain library cells in the resizer engine in OpenROAD, how can this be accomplished and what command can be used to validate these settings?\n", "ref_num": 2, "reference": ["gate_resizing_4", "database_5"], "reference_content": ["id:gate_resizing_4\n### Set Don't Use\n\nThe `set_dont_use` command removes library cells from consideration by\nthe `resizer` engine and the `CTS` engine. `lib_cells` is a list of cells returned by `get_lib_cells`\nor a list of cell names (`wildcards` allowed). For example, `DLY*` says do\nnot use cells with names that begin with `DLY` in all libraries.\n\n```tcl\nset_dont_use lib_cells\nunset_dont_use lib_cells\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:database_5\n# OpenDB\n### C++\n\nAll public database classes are defined in `db.h`. These class definitions\nprovide all functions for examining and modifying the database objects. The\ndatabase is an object itself, so multiple database objects can exist\nsimultaneously (no global state).\n\n`dbTypes.h` defines types returned by database class member functions.\n\nAll database objects are in the `odb` namespace.\n\n-   `dbChip`\n-   `dbBlock`\n-   `dbTech`\n-   `dbLib`\n\nAll database objects have a 32bit object identifier accessed with the\n`dbObject::getOID` base class member function that returns a `uint`. This\nidentifier is preserved across save/restores of the database so it should\nbe used to reference database object by data structures instead of pointers\nif the reference lifetime is across database save/restores. OIDs allow the\ndatabase to have exactly the same layout across save/restores.\n\nThe database distance units are **nanometers** and use the type `uint`.\n\n"], "answer": " Execute the 'set_dont_use' command and specify the cell to be excluded. For instance:\\n\\n```tcl\\nset_dont_use DLY*\\n```\\n\\nTo ensure that the settings have taken effect, specify the cells to look up using their identifiers and validate if they have been properly excluded using the 'dbObject::getOID' function in conjunction with appropriate functions to probe the database objects. Exact application of these functions will be dependent on the specifics of the scenario and the specifics of the API of the OpenDB system.\\n\\n\n"}
{"id": 10, "type": "vlsi_flow", "question": " An OpenROAD user would like to optimize their RTL design's global placement settings by customizing various parameters, and then visualize the resulting placement with a heatmap. How can they achieve this?\n", "ref_num": 3, "reference": ["global_placement_3", "gui_14", "detailed_placement_6"], "reference_content": ["id:global_placement_3\n# Global Placement\n## Using the Python interface to gpl\n\nThis API tries to stay close to the API defined in `C++` class `Replace`\nthat is located [here](include/gpl/Replace.h).\n\nWhen initializing a design, a sequence of Python commands might look like\nthe following:\n\n```python\nfrom openroad import Design, Tech\ntech = Tech()\ntech.readLef(...)\ndesign = Design(tech)\ndesign.readDef(...)\ngpl = design.getReplace()\n```    \n\nHere is an example of some options / configurations to the global placer.\n(See [Replace.h](include/gpl/Replace.h) for a complete list)\n\n```python\ngpl.setInitialPlaceMaxIter(iter)\ngpl.setSkipIoMode(skip_io)\ngpl.setTimingDrivenMode(timing_driven)\ngpl.setTimingNetWeightMax(weight)\n```\n\nThere are some useful Python functions located in the file\n[grt_aux.py](test/grt_aux.py) but these are not considered a part of the *final*\nAPI and they may change.\n\n\n", "id:gui_14\n### Heat Maps\n\nThe currently availble heat maps are:\n\n- ``Power``\n- ``Routing``\n- ``Placement``\n- ``IRDrop``\n- ``RUDY`` [^RUDY]\n\nTo control the settings in the heat maps:\n\n```\ngui::set_heatmap name option\ngui::set_heatmap name option value\n```\n\nOptions description:\n- ``name`` is the name of the heatmap.\n- ``option`` is the name of the option to modify. If option is ``rebuild`` the map will be destroyed and rebuilt.\n- ``value`` is the new value for the specified option. This is not used when rebuilding map.\n\nThese options can also be modified in the GUI by double-clicking the underlined display control for the heat map.\n\n\nTo save the raw data from the heat maps ins a comma separated value (CSV) format:\n\n```\ngui::dump_heatmap name filename\n```\n\nOptions description: \n- ``name`` is the name of the heatmap.\n- ``filename`` path to the file to write the data to.\n\n[^RUDY]: RUDY means Rectangular Uniform wire DensitY, which can predict the routing density very rough and quickly. You can see this notion in [this paper](https://past.date-conference.com/proceedings-archive/2007/DATE07/PDFFILES/08.7_1.PDF) \n\n\n\n## Commands\n\n", "id:detailed_placement_6\n### Optimize Mirroring\n\nThe `optimize_mirroring` command mirrors instances about the Y axis in\na weak attempt to reduce the total half-perimeter wirelength (HPWL).\n\n```tcl\noptimize_mirroring\n```\n\nNo arguments are needed for this function. \n\n## Commands\n\n"], "answer": " To optimize the settings for global placement, the user can interact with the Replace class using a Python program. For instance, the following commands can be used to set various parameters:\\n\\n```python\\ngpl = design.getReplace()\\ngpl.setInitialPlaceMaxIter(iter) # iter is the number of iterations\\ngpl.setSkipIoMode(skip_io) # skip_io is a boolean value\\ngpl.setTimingDrivenMode(timing_driven) # timing_driven is a boolean value\\ngpl.setTimingNetWeightMax(weight) # weight is a numerical value\\n```\\nAfter changing the placement settings, the user can then use the OpenROAD GUI to visualize the placement heatmap by setting the heatmap name as 'Placement'. This can be done using the following commands:\\n\\n```tcl\\ngui::set_heatmap Placement rebuild\\n```\\nTo save the raw data from the heatmap in a comma separated value (CSV) format, use:\\n\\n```tcl\\ngui::dump_heatmap Placement filename\\n```\\nLastly, to optimize the total HPWL, the `optimize_mirroring` command can be applied.\\n\\n```tcl\\noptimize_mirroring\\n```\\n\\n\n"}
{"id": 11, "type": "gui&installation&test", "question": " A user has run the `ibex` design in OpenROAD-flow-scripts from RTL-to-GDS. They now want to utilize the GUI to view setup and hold times of timing paths. How can they utilize the GUI to achieve this?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_20"], "reference_content": ["id:flow-scripts-tutorial_20\n## OpenROAD GUI\n### Viewing Timing Report\n\nClick `Timing` -> `Options` to view and traverse specific timing paths.\nFrom Toolbar, click on the `Timing` icon, View `Timing Report` window added\nat the right side (RHS) of GUI as shown below.\n\n\nIn `Timing Report` Select `Paths` -> `Update`, `Paths` should be integer\nnumbers. The number of timing paths should be displayed in the current\nwindow as follows:\n\n\nSelect `Setup` or `Hold` tabs and view required arrival times and\nslack for each timing path segment.\n\nFor each `Setup` or `Hold` path group, path details have a specific `pin\nname, Time, Delay, Slew and Load` value with the clock to register, register\nto register and register to output data path.\n\n"], "answer": " In the OpenROAD GUI, the user can view and traverse specific timing paths by navigating to `Timing` -> `Options`. \\n\\nIn the `Timing Report`, select `Paths` -> `Update`. \\n\\nTo view required arrival times and slack for each timing path segment, select either the `Setup` or `Hold` tabs. \\n\\nFor each `Setup` or `Hold` path group, path details have a specific `pin name, Time, Delay, Slew and Load` value with the clock to register, register to register and register to output data path. This information provides insight into the setup and hold times of the timing paths.\\n\\n\n"}
{"id": 12, "type": "vlsi_flow", "question": " The users decide to optimize their design with the aim of reducing the chip area. They want to apply a method of adding buffers to decrease certain costs, and to build a power grid. Later, they need to generate a Verilog netlist of the design. Finally, they would like to present the optimized design on GUI. How can this be done with OpenROAD?\n", "ref_num": 7, "reference": ["gui_8", "gate_resizing_6", "power_distribution_network_generator_1", "parasitics_extraction_7", "gui_11", "gui_9", "flow-scripts-tutorial_20"], "reference_content": ["id:gui_8\n### Support\n\nDetermine is the GUI is active:\n\n```\ngui::enabled\n```\n\nAnnounce to the GUI that a design was loaded \n(note: this is only needed when the design was loaded through the odb API and not via ``read_def`` or ``read_db``):\n\n```\ngui::design_created\n```\n\nTo load the results of a DRC report:\n\n```\ngui::load_drc filename\n```\n\n## Commands\n\n", "id:gate_resizing_6\n### Buffer Ports\n\nThe `buffer_ports -inputs` command adds a buffer between the input and its\nloads.  The `buffer_ports -outputs` adds a buffer between the port driver\nand the output port. Inserting buffers on input and output ports makes\nthe block input capacitances and output drives independent of the block\ninternals.\n\n```tcl\nbuffer_ports \n    [-inputs] \n    [-outputs] \n    [-max_utilization util]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-inputs`, `-outputs` | Insert a buffer between the input and load, output and load respectively. The default behavior is `-inputs` and `-outputs` set if neither is specified. |\n| `-max_utilization` | Defines the percentage of core area used. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:power_distribution_network_generator_1\n### Build Power Grid\n\nBuild a power grid in accordance with the information specified.\n\n```tcl\npdngen \n    [-skip_trim]\n    [-dont_add_pins]\n    [-reset]\n    [-ripup]\n    [-report_only]\n    [-failed_via_report file]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-skip_trim` | Skip the metal trim step, which attempts to remove metal stubs. |\n| `-dont_add_pins` | Prevent the creation of block pins. |\n| `-reset` | Reset the grid and domain specifications. |\n| `-ripup` | Ripup the existing power grid, as specified by the voltage domains. |\n| `-report_only` | Print the current specifications. |\n| `-failed_via_report` | Generate a report file that can be viewed in the DRC viewer for all the failed vias (i.e., those that did not get built or were removed). |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:parasitics_extraction_7\n### Generate verilog netlist\n\n`bench_verilog` is used after the `bench_wires` command. This command\ngenerates a Verilog netlist of the generated pattern layout by the `bench_wires`\ncommand.\n\nThis command is optional when running the Extraction Rules generation\nflow. This step is required if the favorite extraction tool (i.e., reference\nextractor) requires a Verilog netlist to extract parasitics of the pattern layout.\n\n\n```tcl\nbench_verilog\n    [filename]                    \n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `filename` | Name for the Verilog output file (e.g., `output.v`). |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gui_11\n### Selections\n\nTo add a single net to the selected items:\n\n```\ngui::selection_add_net name\n```\n\nOptions description:\n- ``name`` name of the net to add.\n\nTo add several nets to the selected items:\n\n```\ngui::selection_add_nets name_regex\n```\n\nOptions description:\n- ``name_regex`` regular expression of the net names to add.\n\nTo add a single instance to the selected items:\n\n```\ngui::selection_add_inst name\n```\n\nOptions description:\n- ``name`` name of the instance to add.\n\nTo add several instances to the selected items:\n\n```\ngui::selection_add_insts name_regex\n```\n\nOptions description:\n- ``name_regex`` regular expression of the instance names to add.\n\nTo add items at a specific point or in an area:\n\n```\ngui::select_at x y\ngui::select_at x y append\ngui::select_at x0 y0 x1 y1\ngui::select_at x0 y0 x1 y1 append\n```\n\nOptions description:\n- ``x, y`` point in the layout area in microns.\n- ``x0, y0`` first corner of the layout area in microns.\n- ``x1, y1`` second corner of the layout area in microns.\n- ``append`` if ``true`` (the default value) append the new selections to the current selection list, else replace the selection list with the new selections.\n\nTo navigate through multiple selected items:\n\n```\ngui::select_next\ngui::select_previous\n```\n\nReturns: current index of the selected item.\n\nTo clear the current set of selected items:\n\n```\ngui::clear_selections\n```\n\nTo get the properties for the current selection in the Inspector:\n\n```\ngui::get_selection_property name\n```\n\nOptions description:\n- ``name`` name of the property. For example, ``Type`` for object type or ``bbox`` for the bounding box of the object.\n\nTo animate the current selection in the Inspector:\n\n```\ngui::selection_animate\ngui::selection_animate repeat\n```\n\nOptions description:\n- ``repeat``: indicate how many times the animation should repeat, default value is 0 repeats. If the value is 0, the animation will repeat indefinitely.\n\n## Commands\n\n", "id:gui_9\n### Opening and closing\n\nTo open the GUI from the command-line (this command does not return until the GUI is closed):\n\n```\ngui::show\ngui::show script\ngui::show script interactive\n```\n\nOptions description:\n- ``script`` TCL script to evaluate in the GUI.\n- ``interactive`` indicates if true the GUI should open in an interactive session (default), or if false that the GUI would execute the script and return to the terminal.\n\nTo close the GUI and return to the command-line:\n\n```\ngui::hide\n```\n\n## Commands\n\n", "id:flow-scripts-tutorial_20\n## OpenROAD GUI\n### Viewing Timing Report\n\nClick `Timing` -> `Options` to view and traverse specific timing paths.\nFrom Toolbar, click on the `Timing` icon, View `Timing Report` window added\nat the right side (RHS) of GUI as shown below.\n\n\nIn `Timing Report` Select `Paths` -> `Update`, `Paths` should be integer\nnumbers. The number of timing paths should be displayed in the current\nwindow as follows:\n\n\nSelect `Setup` or `Hold` tabs and view required arrival times and\nslack for each timing path segment.\n\nFor each `Setup` or `Hold` path group, path details have a specific `pin\nname, Time, Delay, Slew and Load` value with the clock to register, register\nto register and register to output data path.\n\n"], "answer": " Firstly, the users need to make sure the design is loaded. If their design is loaded through the odb API, use `gui::design_created` to announce this to the GUI. \\n\\nThen, to apply buffer insertion, which makes the block input capacitances and output drives independent of block internals, they can use the command:\\n\\n```tcl\\nbuffer_ports\\n    -inputs\\n    -outputs\\n    -max_utilization util\\n```\\n\\nHere, `util` refers to the percentage of core area used.\\n\\nNext, to build a power grid according to the information they defined previously, they can use the command:\\n\\n```tcl\\npdngen\\n```\\n\\nTo generate a Verilog netlist of their design, they need to execute the command:\\n\\n```tcl\\nbench_verilog filename\\n```\\n\\nHere, `filename` should be replaced with the name they want for the Verilog output file.\\n\\nFinally, for presenting the optimized design on GUI, first, if GUI is closed, they need to open it using the command `gui::show`. Then, they need to add nets, instances or items at specific points. For example, to add a single instance to the selected item, they can use the command `gui::selection_add_inst name`. Here, `name` should be replaced with the name of the instance they want to add.\\n\\nFor navigating through multiple selected items, they can use `gui::select_next` or `gui::select_previous`. To clear the current set of selected items, they can use `gui::clear_selection`.\\n\\nIf they want to get the properties for the current selection, they can use `gui::get_selection_property name`. Here, `name` should be replaced with the name of the property they want to access. For example, `bbox` for the bounding box of the object.\\n\\n\n"}
{"id": 13, "type": "gui&installation&test", "question": " Users are trying to enhance their design in order to suit the requirements of a specific technology. They need to add new fields in a database object, show it with GUI, and after several modifications, they desire to close GUI. How can it be done?\n", "ref_num": 2, "reference": ["add_new_fileds_0", "gui_9"], "reference_content": ["id:add_new_fileds_0\n# Adding new fields in DB Object\n\nFor example `add_pitchDiag` in object `DbTechLayer`.\n\n|   | Action                                                 | File              | Source Code                                                                        |\n|---|--------------------------------------------------------|-------------------|------------------------------------------------------------------------------------|\n| 1 | Add Fields at the .h file                              | `dbTechLayer.h`   |                                                                                    |\n| 2 | Define a keyword for db rev number                     | `dbDatabase.h`    | `#define ADS_DB_DF58 52`                                                           |\n| 3 | Set the current rev number same as                     | `dbDatabase.h`    | `#define ADS_DB_SCHEMA_MINOR 52`                                                   |\n| 4 | Stream in new fields Conditionally upon Schema number  | `dbTechLayer.cpp` | `if ( stream.getDatabase()->isSchema(ADS_DB_DF58) ) { stream >> layer._pitchDiag;` |\n| 5 | Stream out new fields Conditionally upon Schema number | `dbTechLayer.cpp` | `if ( stream.getDatabase()->isSchema(ADS_DB_DF58) ) { stream << layer._pitchDiag;` |\n| 6 | Conditionally Diff new fields                          | `dbTechLayer.cpp` | `if ( stream.getDatabase()->isSchema(ADS_DB_DF58) ) { DIFF_FIELD(_pitchDiag);`     |\n| 7 | Conditionally Diff Out new fields                      | `dbTechLayer.cpp` | `if ( stream.getDatabase()->isSchema(ADS_DB_DF58) ) { DIFF_OUT_FIELD(_pitchDiag);` |\n| 8 | Created access APIs to the fields                      | `dbTechLayer.cpp` | `\"dbTechLayer::getPitchDiag(), dbTechLayer::setPitchDiag( int pitch )\"`            |\n", "id:gui_9\n### Opening and closing\n\nTo open the GUI from the command-line (this command does not return until the GUI is closed):\n\n```\ngui::show\ngui::show script\ngui::show script interactive\n```\n\nOptions description:\n- ``script`` TCL script to evaluate in the GUI.\n- ``interactive`` indicates if true the GUI should open in an interactive session (default), or if false that the GUI would execute the script and return to the terminal.\n\nTo close the GUI and return to the command-line:\n\n```\ngui::hide\n```\n\n## Commands\n\n"], "answer": " To add new fields in the database object (let's assume `dbTechLayer`), follow these steps:\\n\\n1. Add fields in the .h file according to your needs (`dbTechLayer.h`).\\n2. Define a keyword for db rev number (`#define ADS_DB_DF58 52` in `dbDatabase.h`).\\n3. Set the current rev number same as the one defined (`#define ADS_DB_SCHEMA_MINOR 52` in `dbDatabase.h`).\\n4. Conditionally stream in/out new fields upon Schema number (`if (stream.getDatabase()->isSchema(ADS_DB_DF58) ) { stream >> / << layer._pitchDiag;` in `dbTechLayer.cpp`).\\n5. Conditionally Diff in/out new fields (`if (stream.getDatabase()->isSchema(ADS_DB_DF58) ) { DIFF_FIELD / DIFF_OUT_FIELD(_pitchDiag);` in `dbTechLayer.cpp`). \\n6. Create access APIs to the fields (`\\\"dbTechLayer::getPitchDiag(), dbTechLayer::setPitchDiag( int pitch )\\\"` in `dbTechLayer.cpp`).\\n\\nAfter modifying the design, if users want to view it on the GUI, they can use the `gui::show` command. If they prefer an interactive GUI, they can use the command `gui::show interactive`.\\n\\nWhen the users want to close the GUI, they can use the `gui::hide` command which properly closes the GUI and returns to the command-line.\\n\\n\n"}
{"id": 14, "type": "vlsi_flow", "question": " What sequence of actions would a user need to take in order to perform a global route debug mode, tracing a specific net, with Steiner tree visualization?\n", "ref_num": 1, "reference": ["global_routing_15"], "reference_content": ["id:global_routing_15\n### Debug Mode\n\nThe `global_route_debug` command allows you to start a debug mode to view the status of the Steiner Trees.\nIt also allows you to dump the input positions for the Steiner tree creation of a net.\nThis must be used before calling the `global_route` command. \nSet the name of the net and the trees that you want to visualize.\n\n```tcl\nglobal_route_debug \n    [-st]\n    [-rst]\n    [-tree2D]\n    [-tree3D]\n    [-saveSttInput file_name]\n    [-net net_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-st` | Show the Steiner Tree generated by `stt`. |\n| `-rst` | Show the Rectilinear Steiner Tree generated by `grt`. |\n| `-tree2D` | Show the Rectilinear Steiner Tree generated by `grt` after the overflow iterations. |\n| `-tree3D` | Show the 3D Rectilinear Steiner Tree post-layer assignment. |\n| `-saveSttInput` | File name to save `stt` input of a net. |\n| `-net` | The name of the net name to be displayed. |\n\n## Example scripts\n\nExamples scripts demonstrating how to run FastRoute on a sample design of `gcd` as follows:\n\n```shell\n./test/gcd.tcl\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Debugging in Global Route and Steiner tree visualization can be achieved with commands as follows:\\n\\n```tcl\\nglobal_route_debug \\n    [-st]\\n    [-net net_name]\\n```\\n\\n\n"}
{"id": 15, "type": "functionality", "question": " I am trying to place a pin on my semiconductor design using OpenROAD, but the pin placement seems to impact my routing results despite the use of the `place_pin` command. The design's pin is to be placed on a specific signal layer during the routing stage. Can the routing stage potentially influence pin placement, or do I have to troubleshoot another aspect of my design flow?\n", "ref_num": 5, "reference": ["get_start_2", "flow-scripts-tutorial_15", "global_routing_2", "pin_placement_8", "global_routing_15"], "reference_content": ["id:get_start_2\n# OpenROAD\n## Getting Started with OpenROAD-flow-scripts\n\nOpenROAD provides [OpenROAD-flow-scripts](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts)\nas a native, ready-to-use prototyping and tapeout flow. However,\nit also enables the creation of any custom flow controllers based\non the underlying tools, database and analysis engines. Please refer to the flow documentation [here](https://openroad-flow-scripts.readthedocs.io/en/latest/).\n\nOpenROAD-flow-scripts (ORFS) is a fully autonomous, RTL-GDSII flow\nfor rapid architecture and design space exploration, early prediction\nof QoR and detailed physical design implementation. However, ORFS\nalso enables manual intervention for finer user control of individual\nflow stages through Tcl commands and Python APIs.\n\nFigure below shows the main stages of the OpenROAD-flow-scripts:\n\n```{mermaid}\n:align: center\n\n%%{init: { 'logLevel': 'debug', 'theme': 'dark'\n  } }%%\ntimeline\n  title RTL-GDSII Using OpenROAD-flow-scripts\n  Synthesis\n    : Inputs  [RTL, SDC, .lib, .lef]\n    : Logic Synthesis  (Yosys)\n    : Output files  [Netlist, SDC]\n  Floorplan\n    : Floorplan Initialization\n    : IO placement  (random)\n    : Timing-driven mixed-size placement\n    : Macro placement\n    : Tapcell and welltie insertion\n    : PDN generation\n  Placement\n    : Global placement without placed IOs\n    : IO placement  (optimized)\n    : Global placement with placed IOs\n    : Resizing and buffering\n    : Detailed placement\n  CTS : Clock Tree Synthesis\n    : Timing optimization\n    : Filler cell insertion\n  Routing\n    : Global Routing\n    : Detailed Routing\n  Finishing\n    : Metal Fill insertion\n    : Signoff timing report\n    : Generate GDSII  (KLayout)\n    : DRC/LVS check (KLayout)\n```\n\nHere are the main steps for a physical design implementation\nusing OpenROAD;\n\n- `Floorplanning`\n  - Floorplan initialization - define the chip area, utilization\n  - IO pin placement (for designs without pads)\n  - Tap cell and well tie insertion\n  - PDN- power distribution network creation\n- `Global Placement` \n  - Macro placement (RAMs, embedded macros)\n  - Standard cell placement\n  - Automatic placement optimization and repair for max slew,\n    max capacitance, and max fanout violations and long wires\n- `Detailed Placement`\n  - Legalize placement - align to grid, adhere to design rules\n  - Incremental timing analysis for early estimates\n- `Clock Tree Synthesis` \n  - Insert buffers and resize for high fanout nets\n- `Optimize setup/hold timing`\n- `Global Routing`\n  - Antenna repair\n  - Create routing guides\n- `Detailed Routing`\n  - Legalize routes, DRC-correct routing to meet timing, power\n    constraints\n- `Chip Finishing`\n  - Parasitic extraction using OpenRCX\n  - Final timing verification\n  - Final physical verification\n  - Dummy metal fill for manufacturability\n  - Use KLayout or Magic using generated GDS for DRC signoff\n\n", "id:flow-scripts-tutorial_15\n\n## OpenROAD GUI\n\nThe GUI allows users to select, control, highlight and navigate the\ndesign hierarchy and design objects (nets, pins, instances, paths, etc.)\nthrough detailed visualization and customization options. Find details\non how to use the [GUI](https://openroad.readthedocs.io/en/latest/main/README.html#gui). All the windows\naside from the layout are docking windows that can be undocked.  Also it\ncan be closed and reopened from the Windows menu.\n\n\nNote:  When you are using remote access, you will need to include -Y (or -X) option in your command to\nenable X11 applications to function properly over the network. By using the command \"ssh -Y\" followed\nby the remote servers' address or hostname, you can establish a secure connection and activate X11 forwarding.\nThis feature enables you to run graphical programs on the remote server and have their windows display\non your local machines desktop environment.\n\n\nIn this section, learn how to:\n\n1. Visualize design hierarchy\n2. Load ODB files for floorplan and layout visualization\n3. Trace the synthesized clock tree to view hierarchy and buffers\n4. Use heat maps to view congestion and observe the effect of placement\n5. View and trace critical timing paths\n6. Set display control options\n7. Zoom to object from inspector\n\nIf you have completed the RTL-GDS flow, then proceed to view the final\nGDS file under results directory `./results/sky130hd/ibex/base/`\n\nFor the `ibex` design uncomment the `DESIGN_CONFIG`\nvariable in the `Makefile` available [here](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/Makefile).\n\n```\n# DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk\nDESIGN_CONFIG=./designs/sky130hd/ibex/config.mk\n# DESIGN_CONFIG=./designs/sky130hd/aes/config.mk\n```\n\n```shell\nmake gui_final\n```\n\n", "id:global_routing_2\n### Set Routing Layers\n\n```tcl\nset_routing_layers \n    [-signal min-max]\n    [-clock min-max]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-signal` | Set the min and max routing signal layer (names) in this format \"%s-%s\". |\n| `-clock` | Set the min and max routing clock layer (names) in this format \"%s-%s\". |\n\nExample: `set_routing_layers -signal Metal2-Metal10 -clock Metal6-Metal9`\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:pin_placement_8\n### Place Individual Pin\n\nThe `place_pin` command places a specific pin in the specified location with the specified size.\nIt is recommended that individual pins be placed before the `place_pins` command,\nas the routing tracks occupied by these individual pins will be blocked, preventing overlaps.\n\nTo place an individual pin:\n\n```tcl\nplace_pin \n    -pin_name pin_name\n    -layer layer\n    -location {x y}\n    [-pin_size {width height}]\n    [-force_to_die_boundary]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-pin_name` | The name of a pin of the design. |\n| `-layer` | The routing layer where the pin is placed. |\n| `-location` | The center of the pin (in microns). |\n| `-pin_size` | The width and height of the pin (in microns). |\n| `-force_to_die_boundary` | When this flag is enabled, the pin will be snapped to the nearest routing track, next to the die boundary. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:global_routing_15\n### Debug Mode\n\nThe `global_route_debug` command allows you to start a debug mode to view the status of the Steiner Trees.\nIt also allows you to dump the input positions for the Steiner tree creation of a net.\nThis must be used before calling the `global_route` command. \nSet the name of the net and the trees that you want to visualize.\n\n```tcl\nglobal_route_debug \n    [-st]\n    [-rst]\n    [-tree2D]\n    [-tree3D]\n    [-saveSttInput file_name]\n    [-net net_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-st` | Show the Steiner Tree generated by `stt`. |\n| `-rst` | Show the Rectilinear Steiner Tree generated by `grt`. |\n| `-tree2D` | Show the Rectilinear Steiner Tree generated by `grt` after the overflow iterations. |\n| `-tree3D` | Show the 3D Rectilinear Steiner Tree post-layer assignment. |\n| `-saveSttInput` | File name to save `stt` input of a net. |\n| `-net` | The name of the net name to be displayed. |\n\n## Example scripts\n\nExamples scripts demonstrating how to run FastRoute on a sample design of `gcd` as follows:\n\n```shell\n./test/gcd.tcl\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The routing layer is indeed a crucial aspect which might be influencing the pin placement. You should check the signal routing layers set through `set_routing_layers` command, confirming whether the layer intended for your pin is included, and do the adjustment if necessary. \\n\\nFurther, you might want to use the `global_route_debug` command to effectively debug the Steiner Tree status for your specific net, which can potentially uncover issues in the global routing affecting your pin's placement. \\n\\nIt should be noted that pin placement can indeed cause overlaps and impact the future routing stage. Therefore, it might be useful to ensure that the routing tracks occupied by the placed pin will be blocked, effectively mitigating overlaps. \\n\\nTherefore, the order of operations and dependencies among different commands are not negligible and can affect your final results. \\n\\nFinally, as a reminder, since the `set_routing_layers` and the `global_route_debug` commands are Tcl commands, they would not work if not properly integrated into your design flow's script. You could also consider using OpenROAD's GUI to help visualize and potentially debug the placement and routing of the pin.\n"}
{"id": 16, "type": "vlsi_flow", "question": " During the global routing process using OpenROAD, I am not always obtaining consistent results despite using the same design scripts. What could be the cause for this inconsistency, and how can I take steps to better control my routing results?\n", "ref_num": 1, "reference": ["global_routing_8"], "reference_content": ["id:global_routing_8\n### Set Global Routing Randomness\n\nThe randomized global routing shuffles the\norder of the nets and randomly subtracts or adds to the capacities of\na random set of edges. \n\n```tcl\nset_global_routing_random \n    [-seed seed]\n    [-capacities_perturbation_percentage percent]\n    [-perturbation_amount value]\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-seed` | Sets the random seed (must be non-zero for randomization). |\n| `-capacities_perturbation_percentage` | Sets the percentage of edges whose capacities are perturbed. By default, the edge capacities are perturbed by adding or subtracting 1 (track) from the original capacity.  |\n| `-perturbation_amount` | Sets the perturbation value of the edge capacities. This option is only meaningful when `-capacities_perturbation_percentage` is used. |\n\nExample:\n`set_global_routing_random -seed 42 \\\n  -capacities_perturbation_percentage 50 \\\n  -perturbation_amount 2`\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Randomness introduced in the global routing process might be the source of the inconsistency you're experiencing. OpenROAD has a `set_global_routing_random` command that randomizes global routing by shuffling the order of the nets, adding or subtracting from the capacities of a random set of edges. \\n\\nIf you have activated this setting without realizing it, each run of global routing could be subject to fluctuations generated by this random routing process, thus leading to inconsistent results. You can control this randomness to some extent by setting the random seed through `-seed` option in this command, which ensures that the randomization process is reproducible when executing scripts multiple times.\\n\\nRemember that fluctuations in the results due to randomness do not necessarily imply an issue with your design scripts, nor does it indicate an issue with OpenROAD. Rather, it offers a different perspective or trajectory within the large design space of your digital design. \\n\\nIf you decide to manage the randomness in your global router more effectively, you should be aware that you may also need to adjust other parameters like the capacities perturbation percentage or perturbation amount to achieve desired layout results.\\n\\n\n"}
{"id": 17, "type": "functionality", "question": " Once my chip design has been finalized in OpenROAD-flow-scripts, is it feasible to remove the entire bump array from my design if it is no longer required, and will this impact my design's functionality or performance in any way?\n", "ref_num": 1, "reference": ["chip-level_connections_3"], "reference_content": ["id:chip-level_connections_3\n### Removing Entire Bump Array\n\nTo remove a bump array.\n\n```tcl\nremove_io_bump_array -bump master\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-bump` | Name of the bump master. |\n\nExample usage:\n\n```tcl\nremove_io_bump_array -bump BUMP\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Yes, OpenROAD-flow-scripts provide the option to remove an entire bump array from your design using the `remove_io_bump_array` command. However, it should be noted that the IO bump array is often crucial for the IO pads or the power/ground connections, and removing this could potentially impact the functionality of your design, both logically and physically. \\n\\nTherefore, if you intend to remove the bump array, it's generally recommended to have a deep understanding of the design and its dependency on the bump array. Also, in removing the bump array, the design should have alternative power/ground and IO pads connections or designs might experience wide-ranging issues. \\n\\nIn this context, it is advised to make the change with caution, and re-check the design rule and functionality after the removal.\\n\\n\n"}
{"id": 18, "type": "vlsi_flow", "question": " Assuming a user needs to insert filler cells, analyze clock tree synthesis (CTS), remove the buffers and analyze the net using OpenROAD, how can they go about it?\\n\\n\n", "ref_num": 4, "reference": ["flow-scripts-tutorial_45", "clock_tree_synthesis_3", "gate_resizing_7", "IR_Drop_analysis_4"], "reference_content": ["id:flow-scripts-tutorial_45\n\n### Clock Tree Synthesis\n\n### Adding Filler Cells\n\nFiller cells fills gaps between detail-placed instances to connect the\npower and ground rails in the rows. Filler cells have no logical\nconnectivity. These cells are provided continuity in the rows for VDD\nand VSS nets and it also contains substrate nwell connection to improve\nsubstrate biasing.\n\n`filler_masters` is a list of master/macro names to use for\nfilling the gaps.\n\nRefer to the following built-in example [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/dpl/test/fillers1.tcl)\nto learn about filler cell insertion.\n\nTo view this in OpenROAD GUI run the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/grt/test/\nopenroad -gui\n```\n\nIn the `Tcl Commands` section of GUI,run following commands:\n\n```tcl\nsource \"helpers.tcl\"\nread_lef \"Nangate45/Nangate45.lef\"\nread_def \"gcd.def\"\n```\n\nLoaded DEF view without filler insertion:\n\n![Without_Fill_Cell_Insertion](./images/wo_fillcell_insertion.webp)\n\nRun following commands for filler cell insertion:\n```\nset filler_master [list FILLCELL_X1 FILLCELL_X2 FILLCELL_X4 FILLCELL_X8 FILLCELL_X16]\nfiller_placement $filler_master\n```\n\nView the resulting fill cell insertion as follows:\n\n![Fill_Cell_Insertion](./images/fillcell_insertion.webp)\n\nFiller cells removed with `remove_fillers` command.\n\n", "id:clock_tree_synthesis_3\n### Report CTS\n\nAnother command available from `cts` is `report_cts`. It is used to\nextract metrics after a successful `clock_tree_synthesis` run. These are:\n \n- Number of Clock Roots\n- Number of Buffers Inserted\n- Number of Clock Subnets\n- Number of Sinks.  \n\n```tcl\nreport_cts \n    [-out_file file]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-out_file` | The file to save `cts` reports. If this parameter is omitted, the report is streamed to `stdout` and not saved. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gate_resizing_7\n### Remove Buffers\n\nUse the `remove_buffers` command to remove buffers inserted by synthesis. This\nstep is recommended before using `repair_design` so that there is more flexibility\nin buffering nets. \n\n```tcl\nremove_buffers\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:IR_Drop_analysis_4\n# IR Drop Analysis\n### Useful Developer Commands\n\nIf you are a developer, you might find these useful. More details can be found in the [source file](./src/pdnsim.cpp) or the [swig file](./src/pdnsim.i).\n\n| Command Name | Description |\n| ----- | ----- |\n| `find_net` | Get a reference to net name. | \n\n"], "answer": " You can follow these steps to perform the operations you need:\\n\\n1. Insert the filler cells according to 'fillers1.tcl', as described in the 'flow-scripts-tutorial_45' document. Let's say you have ‘FILLCELL_X1’, ‘FILLCELL_X2’, ‘FILLCELL_X4’, ‘FILLCELL_X8’, ‘FILLCELL_X16’ as your filler masters. You can insert them using the following commands:\\n```tcl\\nset filler_master [list FILLCELL_X1 FILLCELL_X2 FILLCELL_X4 FILLCELL_X8 FILLCELL_X16]\\nfiller_placement $filler_master\\n```\\n\\n2. Perform clock tree synthesis (CTS) and generate a report using the `report_cts` command as described in the 'clock_tree_synthesis_3' document. Accumulate all the results in an output file named 'cts_report.txt':\\n```tcl\\nreport_cts -out_file cts_report.txt\\n```\\n\\n3. Remove buffers inserted by synthesis using the `remove_buffers` command from the 'gate_resizing_7' document:\\n```tcl\\nremove_buffers\\n```\\n\\n4. Finally, analyze the net using the 'find_net' command found in the 'IR_Drop_analysis_4' documentation. If 'net1' is the name of the net you want to find:\\n```tcl\\nfind_net net1\\n```\\n\\n\n"}
{"id": 19, "type": "functionality", "question": " One user of OpenROAD wants to place macros on a design using Hier-RTLMP algorithm (via `rtl_macro_placer` command). However, he is unsure how to set the parameters optimally for his area critical design. Can you recommend an optimised set of parameters?\n", "ref_num": 1, "reference": ["hierarchical_macro_placement_1"], "reference_content": ["id:hierarchical_macro_placement_1\n### Hier-RTLMP algorithm\n\n```tcl\nrtl_macro_placer \n    [-max_num_macro max_num_macro]\n    [-min_num_macro min_num_macro]\n    [-max_num_inst max_num_inst]  \n    [-min_num_inst min_num_inst] \n    [-tolerance tolerance]     \n    [-max_num_level max_num_level] \n    [-coarsening_ratio coarsening_ratio]\n    [-num_bundled_ios num_bundled_ios]\n    [-large_net_threshold large_net_threshold]\n    [-signature_net_threshold signature_net_threshold]\n    [-halo_width halo_width] \n    [-fence_lx fence_lx] \n    [-fence_ly fence_ly]\n    [-fence_ux fence_ux]\n    [-fence_uy fence_uy]\n    [-area_weight area_weight] \n    [-outline_weight outline_weight] \n    [-wirelength_weight wirelength_weight]\n    [-guidance_weight guidance_weight]\n    [-fence_weight fence_weight] \n    [-boundary_weight boundary_weight]\n    [-notch_weight notch_weight]\n    [-macro_blockage_weight macro_blockage_weight]\n    [-pin_access_th pin_access_th]\n    [-target_util target_util]\n    [-target_dead_space target_dead_space]\n    [-min_ar min_ar]\n    [-snap_layer snap_layer]\n    [-bus_planning]\n    [-report_directory report_directory]\n    [-write_macro_placement file_name]\n```\n\n#### Generic Parameters\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-max_num_macro`, `-min_num_macro` | Maximum/minimum number of macros in a cluster. The default value is `0` for both, and the allowed values are integers `[0, MAX_INT]`. |\n| `-max_num_inst`, `-min_num_inst` | Maximum/minimum number of standard cells in a cluster. The default value is `0` for both, and the allowed values are integers `[0, MAX_INT]`. |\n| `-tolerance` | Add a margin to the minimum and maximum number of macros/std cells in a cluster. For min, we multiply by (1 - `tol`), and for the max (1 + `tol`). This is to improve the robustness of hierarchical clustering. The allowed values are floats `[0, 1)`, and the default value is `0.1`. |\n| `-max_num_level` | Maximum depth of physical hierarchical tree. The default value is `2`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-coarsening_ratio` | The larger the coarsening_ratio, the faster the convergence process. The allowed values are floats, and the default value is `10.0`. |\n| `-num_bundled_ios` | Specifies the number of bundled pins for the left, right, top, and bottom boundaries. The default value is `3`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-large_net_threshold` | Ignore nets with many connections during clustering, such as global nets. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-signature_net_threshold` | Minimum number of connections between two clusters to be identified as connected. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-halo_width` | Horizontal/vertical halo around macros (microns). The allowed values are floats, and the default value is `0.0`. |\n| `-fence_lx`, `-fence_ly`, `-fence_ux`, `-fence_uy` | Defines the global fence bounding box coordinates. The default values are the core area coordinates). |\n| `-pin_access_th` | Specifies the pin access threshold value of macros. The default value is `0.0`, and the allowed values are floats [0,1]. |\n| `-target_util` | Specifies the target utilization of `MixedCluster` and has higher priority than target_dead_space. The allowed values are floats, and the default value is `0.25`. |\n| `-target_dead_space` | Specifies the target dead space percentage, which influences the utilization of `StandardCellCluster`. The allowed values are floats, and the default value is `0.05`. |\n| `-min_ar` | Specifies the minimum aspect ratio $a$, or the ratio of its width to height of a `StandardCellCluster` from $[a, \\frac{1}{a}]$. The allowed values are floats, and the default value is `0.33`. |\n| `-snap_layer` | Snap macro origins to this routing layer track. The default value is 4, and the allowed values are integers `[1, MAX_LAYER]`). |\n| `-bus_planning` | Flag to enable bus planning. We recommend to enable bus planning for technologies with very limited routing layers such as SKY130 and GF180. As for technologies such as NanGate45 and ASAP7, we recommend to keep it disabled. |\n| `-report_directory` | Save reports to this directory. |\n| `-write_macro_placement` | Generates a file with the placement of the macros placed by HierRTLMP flow in the format of multiple calls for the `place_macro` command. |\n\n\n#### Simulated Annealing Weight parameters\n\nDo note that while action probabilities are normalized to 1.0, the weights are not necessarily normalized. \n\n| Switch Name | Description | \n| ----- | ----- |\n| `-area_weight` | Weight for the area of current floorplan.  The allowed values are floats, and the default value is `0.1`. |\n| `-outline_weight` | Weight for violating the fixed outline constraint, meaning that all clusters should be placed within the shape of their parent cluster.  The allowed values are floats, and the default value is `100.0`. |\n| `-wirelength_weight` | Weight for half-perimeter wirelength.  The allowed values are floats, and the default value is `100.0`. |\n| `-guidance_weight` | Weight for guidance cost or clusters being placed near specified regions if users provide such constraints.  The allowed values are floats, and the default value is `10.0`. |\n| `-fence_weight` | Weight for fence cost, or how far the macro is from zero fence violation.  The allowed values are floats, and the default value is `10.0`. |\n| `-boundary_weight` | Weight for the boundary, or how far the hard macro clusters are from boundaries. Note that mixed macro clusters are not pushed, thus not considered in this cost.  The allowed values are floats, and the default value is `50.0`. |\n| `-notch_weight` | Weight for the notch, or the existence of dead space that cannot be used for placement & routing. Note that this cost applies only to hard macro clusters.  The allowed values are floats, and the default value is `10.0`. |\n| `-macro_blockage_weight` | Weight for macro blockage, or the overlapping instances of the macro.  The allowed values are floats, and the default value is `10.0`. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The 'rtl_macro_placer' command can be used for this purpose. An example usage can be:\\n```tcl\\nrtl_macro_placer -max_num_macro 4 -min_num_macro 2 -max_num_inst 1000 -min_num_inst 500 -target_util 0.7 -area_weight 1.0\\n```\\nHere,\\n- the maximum and minimum number of macros in a cluster is set to 4 and 2, respectively.\\n- the maximum and minimum number of standard cells in a cluster is set to 1000 and 500, respectively.\\n- the target utilization is set to 0.7 or 70%. The user can adjust this based on the specific area requirements of the design.\\n- the weight for the area is set to 1.0 emphasizing the importance of the area of the floorplan during simulated annealing. Higher the weight, higher its importance.\\n  \\nThe user can adjust these parameters as per their requirements and should note that the parameters should be set in a way that meets their design constraints and performance requirements.\\n\\n\n"}
{"id": 20, "type": "vlsi_flow", "question": " A user wants to partition a hypergraph in a specific manner. Next, he wishes to define a power grid pattern for his design. The user then proceeds to set a pin offset and then clear IO pin constraints, before requesting for a screenshot of the layout. How can we use OpenROAD application to facilitate these processes?\n", "ref_num": 5, "reference": ["partition_manager_12", "power_distribution_network_generator_3", "global_routing_4", "pin_placement_3", "gui_3"], "reference_content": ["id:partition_manager_12\n### How to partition a hypergraph in the way you would using hMETIS (min-cut partitioning)\n\n```tcl\ntriton_part_hypergraph -hypergraph_file des90.hgr -num_parts 5 -balance_constraint 2 -seed 2\n```\nYou can also check the provided example [here](./examples/min-cut-partitioning/run_openroad.tcl).\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:power_distribution_network_generator_3\n### Define Power Grid (General)\n\nDefine the rules to describe a power grid pattern to be placed in the design.\n\n```{warning}\n`define_pdn_grid` is overloaded with two different signatures. Take note of the arguments when using this function!\n```\n\n```tcl\ndefine_pdn_grid \n    [-name name] \n    [-voltage_domain list_of_domain_names] \n    [-pins list_of_pin_layers] \n    [-starts_with POWER|GROUND] \n    [-starts_with POWER|GROUND] \n    [-obstructions list_of_layers]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-name` | The name to use when referring to this grid definition. |\n| `-voltage_domain` | This grid's voltage domain name. Defaults to the last domain created. |\n| `-pins` | List of layers where the power straps will be promoted to block pins. |\n| `-starts_with` | Use `POWER` or `GROUND`  for the first placed strap. Defaults to `GROUND`. |\n| `-obstructions` | Layers to add routing blockages to avoid DRC violations. |\n\nExample usage:\n\n```tcl\ndefine_pdn_grid -name main_grid -pins {metal7} -voltage_domain {CORE TEMP_ANALOG}\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:global_routing_4\n### Set Pin Offset\n\n```tcl\nset_pin_offset offset \n```\n\n#### Options\n\n| Argument Name | Description | \n| ----- | ----- |\n| `offset` | Pin offset in microns (must be a positive integer). | \n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:pin_placement_3\n### Clear IO Pin Constraints\n\nThe `clear_io_pin_constraints` command clears all the previously-defined\nconstraints and pin shape patterns created with `set_io_pin_constraint` or\n`define_pin_shape_pattern`.\n\n```tcl\nclear_io_pin_constraints\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gui_3\n### Save screenshot of layout\n\nThis command can be both be used when the GUI is active and not active.\n\n```\nsave_image [-resolution microns_per_pixel]\n           [-area {x0 y0 x1 y1}]\n           [-width width]\n           [-display_option {option value}]\n           filename\n```\n\nOptions description:\n- ``filename`` path to save the image to.\n- ``x0, y0`` first corner of the layout area (in microns) to be saved, default is to save what is visible on the screen unless called when gui is not active and then it selected the whole block.\n- ``x1, y1`` second corner of the layout area (in microns) to be saved, default is to save what is visible on the screen unless called when gui is not active and then it selected the whole block.\n- ``microns_per_pixel`` resolution in microns per pixel to use when saving the image, default will match what the GUI has selected.\n- ``width`` width of the output image in pixels, default will be computed from the resolution. Cannot be used with ``-resolution``.\n- ``option`` specific setting for a display option to show or hide specific elements. For example, to hide metal1 ``-display_option {Layers/metal1 false}``, to show routing tracks ``-display_option {Tracks/Pref true}``, or to show everthing ``-display_option {* true}``.\n\n## Commands\n\n"], "answer": " Step 1: Partition a Hypergraph\\nThe user can use the command below to partition a hypergraph:\\n```tcl\\ntriton_part_hypergraph -hypergraph_file des90.hgr -num_parts 5 -balance_constraint 2 -seed 2\\n```\\nStep 2: Define Power Grid\\nThis can be achieved with the following command:\\n```tcl\\ndefine_pdn_grid -name main_grid -pins {metal7} -voltage_domain {CORE TEMP_ANALOG}\\n```\\nStep 3: Set Pin Offset\\nThis can be accomplished with the following command:\\n```tcl\\nset_pin_offset 5\\n```\\nStep 4: Clearing IO Pin Constraints\\nThis is performed using the following command:\\n```tcl\\nclear_io_pin_constraints\\n```\\nStep 5: Save Screenshot of the Layout\\nFinally, the user can obtain a screenshot of the layout using the following command:\\n```tcl\\nsave_image -resolution 1 -area {0 0 100 100} -display_option {Tracks/Pref true} screenshot.png\\n```\\n\n"}
{"id": 21, "type": "functionality", "question": " In a scenario where you need to write the parasitics of specific nets into .spef files for further investigation and analysis, how could you achieve this using OpenROAD?\n", "ref_num": 1, "reference": ["parasitics_extraction_3"], "reference_content": ["id:parasitics_extraction_3\n### Write SPEF\n\nThe `write_spef` command writes the `.spef` output of the parasitics stored\nin the database.\n\n```tcl\nwrite_spef\n    [-net_id net_id]                \n    [-nets nets]\n    filename                     \n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net_id` | Output the parasitics info for specific net IDs. |\n| `-nets` | Net name. |\n| `filename` | Output filename. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Step 1: Identifying the Specific Nets\\nDepending on your design and the context, you should have a way to identify the specific nets you are concerned with. This could be by net_id or net names.\\n\\nStep 2: Writing Parasitics to .spef Files\\nYou can write the parasitics of the specific nets you've identified to a .spef file using the `write_spef` command in OpenROAD. Set the `-net_id` (or `-nets` if using net names) parameter to your identified nets; set the `filename` parameter to your desired output file. Code example:\\n\\n```tcl\\nwrite_spef -net_id net_id_yours output.spef\\n```\\nor\\n```tcl\\nwrite_spef -nets net_name_yours output.spef\\n```\\n\\nNow, you have the parasitics of the specific nets written in the output.spef file. \\n\\n\n"}
{"id": 22, "type": "functionality", "question": " In a certain power-domain aware design, an engineer finds that his isolation strategy needs to be updated. How can the engineer update an existing isolation strategy using the OpenROAD command line interface?\n", "ref_num": 1, "reference": ["read_UPF_utility_5"], "reference_content": ["id:read_UPF_utility_5\n### Create or Update Isolation Strategy\n\n```tcl \nset_isolation\n    [-domain domain]\n    [-applies_to applies_to]\n    [-clamp_value clamp_value]\n    [-isolation_signal isolation_signal]\n    [-isolation_sense isolation_sense]\n    [-location location]\n    [-update]\n    name\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-domain` | Power domain |\n| `-applies_to` | Restricts the strategy to apply one of these (`inputs`, `outputs`, `both`). |\n| `-clamp_value` | Value the isolation can drive (`0`, `1`). |\n| `-isolation_signal` | The control signal for this strategy. |\n| `-isolation_sense` | The active level of isolation control signal. |\n| `-location` | Domain in which isolation cells are placed (`parent`, `self`, `fanout`). |\n| `-update` | Only available if using existing strategy, will error if the strategy doesn't exist. |\n| `name` | Isolation strategy name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Once the needed isolation strategy name is obtained, the engineer can execute the update using the `set_isolation` command:\\n\\n```tcl\\nset_isolation -update -domain <domain> -applies_to <applies> -clamp_value <value> \\n    -isolation_signal <signal> -isolation_sense <sense> -location <location> <strategy_name>\\n```\\nHere, `<domain>`, `<applies>`, `<value>`, `<signal>`, `<sense>`, `<location>` are the updated parameters and `<strategy_name>` is the name of the existing isolation strategy.\\n\\n\n"}
{"id": 23, "type": "functionality", "question": " What are the steps to generate an Extraction Rules file using the `bench_wires` command in OpenROAD and how can one set the resistance and capacitance for a layer?\n", "ref_num": 2, "reference": ["parasitics_extraction_6", "gate_resizing_2"], "reference_content": ["id:parasitics_extraction_6\n### Extraction Rules File Generation\n\nThe `bench_wires` command produces a layout which contains various patterns\nthat are used to characterize per-unit length R and C values. The generated patterns model\nthe lateral, vertical, and diagonal coupling capacitances, as well as ground\ncapacitance effects. This command generates a .def file that contains a number of wire patterns.\n\nThis command is specifically intended for the Extraction Rules file generation only.\n\n```tcl\nbench_wires\n    [-met_cnt mcnt]\n    [-cnt count]\n    [-len wire_len]\n    [-over]\n    [-diag]\n    [-all]\n    [-db_only]\n    [-under_met layer]\n    [-w_list width]\n    [-s_list space]\n    [-over_dist dist]\n    [-under_dist dist]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-met_cnt` | Number of layers used in each pattern. The default value is `-1`, meaning it is not set, and the allowed values are integers `[0, MAX_INT]`. |\n| `-cnt` | Number of wires in each pattern. The default value is `5`, and the default values are integers `[0, MAX_INT]`. |\n| `-len` | Wirelength in microns in the pattern. The default value is `100`, and the allowed values are integers `[0, MAX_INT]`. | \n| `-all` | Consider all different pattern geometries (`over`, `under`, `over_under`, and `diagonal`). |\n| `-db_only` | Run with db values only. All parameters in `bench_wires` are ignored. |\n| `-under_met` | Consider under metal layer. |\n| `-w_list` | Lists of wire width multipliers from the minimum spacing defined in the LEF. |\n| `-s_list` | Lists of wire spacing multipliers from the minimum spacing defined in the LEF. The list will be the input index on the OpenRCX RC table (Extraction Rules file). |\n| `-over_dist`, `-under_dist` | Consider over and under metal distance respectively. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gate_resizing_2\n### Set Layer RC\n\nThe `set_layer_rc` command can be used to set the resistance and capacitance\nfor a layer or via. This is useful if these values are missing from the LEF file,\nor to override the values in the LEF.\n\n```tcl\nset_layer_rc \n    [-layer layer]\n    [-via via_layer]\n    [-resistance res]\n    [-capacitance cap]\n    [-corner corner]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-layer` | Set layer name to modify. Note that the layer must be a routing layer. |\n| `-via` | Select via layer name. Note that via resistance is per cut/via, not area-based. |\n| `-resistance` | Resistance per unit length, same convention as `set_wire_rc`. |\n| `-capacitance` | Capacitance per unit length, same convention as `set_wire_rc`. |\n| `-corner` | Process corner to use. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To generate an Extraction Rules file using the `bench_wires` command, execute the following command:\\n```tcl\\nbench_wires\\n    [-met_cnt 6] \\n    [-cnt 5] \\n    [-len 60] \\n    [-all] \\n    [-db_only] \\n    [-under_met 3] \\n    [-w_list 1,2] \\n    [-s_list 1,2] \\n    [-over_dist 100]\\n    [-under_dist 100]\\n```\\nThe above values are just an example, and you can modify them as per your design specifics.\\n\\nTo set resistance and capacitance for a layer, you can use the 'set_layer_rc' command like:\\n```tcl\\nset_layer_rc \\n    [-layer metal1] \\n    [-resistance 0.010] \\n    [-capacitance 0.002] \\n    [-corner slow]\\n```\\nAgain, the values of resistance and capacitance and layer are examples and can be set as per the given technology library and design requirements.\\n\\n\n"}
{"id": 24, "type": "functionality", "question": " I need to create a functional partition in my design to modularize its functionality. How can I create a partition and export it as Verilog?\n", "ref_num": 1, "reference": ["partition_manager_9"], "reference_content": ["id:partition_manager_9\n### Write Partition to Verilog\n\n```tcl\nwrite_partition_verilog\n    [-port_prefix prefix]\n    [-module_suffix suffix]\n    [file]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-port_prefix` | Port name prefix. |\n| `-module_suffix` | Module name suffix. |\n| `file` | Filename to write partition verilog to. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Assuming a logical partition named \\\"my_partition\\\" exists in your design, the following Tcl command can be used to write it to a Verilog file:\\n\\n```tcl\\nwrite_partition_verilog -port_prefix p_ -module_suffix _m my_partition.v\\n```\\n\\nThis command will write the partition to a Verilog file named \\\"my_partition.v\\\", with each port name prefixed by \\\"p_\\\" and each module name suffixed by \\\"_m\\\". This can help to distinguish the partitioned elements from those of the original design when they are used together.\\n\\nPlease replace \\\"my_partition.v\\\" with your desired filename.\\n\\n\n"}
{"id": 25, "type": "gui&installation&test", "question": " In my design, I want to synthesize a clock tree. After that, I want to highlight the clock nets on the OpenROAD GUI. How can I achieve that?\n", "ref_num": 2, "reference": ["clock_tree_synthesis_2", "gui_12"], "reference_content": ["id:clock_tree_synthesis_2\n### Clock Tree Synthesis\n\n```tcl\nclock_tree_synthesis \n    -buf_list <list_of_buffers>\n    [-root_buf root_buf]\n    [-wire_unit wire_unit]\n    [-clk_nets <list_of_clk_nets>]\n    [-distance_between_buffers]\n    [-branching_point_buffers_distance]\n    [-clustering_exponent]\n    [-clustering_unbalance_ratio]\n    [-sink_clustering_enable]\n    [-sink_clustering_size cluster_size]\n    [-sink_clustering_max_diameter max_diameter]\n    [-balance_levels]\n    [-num_static_layers]\n    [-sink_clustering_buffer]\n    [-use_dummy_load]\n    [-insertion_delay]\n    [-sink_buffer_max_cap_derate derate_value]\n    [-delay_buffer_derate derate_value]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-buf_list` | Tcl list of master cells (buffers) that will be considered when making the wire segments (e.g. `{BUFXX, BUFYY}`). |\n| `-root_buffer` | The master cell of the buffer that serves as root for the clock tree. If this parameter is omitted, the first master cell from `-buf_list` is taken. |\n| `-wire_unit` | Minimum unit distance between buffers for a specific wire. If this parameter is omitted, the code gets the value from ten times the height of `-root_buffer`. |\n| `-clk_nets` | String containing the names of the clock roots. If this parameter is omitted, `cts` automatically looks for the clock roots automatically. |\n| `-distance_between_buffers` | Distance (in microns) between buffers that `cts` should use when creating the tree. When using this parameter, the clock tree algorithm is simplified and only uses a fraction of the segments from the LUT. |\n| `-branching_point_buffers_distance` | Distance (in microns) that a branch has to have in order for a buffer to be inserted on a branch end-point. This requires the `-distance_between_buffers` value to be set. |\n| `-clustering_exponent` | Value that determines the power used on the difference between sink and means on the CKMeans clustering algorithm. The default value is `4`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-clustering_unbalance_ratio` | Value determines each cluster's maximum capacity during CKMeans. A value of `0.5` (i.e., 50%) means that each cluster will have exactly half of all sinks for a specific region (half for each branch). The default value is `0.6`, and the allowed values are floats `[0, 1.0]`. |\n| `-sink_clustering_enable` | Enables pre-clustering of sinks to create one level of sub-tree before building H-tree. Each cluster is driven by buffer which becomes end point of H-tree structure. |\n| `-sink_clustering_size` | Specifies the maximum number of sinks per cluster. The default value is `20`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-sink_clustering_max_diameter` | Specifies maximum diameter (in microns) of sink cluster. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-balance_levels` | Attempt to keep a similar number of levels in the clock tree across non-register cells (e.g., clock-gate or inverter). The default value is `False`, and the allowed values are bool. |\n| `-clk_nets` | String containing the names of the clock roots. If this parameter is omitted, `cts` looks for the clock roots automatically. |\n| `-num_static_layers` | Set the number of static layers. The default value is `0`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-sink_clustering_buffer` | Set the sink clustering buffer(s) to be used. |\n| `-obstruction_aware` | Enables obstruction-aware buffering such that clock buffers are not placed on top of blockages or hard macros. This option may reduce legalizer displacement, leading to better latency, skew or timing QoR.  The default value is `False`, and the allowed values are bool. |\n| `-apply_ndr` | Applies 2X spacing non-default rule to all clock nets except leaf-level nets. The default value is `False`. |\n| `-no_insertion_delay` | Don't consider insertion delays in macro timing models in balancing latencies between macro cells and registers. This option prevents construction of separate clock trees for macro cells and registers.  The default value is `False`. |\n| `-use_dummy_load` | Applies dummy buffer or inverter cells at clock tree leaves to balance loads.  The default values is `False`. |\n| `-sink_buffer_max_cap_derate` | Use this option to control automatic buffer selection. To favor strong(weak) drive strength buffers use a small(large) value.  The default value is `0.01`, meaning that buffers are selected by derating max cap limit by 0.01. The value of 1.0 means no derating of max cap limit.  |\n| `-delay_buffer_derate` | This option is used with -insertion_delay option that balances latencies between macro cells and registers by inserting delay buffers.  The default values is `1.0`, meaning all needed delay buffers are inserted.  Value of 0.5 means only half of necessary delay buffers are inserted.  Value of 0.0 means no insertion of delay buffers. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gui_12\n### Highlighting\n\nTo highlight a net:\n\n```\ngui::highlight_net name\ngui::highlight_net name highlight_group\n```\n\nOptions description:\n- ``name`` name of the net to highlight.\n- ``highlight_group`` group to add the highlighted net to, defaults to ``0``, valid groups are ``0 - 7``.\n\nTo highlight an instance:\n\n```\ngui::highlight_inst name\ngui::highlight_inst name highlight_group\n```\n\nOptions description:\n- ``name`` name of the instance to highlight.\n- ``highlight_group`` group to add the highlighted instance to, defaults to ``0``, valid groups are ``0 - 7``.\n\nTo clear the highlight groups:\n\n```\ngui::clear_highlights\ngui::clear_highlights highlight_group\n```\n\nOptions description:\n- ``highlight_group`` group to clear, defaults to ``0``, valid groups are ``-1 - 7``. Use ``-1`` to clear all groups.\n\n## Commands\n\n"], "answer": " First, you should start with the clock tree synthesis. You can use the following Tcl command as an example:\\n\\n```tcl\\nclock_tree_synthesis -buf_list {BUF1 BUF2} -clk_nets {clk1 clk2}\\n```\\n\\nThis example creates a clock tree using buffers `BUF1` and `BUF2`, and applies it to the clock nets `clk1` and `clk2`. Please replace the buffer names and clock net names with those appropriate for your design.\\n\\nAfter synthesizing the clock tree, you can use the following commands to highlight the clock nets on the OpenROAD GUI:\\n\\n```tcl\\ngui::highlight_net clk1\\ngui::highlight_net clk2\\n```\\n\\nThese commands highlight the `clk1` and `clk2` nets, respectively, allowing you to visually inspect the synthesized clock tree.\\n\\n\n"}
{"id": 26, "type": "functionality", "question": " Given a design using the `SKY130` node, suppose that in the course of viewing your completed RTL-GDS flow in the GUI, you decide to make further modifications to the design for optimization purposes. Say you want to select certain nets to route and extend the length of the pins. How can you achieve this using OpenROAD?\n", "ref_num": 3, "reference": ["global_routing_9", "pin_placement_5", "flow-scripts-tutorial_15"], "reference_content": ["id:global_routing_9\n### Set Specific Nets to Route\n\nThe `set_nets_to_route` command defines a list of nets to route. Only the nets\ndefined in this command are routed, leaving the remaining nets without any\nglobal route guides.\n\n```tcl\nset_nets_to_route \n    net_names \n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `net_names` | Tcl list of set of nets (e.g. `{net1, net2}`). |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:pin_placement_5\n### Set Pin Extension\n\nThe `set_pin_length_extension` command defines the an extension of the length\nof all vertical and horizontal pins. Note that this command may generate pins\npartially outside the die area.\n\n```tcl\nset_pin_length_extension \n    [-hor_extension h_extension]\n    [-ver_extension v_extension]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-hor_extension` | The length (in microns) for the horizontal pins. |\n| `-ver_extension` | The length (in microns) for the vertical pins. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:flow-scripts-tutorial_15\n\n## OpenROAD GUI\n\nThe GUI allows users to select, control, highlight and navigate the\ndesign hierarchy and design objects (nets, pins, instances, paths, etc.)\nthrough detailed visualization and customization options. Find details\non how to use the [GUI](https://openroad.readthedocs.io/en/latest/main/README.html#gui). All the windows\naside from the layout are docking windows that can be undocked.  Also it\ncan be closed and reopened from the Windows menu.\n\n\nNote:  When you are using remote access, you will need to include -Y (or -X) option in your command to\nenable X11 applications to function properly over the network. By using the command \"ssh -Y\" followed\nby the remote servers' address or hostname, you can establish a secure connection and activate X11 forwarding.\nThis feature enables you to run graphical programs on the remote server and have their windows display\non your local machines desktop environment.\n\n\nIn this section, learn how to:\n\n1. Visualize design hierarchy\n2. Load ODB files for floorplan and layout visualization\n3. Trace the synthesized clock tree to view hierarchy and buffers\n4. Use heat maps to view congestion and observe the effect of placement\n5. View and trace critical timing paths\n6. Set display control options\n7. Zoom to object from inspector\n\nIf you have completed the RTL-GDS flow, then proceed to view the final\nGDS file under results directory `./results/sky130hd/ibex/base/`\n\nFor the `ibex` design uncomment the `DESIGN_CONFIG`\nvariable in the `Makefile` available [here](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/Makefile).\n\n```\n# DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk\nDESIGN_CONFIG=./designs/sky130hd/ibex/config.mk\n# DESIGN_CONFIG=./designs/sky130hd/aes/config.mk\n```\n\n```shell\nmake gui_final\n```\n\n"], "answer": " Suppose we identified a list of specific nets to route, and we want to extend the length of certain pins, we can use OpenROAD's `set_nets_to_route` and `set_pin_length_extension` commands.\\n\\nFor routing specific nets (say `{netA, netB}`), we use:\\n\\n```tcl\\nset_nets_to_route {netA, netB}\\n```\\n\\nI also want to extend the length of certain pins. Assuming we want an extension of 5 microns for horizontal pins and 3 microns for vertical pins, we use:\\n\\n```tcl\\nset_pin_length_extension -hor_extension 5 -ver_extension 3\\n```\\n\\nRemember to re-run global routing after these steps to ensure the new changes are in effect. Finally, review `5_route_drc.rpt` to make sure there were no new DRC violations introduced:\\n\\n```shell\\nless ./reports/sky130hd/ibex/base/5_route_drc.rpt\\n```\\n\\nIn summary, using OpenROAD's set_nets_to_route and set_pin_length_extension commands, we were able to select specific nets to route and extend the lengths of certain pins.\\n\\n\n"}
{"id": 27, "type": "vlsi_flow", "question": " What steps should I follow to define interface cells, place wirebond pads, IO termianls to the instances and bondmaster to the IO instances using OpenROAD?\n", "ref_num": 3, "reference": ["read_UPF_utility_6", "chip-level_connections_12", "chip-level_connections_1"], "reference_content": ["id:read_UPF_utility_6\n### Set Interface cell\n\n```tcl \nuse_interface_cell\n    [-domain domain]\n    [-strategy strategy]\n    [-lib_cells lib_cells]\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-domain` | Power domain name. |\n| `-strategy` | Isolation strategy name. |\n| `-lib_cells` | List of lib cells that could be used. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:chip-level_connections_12\n### Placing Wirebond Pads\n\nTo place the wirebond pads over the IO cells.\n\n```tcl\nplace_bondpad \n    -bond master\n    [-offset {x y}]\n    [-rotation rotation]\n    io_instances\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-bond` | Name of the bondpad master. |\n| `-offset` | Offset to place the bondpad at with respect to the io instance. |\n| `-rotation` | Rotation of the bondpad. |\n| `io_instances` | Names of the instances to add bond pads to. |\n\nExample usage:\n\n```tcl\nplace_bondpad -bond PAD IO_*\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:chip-level_connections_1\n### Placing Terminals\n\nIn the case where the bond pads are integrated into the padcell, the IO terminals need to be placed.\nTo place a terminals on the padring\n\n```tcl\nplace_io_terminals\n    -allow_non_top_layer\n    inst_pins\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-allow_non_top_layer` | Allow the terminal to be placed below the top layer. |\n| `inst_pins` | Instance pins to place the terminals on. |\n\n#### Examples\n```\nplace_io_terminals u_*/PAD\nplace_io_terminals u_*/VDD\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Firstly, you will need to define the interface cell. This requires a domain name, a strategy and a list of lib cells that could be used. You can use the 'use_interface_cell' command with the necessary parameters, as shown below:\\n```\\nuse_interface_cell -domain domain -strategy strategy -lib_cells lib_cells\\n```\\n\\nNext, for placing wirebond pads, you will have to use the 'place_bondpad' command. You need to define the name of the bondpad master and the names of the instances to add the bond pads. Here's an example command:\\n```\\nplace_bondpad -bond PAD IO_*\\n```\\n\\nFinally, for placing the IO terminals on the pad ring, use the 'place_io_terminals' command and pass the instance pins to place the terminals on. Here's an example command:\\n```\\nplace_io_terminals u_*/PAD\\nplace_io_terminals u_*/VDD\\n```\\n\n"}
{"id": 28, "type": "gui&installation&test", "question": " How can a user create a unit test for a specific chip design's net connection using Python Unit Tests?\n", "ref_num": 2, "reference": ["unit_test_5", "unit_test_4"], "reference_content": ["id:unit_test_5\n# Python Unit Tests\n### TestNet.py:\n\nUnit test class for testing dbNet. It inherits from `odbUnitTest.TestCase` . it consists of\n\n* `setUp(self)` function to be called before each test case. Here, we create the database with the desired chip, block, masters, instances and nets.\n* `tearDown(self)` function to be called after each test case. Here, we destroy our db.\n* `test_*(self)` the test cases functions. Their names should start with `test` for the unittest suite to recognize.\n\n", "id:unit_test_4\n# Python Unit Tests\n### helper.py:\n\nA set of functions for creating simple db instances to be used for testing.  You can find the description of each function in the comments\n\n"], "answer": " To create a unit test for your specific chip design's net connection, please refer to the steps below:\\n\\n1. First, make sure to import the necessary Python libraries, including unittest and odbUnitTest, as well as the helper functions for db instances creation from the `helper.py` script. \\n\\n2. In the `setUp(self)` function, make sure to use the helper functions from `helper.py` to create the necessary objects, like database, chip, block, master, instances, and nets.\\n\\n3. Write your test case function `test_<yourfunction>(self)`. In this function, write the Python code to perform different operations on `dbNet` for the chip design's net you want to test. Make sure the function name starts with `test` for the unittest suite to recognize it.\\n\\n4. Eventually, in the `tearDown(self)` function, destroy the dbNet and other created objects.\\n\\n```python\\nimport unittest\\nimport odbUnitTest\\nfrom helper import *\\n\\nclass TestNet(odbUnitTest.TestCase):\\n    def setUp(self):\\n        ...\\n        # utilize helper.py functions to set up the objects like dbNet\\n        ...\\n\\n    def test_<yourfunction>(self):\\n        ...\\n        # write your test operations for dbNet here\\n        ...\\n\\n    def tearDown(self):\\n        ...\\n        # destroy your db here\\n        ...\\n```\\n\\n5. After you have written your unit test, you can execute your test via Python's unittest module.\\n\\n\n"}
{"id": 29, "type": "gui&installation&test", "question": " How to remove a bump instance during chip-level connections and how to showcase timing cone for a particular block pin in OpenROAD's GUI?\n", "ref_num": 2, "reference": ["chip-level_connections_4", "gui_6"], "reference_content": ["id:chip-level_connections_4\n### Removing a Single Bump Instance\n\nTo remove a single bump instance.\n\n```tcl\nremove_io_bump instance_name\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `instance_name` | Name of the bump. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gui_6\n### Displaying timing cones\n\n```\ndisplay_timing_cone pin\n                    [-fanin]\n                    [-fanout]\n                    [-off]\n```\n\nOptions description:\n- ``pin``: name of the instance or block pin.\n- ``fanin``: (optional) display the fanin timing cone.\n- ``fanout``: (optional) display the fanout timing cone.\n- ``off``: (optional) remove the timing cone.\n\n## Commands\n\n"], "answer": " To remove the specified bump instance and show the timing cone of a specific pin, you should proceed as follows:\\n\\n1. Invoke the `remove_io_bump` command with the bump instance's name that you would like to remove:\\n```tcl\\nremove_io_bump <instance_name>\\n```\\nReplace `<instance_name>` with the name of the bump instance you intend to remove.\\n\\n2. To display the timing cone, open the OpenROAD GUI. Run the following command:\\n```tcl\\ndisplay_timing_cone <pin> -fanin -fanout\\n```\\nReplace `<pin>` with the name of the instance or block pin that you are interested in displaying. The `-fanin` optional parameter will display the fanin timing cone and `-fanout` will display the fanout timing cone of that pin.\\n\\n\n"}
{"id": 30, "type": "functionality", "question": " An engineer needs to evaluate a hypergraph partition solution generated with OpenROAD and utilize the partition results for domain area placement. How can they proceed?\n", "ref_num": 2, "reference": ["partition_manager_6", "read_UPF_utility_7"], "reference_content": ["id:partition_manager_6\n### Evaluate Hypergraph Partition\n\n```tcl\nevaluate_hypergraph_solution\n  -num_parts num_parts\n  -balance_constraint balance_constraint\n  -hypergraph_file hypergraph_file\n  -solution_file solution_file\n  [-base_balance base_balance]\n  [-vertex_dimension vertex_dimension]\n  [-hyperedge_dimension hyperedge_dimension]\n  [-fixed_file fixed_file]\n  [-group_file group_file]\n  [-e_wt_factors e_wt_factors]\n  [-v_wt_factors v_wt_factors] \n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-num_parts` | Number of partitions. The default value is `2`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-balance_constraint` | Allowed imbalance between blocks. The default value is `1.0`, and the allowed values are floats. |\n| `-vertex_dimension` | Number of vertices in the hypergraph. The default value is `1`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-hyperedge_dimension` | Number of hyperedges in hypergraph. The default value is `1`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-hypergraph_file` | Path to hypergraph file. |\n| `-solution_file` | Path to solution file. |\n| `-base_balance` | Tcl list of baseline imbalance between partitions. The default value is `{1.0}`, and the allowed values are floats that sum up to `1.0`. |\n| `-fixed_file` | Path to fixed vertices constraint file. |\n| `-group_file` | Path to `stay together` attributes file. |\n| `-e_wt_factors` | Hyperedge weight factor. |\n| `-v_wt_factors` | Vertex weight factor. |\n\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:read_UPF_utility_7\n### Set Domain Area\n\n```tcl\nset_domain_area\n    domain_name\n    -area {llx lly urx ury}\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `domain_name` | Power domain name. |\n| `-area` | x-/y- coordinates in microns for the lower left and upper right corners of the power domain area. |\n\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " First, evaluate the hypergraph partition solution:\\n\\n```tcl\\nevaluate_hypergraph_solution\\n  -num_parts <num_parts>\\n  -balance_constraint <balance_constraint>\\n  -hypergraph_file <hypergraph_file>\\n  -solution_file <solution_file>\\n  [-base_balance <base_balance>]\\n  [-vertex_dimension <vertex_dimension>]\\n  [-hyperedge_dimension <hyperedge_dimension>]\\n  [-fixed_file <fixed_file>]\\n  [-group_file <group_file>]\\n  [-e_wt_factors <e_wt_factors>]\\n  [-v_wt_factors <v_wt_factors>]\\n```\\n\\nAfter evaluation, use the partition results to set domain areas. You can repeat this for all domains in the partition:\\n\\n```tcl\\nset_domain_area\\n  <domain_name>\\n  -area {<llx> <lly> <urx> <ury>}\\n```\\nWhere llx, lly, urx and ury are the lower left and upper right corners coordinates of the power domain area in microns, calculated from the partition solution.\\n\\n\n"}
{"id": 31, "type": "functionality", "question": " Suppose a user wants to perform IR drop analysis on an OpenROAD based design. What steps can be taken to perform IR drop analysis using OpenROAD utility?\n", "ref_num": 2, "reference": ["read_UPF_utility_0", "IR_Drop_analysis_2"], "reference_content": ["id:read_UPF_utility_0\n# Read UPF Utility\n\nThis module contains functionality to read, and modify information\nfrom Unified Power Format (UPF) files. \n\n", "id:IR_Drop_analysis_2\n### Check Power Grid\n\n```tcl\ncheck_power_grid -net net_name\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net` | Name of the net to analyze. Must be a power or ground net name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " 1. Read UPF files using OpenROAD UPF utility (ref: read_upf -file file)\\n    2. Run `check_power_grid -net net_name` to check the power grid. Replace net_name with the name of the net to analyze. (ref: IR_Drop_analysis_2)\\n\n"}
{"id": 32, "type": "functionality", "question": " During gate resizing, how can developers ensure that design constraints such as maximum utilization and maximum wire length are met?\n", "ref_num": 1, "reference": ["gate_resizing_14"], "reference_content": ["id:gate_resizing_14\n# Gate Resizer\n### Useful Developer Commands\n\nIf you are a developer, you might find these useful. More details can be found in the [source file](./src/Resizer.cc) or the [swig file](./src/Resizer.i).\n\n| Command Name | Description |\n| ----- | ----- |\n| `repair_setup_pin` | Repair setup pin violation. |\n| `check_parasitics` | Check if the `estimate_parasitics` command has been called. |\n| `parse_time_margin_arg` | Get the raw value for timing margin (e.g. `slack_margin`, `setup_margin`, `hold_margin`) |\n| `parse_percent_margin_arg` | Get the above margin in perentage format. |\n| `parse_margin_arg` | Same as `parse_percent_margin_arg`. |\n| `parse_max_util` | Check maximum utilization. |\n| `parse_max_wire_length` | Get maximum wirelength. |\n| `check_corner_wire_caps` | Check wire capacitance for corner. |\n| `check_max_wire_length` | Check if wirelength is allowed by rsz for minimum delay. |\n| `dblayer_wire_rc` | Get layer RC values. |\n| `set_dblayer_wire_rc` | Set layer RC values. |\n\n"], "answer": " 1. Use the `parse_max_util` command to check maximum utilization. \\n    2. Use the `parse_max_wire_length` command to get the maximum wirelength.\\n    3. Then, check if the wirelength fits into the allowable range by running the `check_max_wire_length` command. \\n\\n\n"}
{"id": 33, "type": "functionality", "question": " A user noticed that the tool is extracting parasitics incorrectly in one process corner. How should the user debug this issue?\n", "ref_num": 1, "reference": ["parasitics_extraction_1"], "reference_content": ["id:parasitics_extraction_1\n### Define Process Corner\n\n```tcl\ndefine_process_corner \n    [-ext_model_index index]\n    filename\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-ext_model_index` | Extraction model index. Expects 2 inputs (an index, and corner name). |\n| `filename` | Path to process corner file `rcx_patterns.rules`. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " For defining a process corner, the user can use the command :\\n\\n```tcl\\ndefine_process_corner \\n    [-ext_model_index index]\\n    filename\\n```\\nThey should check and ensure the filename (rcx_patterns.rules file) is correct and `ext_model_index` is set to the correct index if specified.\\n\\n\n"}
{"id": 34, "type": "functionality", "question": " After running detailed placement for my design, I would like to write the parasitics to a SPEF file. However, I only want to write the parasitic data of certain nets. How can I achieve this?\n", "ref_num": 1, "reference": ["parasitics_extraction_3"], "reference_content": ["id:parasitics_extraction_3\n### Write SPEF\n\nThe `write_spef` command writes the `.spef` output of the parasitics stored\nin the database.\n\n```tcl\nwrite_spef\n    [-net_id net_id]                \n    [-nets nets]\n    filename                     \n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net_id` | Output the parasitics info for specific net IDs. |\n| `-nets` | Net name. |\n| `filename` | Output filename. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": "  The 'write_spef' command is used to write the parasitics to a SPEF file. By using optional argument, '-nets', you can specify the particular nets you want to write the parasitics for.\\n\\n    The application script might look as follows:\\n\\n    ```tcl\\n    write_spef -nets {net_name1 net_name2} output_file_name.spef\\n    ```\\n\\n\n"}
{"id": 35, "type": "functionality", "question": " How can I place the IO pins on the top layer of the design? And what should I consider in the pin placements to avoid conflicts with previously defined pin placements or constraints?\n", "ref_num": 2, "reference": ["pin_placement_10", "pin_placement_3"], "reference_content": ["id:pin_placement_10\n# Pin Placer\n### Useful Developer Commands\n\nIf you are a developer, you might find these useful. More details can be found in the [source file](./src/IOPlacer.cpp) or the [swig file](./src/IOPlacer.i).\n\n| Command Name | Description |\n| ----- | ----- |\n| `parse_edge` | Parse edge (top/bottom/left/right). |\n| `parse_direction` | Parse direction. |\n| `parse_excludes_arg` | Parse excluded arguments. |\n| `parse_group_pins_arg` | Parse group pins arguments. | \n| `parse_layer_name` | Parse layer name. |\n| `parse_pin_names` | Parse pin names. |\n| `get_edge_extreme` | Get extremes of edge. |\n| `exclude_intervals` | Set exclude interval. |\n| `add_pins_to_constraint` | Add pins to constrained region. |\n| `add_pins_to_top_layer` | Add pins to top layer. | \n\n\n", "id:pin_placement_3\n### Clear IO Pin Constraints\n\nThe `clear_io_pin_constraints` command clears all the previously-defined\nconstraints and pin shape patterns created with `set_io_pin_constraint` or\n`define_pin_shape_pattern`.\n\n```tcl\nclear_io_pin_constraints\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Here is the step-by-step solution:\\n\\n 1. If you want to place the IO pins on the top layer, this can be achieved using the \\\"add_pins_to_top_layer\\\". 2. Before setting your new pin placement constraints, use the 'clear_io_pin_constraints' command to clear all the previous constraints:\\n  \\n    ```\\n    clear_io_pin_constraints\\n    ```\\n\\nThis forms a good base to avoid potential pin placement constraint conflicts.\\n\\n\n"}
{"id": 36, "type": "gui&installation&test", "question": " How can I implement timing driven placement with global routing debug mode while also creating a custom menu item in the GUI for easy future access?\n", "ref_num": 3, "reference": ["global_placement_1", "global_routing_15", "gui_2"], "reference_content": ["id:global_placement_1\n### Global Placement\n\nWhen using the `-timing_driven` flag, `gpl` does a virtual `repair_design` \nto find slacks and\nweight nets with low slack. It adjusts the worst slacks (modified with \n`-timing_driven_nets_percentage`) using a multiplier (modified with \n`-timing_driven_net_weight_max`). The multiplier\nis scaled from the full value for the worst slack, to 1.0 at the\n`timing_driven_nets_percentage` point. Use the `set_wire_rc` command to set\nresistance and capacitance of estimated wires used for timing.\n\n```\nglobal_placement\n    [-timing_driven]\n    [-routability_driven]\n    [-skip_initial_place]\n    [-incremental]\n    [-bin_grid_count grid_count]\n    [-density target_density]\n    [-init_density_penalty init_density_penalty]\n    [-init_wirelength_coef init_wirelength_coef]\n    [-min_phi_coef min_phi_conef]\n    [-max_phi_coef max_phi_coef]\n    [-overflow overflow]\n    [-initial_place_max_iter initial_place_max_iter]\n    [-initial_place_max_fanout initial_place_max_fanout]\n    [-pad_left pad_left]\n    [-pad_right pad_right]\n    [-verbose_level level]\n    [-force_cpu]\n    [-skip_io]\n    [-routability_check_overflow routability_check_overflow]\n    [-routability_max_density routability_max_density]\n    [-routability_max_bloat_iter routability_max_bloat_iter]\n    [-routability_max_inflation_iter routability_max_inflation_iter]\n    [-routability_target_rc_metric routability_target_rc_metric]\n    [-routability_inflation_ratio_coef routability_inflation_ratio_coef]\n    [-routability_pitch_scale routability_pitch_scale]\n    [-routability_max_inflation_ratio routability_max_inflation_ratio]\n    [-routability_rc_coefficients routability_rc_coefficients]\n    [-timing_driven_net_reweight_overflow]\n    [-timing_driven_net_weight_max]\n    [-timing_driven_nets_percentage]\n```\n\n#### General Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-timing_driven` | Enable timing-driven mode. See [link](#timing-driven-arguments) for timing-specific arguments. |\n| `-routability_driven` | Enable routability-driven mode. See [link](#routability-driven-arguments) for routability-specific arguments. |\n| `-skip_initial_place` | Skip the initial placement (Biconjugate gradient stabilized, or BiCGSTAB solving) before Nesterov placement. Initial placement improves HPWL by ~5% on large designs. Equivalent to `-initial_place_max_iter 0`. | \n| `-incremental` | Enable the incremental global placement. Users would need to tune other parameters (e.g., `init_density_penalty`) with pre-placed solutions. | \n| `-bin_grid_count` | Set bin grid's counts. The internal heuristic defines the default value. Allowed values are integers `[64,128,256,512,...]`. |\n| `-density` | Set target density. The default value is `0.7` (i.e., 70%). Allowed values are floats `[0, 1]`. |\n| `-init_density_penalty` | Set initial density penalty. The default value is `8e-5`. Allowed values are floats `[1e-6, 1e6]`. |\n| `-init_wirelength_coef` | Set initial wirelength coefficient. The default value is `0.25`. Allowed values are floats. |\n| `-min_phi_coef` | Set `pcof_min` ($\\mu_k$ Lower Bound). The default value is `0.95`. Allowed values are floats `[0.95, 1.05]`. |\n| `-max_phi_coef` | Set `pcof_max` ($\\mu_k$ Upper Bound). Default value is 1.05. Allowed values are `[1.00-1.20, float]`. |\n| `-overflow` | Set target overflow for termination condition. The default value is `0.1`. Allowed values are floats `[0, 1]`. |\n| `-initial_place_max_iter` | Set maximum iterations in the initial place. The default value is 20. Allowed values are integers `[0, MAX_INT]`. |\n| `-initial_place_max_fanout` | Set net escape condition in initial place when $fanout \\geq initial\\_place\\_max\\_fanout$. The default value is 200. Allowed values are integers `[1, MAX_INT]`. |\n| `-pad_left` | Set left padding in terms of number of sites. The default value is 0, and the allowed values are integers `[1, MAX_INT]` |\n| `-pad_right` | Set right padding in terms of number of sites. The default value is 0, and the allowed values are integers `[1, MAX_INT]` |\n| `-verbose_level` | Set verbose level for `gpl`. The default value is 1. Allowed values are integers `[0, 5]`. |\n| `-force_cpu` | Force to use the CPU solver even if the GPU is available. |\n| `-skip_io` | Flag to ignore the IO ports when computing wirelength during placement. The default value is False, allowed values are boolean. |\n\n#### Routability-Driven Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-routability_check_overflow` | Set overflow threshold for routability mode. The default value is `0.2`, and the allowed values are floats `[0, 1]`. |\n| `-routability_max_density` | Set density threshold for routability mode. The default value is `0.99`, and the allowed values are floats `[0, 1]`. |\n| `-routability_max_bloat_iter` | Set bloat iteration threshold for routability mode. The default value is `1`, and the allowed values are integers `[1, MAX_INT]`.|\n| `-routability_max_inflation_iter` | Set inflation iteration threshold for routability mode. The default value is `4`, and the allowed values are integers `[1, MAX_INT]`. |\n| `-routability_target_rc_metric` | Set target RC metric for routability mode. The default value is `1.25`, and the allowed values are floats. |\n| `-routability_inflation_ratio_coef` | Set inflation ratio coefficient for routability mode. The default value is `2.5`, and the allowed values are floats. |\n| `-routability_max_inflation_ratio` | Set inflation ratio threshold for routability mode. The default value is `2.5`, and the allowed values are floats. |\n| `-routability_rc_coefficients` | Set routability RC coefficients. It comes in the form of a Tcl List `{k1, k2, k3, k4}`. The default value for each coefficient is `{1.0, 1.0, 0.0, 0.0}` respectively, and the allowed values are floats. |\n\n#### Timing-Driven Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-timing_driven_net_reweight_overflow` | Set overflow threshold for timing-driven net reweighting. Allowed value is a Tcl list of integers where each number is `[0, 100]`. |\n| `-timing_driven_net_weight_max` | Set the multiplier for the most timing-critical nets. The default value is `1.9`, and the allowed values are floats. |\n| `-timing_driven_nets_percentage` | Set the reweighted percentage of nets in timing-driven mode. The default value is 10. Allowed values are floats `[0, 100]`. |\n\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:global_routing_15\n### Debug Mode\n\nThe `global_route_debug` command allows you to start a debug mode to view the status of the Steiner Trees.\nIt also allows you to dump the input positions for the Steiner tree creation of a net.\nThis must be used before calling the `global_route` command. \nSet the name of the net and the trees that you want to visualize.\n\n```tcl\nglobal_route_debug \n    [-st]\n    [-rst]\n    [-tree2D]\n    [-tree3D]\n    [-saveSttInput file_name]\n    [-net net_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-st` | Show the Steiner Tree generated by `stt`. |\n| `-rst` | Show the Rectilinear Steiner Tree generated by `grt`. |\n| `-tree2D` | Show the Rectilinear Steiner Tree generated by `grt` after the overflow iterations. |\n| `-tree3D` | Show the 3D Rectilinear Steiner Tree post-layer assignment. |\n| `-saveSttInput` | File name to save `stt` input of a net. |\n| `-net` | The name of the net name to be displayed. |\n\n## Example scripts\n\nExamples scripts demonstrating how to run FastRoute on a sample design of `gcd` as follows:\n\n```shell\n./test/gcd.tcl\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gui_2\n### Add items to the menubar\n\n```\ncreate_menu_item [-name name]\n                 [-path menu_path]\n                 -text item_text\n                 -script tcl_script\n                 [-shortcut key_shortcut] \n                 [-echo]\n```\n\nReturns: name of the new item, either ``name`` or ``actionX``.\n\nOptions description:\n- ``item_text``: The text to put on the item.\n- ``tcl_script``: The tcl script to evaluate when the button is pressed.\n- ``name``: (optional) name of the item, used when deleting the item.\n- ``menu_path``: (optional) Menu path to place the new item in (hierarchy is separated by /), defaults to \"Custom Scripts\", but this can also be \"Tools\" or \"New menu/New submenu\".\n- ``key_shortcut``: (optional) key shortcut to trigger this item.\n- ``echo``: (optional) indicate that the commands in the ``tcl_script`` should be echoed in the log.\n\nTo remove the item: \n\n```\ngui::remove_menu_item name\n```\n\n\n## Commands\n\n"], "answer": " To achieve the mentioned tasks, follow the following steps:\\n\\nFor the timing driven placement part, running the following command:\\n```tcl\\nglobal_placement -timing_driven -timing_driven_nets_percentage 70 -timing_driven_net_weight_max 1.6\\n```\\n\\nFor the global routing debug mode part, run the following command:\\n```tcl\\nglobal_route_debug -st -rst -tree2D -tree3D -net net1\\n```\\nYou could replace 'net1' with your actual net name.\\n\\nFor the custom menu item in the GUI, you could use the following command:\\n```tcl\\ncreate_menu_item -name TimingPlacementMenuItem -text \\\"Timing Driven Placement\\\" -script {\\n    global_placement -timing_driven -timing_driven_nets_percentage 70 -timing_driven_net_weight_max 1.6\\n    global_route_debug -st -rst -tree2D -tree3D -net net1\\n}\\n```\\nThis creates a new menu item named TimingPlacementMenuItem, with the text \\\"Timing Driven Placement\\\". When this menu item is clicked, it'll execute the script enclosed.\\n\\n\n"}
{"id": 37, "type": "gui&installation&test", "question": " After the whole RLT-to-GDSII flow, how to navigate to the specific region of the layout in the GUI to scrutinize it?\n", "ref_num": 1, "reference": ["gui_10"], "reference_content": ["id:gui_10\n### Layout navigation\n\nTo fit the whole layout in the window:\n\n```\ngui::fit\n```\n\nTo zoom in our out to a specific region:\n\n```\ngui::zoom_to x0 y0 x1 y1\n```\n\nOptions description:\n- ``x0, y0`` first corner of the layout area in microns.\n- ``x1, y1`` second corner of the layout area in microns.\n\nTo zoom in the layout:\n\n```\ngui::zoom_in\ngui::zoom_in x y\n```\n\nOptions description:\n- ``x, y`` new center of layout.\n\nTo zoom out the layout:\n\n```\ngui::zoom_out\ngui::zoom_out x y\n```\n\nOptions description:\n- ``x, y`` new center of layout.\n\nTo move the layout to new area:\n\n```\ngui::center_at x y\n```\n\nOptions description:\n- ``x, y`` new center of layout.\n\nTo change the resolution to a specific value:\n\n```\ngui::set_resolution resolution\n```\n\nOptions description:\n- ``resolution`` database units per pixel.\n\n## Commands\n\n"], "answer": " You can navigate the result in the layout with below script:\\n```tcl\\ngui::zoom_to x0 y0 x1 y1\\n```\\nYou can replace `x0 y0 x1 y1` with the coordinates of the region you want to inspect.\\n\\n\n"}
{"id": 38, "type": "functionality", "question": " How to extract parasitics of a design processed by OpenROAD flow?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_50"], "reference_content": ["id:flow-scripts-tutorial_50\n\n### Parasitics Extraction\n\nOpenRCX is a Parasitic Extraction (PEX, or RCX) tool that works on OpenDB design APIs.\nIt extracts routed designs based on the LEF/DEF layout model.\n\nOpenRCX stores resistance, coupling capacitance and ground (i.e., grounded) capacitance\non OpenDB objects with direct pointers to the associated wire and via db\nobjects. Optionally, OpenRCX can generate a `.spef` file.\n\nRefer to the built-in example [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/rcx/test/45_gcd.tcl).\n\nLaunch OpenROAD tool by running the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/rcx/test/\nopenroad\n```\n\n45_gcd:\n```shell\nsource helpers.tcl\n\nset test_nets \"\"\n\nread_lef Nangate45/Nangate45.lef\nread_liberty Nangate45/Nangate45_typ.lib\nread_def 45_gcd.def\n\n# Load via resistance info\nsource 45_via_resistance.tcl\n\ndefine_process_corner -ext_model_index 0 X\nextract_parasitics -ext_model_file 45_patterns.rules \\\n      -max_res 0 -coupling_threshold 0.1\n\nset spef_file [make_result_file 45_gcd.spef] \nwrite_spef $spef_file -nets $test_nets\n\ndiff_files 45_gcd.spefok $spef_file \"^\\\\*(DATE|VERSION)\"\n```\n\nTo run parasitics for gcd design:\n```tcl\nsource 45_gcd.tcl\n```\n\nThe log as follows:\n```\n[INFO ODB-0222] Reading LEF file: Nangate45/Nangate45.lef\n[INFO ODB-0223]     Created 22 technology layers\n[INFO ODB-0224]     Created 27 technology vias\n[INFO ODB-0225]     Created 135 library cells\n[INFO ODB-0226] Finished LEF file:  Nangate45/Nangate45.lef\n[INFO ODB-0127] Reading DEF file: 45_gcd.def\n[INFO ODB-0128] Design: gcd\n[INFO ODB-0130]     Created 54 pins.\n[INFO ODB-0131]     Created 1820 components and 4618 component-terminals.\n[INFO ODB-0132]     Created 2 special nets and 3640 connections.\n[INFO ODB-0133]     Created 350 nets and 978 connections.\n[INFO ODB-0134] Finished DEF file: 45_gcd.def\n[INFO RCX-0431] Defined process_corner X with ext_model_index 0\n[INFO RCX-0029] Defined extraction corner X\n[INFO RCX-0008] extracting parasitics of gcd ...\n[INFO RCX-0435] Reading extraction model file 45_patterns.rules ...\n[INFO RCX-0436] RC segment generation gcd (max_merge_res 0.0) ...\n[INFO RCX-0040] Final 2656 rc segments\n[INFO RCX-0439] Coupling Cap extraction gcd ...\n[INFO RCX-0440] Coupling threshhold is 0.1000 fF, coupling capacitance less than 0.1000 fF will be grounded.\n[INFO RCX-0043] 1954 wires to be extracted\n[INFO RCX-0442] 48% completion -- 954 wires have been extracted\n[INFO RCX-0442] 100% completion -- 1954 wires have been extracted\n[INFO RCX-0045] Extract 350 nets, 2972 rsegs, 2972 caps, 2876 ccs\n[INFO RCX-0015] Finished extracting gcd.\n[INFO RCX-0016] Writing SPEF ...\n[INFO RCX-0443] 350 nets finished\n[INFO RCX-0017] Finished writing SPEF ...\n```\n\n`45_gcd.spef` viewed in `results` directory.\n\n"], "answer": " You can extract the parasitics using the OpenRCX tool by following the below script:\\n```tcl\\nsource helpers.tcl\\n\\nset test_nets \\\"\\\"\\n\\nread_lef Nangate45/Nangate45.lef\\nread_liberty Nangate45/Nangate45_typ.lib\\nread_def 45_gcd.def\\n\\n# Load via resistance info\\nsource 45_via_resistance.tcl\\n\\ndefine_process_corner -ext_model_index 0 X\\nextract_parasitics -ext_model_file 45_patterns.rules -max_res 0 -coupling_threshold 0.1\\n\\nset spef_file [make_result_file 45_gcd.spef] \\nwrite_spef $spef_file -nets $test_nets\\n```\\nYou will need to replace the placeholders with the specifics of your design such as the LEF, LIB and DEF files along with any via resistance info you may have.\n"}
{"id": 39, "type": "functionality", "question": " How to create logic ports?\n", "ref_num": 1, "reference": ["read_UPF_utility_3"], "reference_content": ["id:read_UPF_utility_3\n### Create Logic Port\n\n```tcl\ncreate_logic_port\n    [-direction direction]\n    port_name\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-direction` | Direction of the port (`in`, `out`, `inout`). |\n| `port_name` | Port name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " You can create a logic port using the `create_logic_port [-direction direction] port_name` command where the direction is the direction of your port (either `in`,`out`, or `inout`). 'port_name' parameter is the name of your port.\\n   ```tcl\\n   create_logic_port -direction your_port_direction your_port_name\\n   ```\\n\n"}
{"id": 40, "type": "gui&installation&test", "question": " The user needs to perform a robust timing analysis post placement, before proceeding to the next stage of the RTL-GDSII flow. How does the user use the OpenROAD tool to obtain a detailed timing report, including the slack for each individual timing path?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_20"], "reference_content": ["id:flow-scripts-tutorial_20\n## OpenROAD GUI\n### Viewing Timing Report\n\nClick `Timing` -> `Options` to view and traverse specific timing paths.\nFrom Toolbar, click on the `Timing` icon, View `Timing Report` window added\nat the right side (RHS) of GUI as shown below.\n\n\nIn `Timing Report` Select `Paths` -> `Update`, `Paths` should be integer\nnumbers. The number of timing paths should be displayed in the current\nwindow as follows:\n\n\nSelect `Setup` or `Hold` tabs and view required arrival times and\nslack for each timing path segment.\n\nFor each `Setup` or `Hold` path group, path details have a specific `pin\nname, Time, Delay, Slew and Load` value with the clock to register, register\nto register and register to output data path.\n\n"], "answer": " In the OpenROAD GUI, navigate to the `Timing` menu and select `Options`. This will bring up the box for specifying which timing paths you want to analyze.\\n\\nNext, go to the `Paths` section and press `Update`. In this section, the `Paths` should be integer numbers representing how many timing paths you want to analyze.\\n\\nNow, under the `Setup` and `Hold` tabs, you can view the required arrival times and slack for each timing path segment. For each `Setup` or `Hold` path group, path details have a specific `pin name, Time, Delay, Slew and Load` value with the clock to register, register to register and register to the output data path. This will provide you with a detailed timing report for further analysis and optimization.\\n\\n\n"}
{"id": 41, "type": "functionality", "question": " In a use-case scenario where a design engineer finds the use of a specific IO bump not necessary for the circuit implementation, how can the engineer remove it from the database using OpenROAD?\n", "ref_num": 1, "reference": ["chip-level_connections_4"], "reference_content": ["id:chip-level_connections_4\n### Removing a Single Bump Instance\n\nTo remove a single bump instance.\n\n```tcl\nremove_io_bump instance_name\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `instance_name` | Name of the bump. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Step 1: Identify the bump instance that needs to be removed.\\n\\nStep 2: Once the instance name of the bump is determined, utilize the OpenROAD `remove_io_bump` command to remove the IO bump. The command syntax is as shown below:\\n\\n```tcl\\nremove_io_bump instance_name\\n```\\n\\nAfterwards, re-run the script. After the execution, the specified IO bump will be removed from the database.\\n\\n\n"}
{"id": 42, "type": "gui&installation&test", "question": " While working with Power Distribution Network Generator in OpenROAD application, an engineer is trying to explore and debug the available power density maps. However, the engineer is struggling with the exploration due to overlapping outputs. How can the engineer isolate and view certain instances or power domains without letting others overlays?\n", "ref_num": 4, "reference": ["gui_9", "flow-scripts-tutorial_15", "power_distribution_network_generator_10", "flow-scripts-tutorial_18"], "reference_content": ["id:gui_9\n### Opening and closing\n\nTo open the GUI from the command-line (this command does not return until the GUI is closed):\n\n```\ngui::show\ngui::show script\ngui::show script interactive\n```\n\nOptions description:\n- ``script`` TCL script to evaluate in the GUI.\n- ``interactive`` indicates if true the GUI should open in an interactive session (default), or if false that the GUI would execute the script and return to the terminal.\n\nTo close the GUI and return to the command-line:\n\n```\ngui::hide\n```\n\n## Commands\n\n", "id:flow-scripts-tutorial_15\n\n## OpenROAD GUI\n\nThe GUI allows users to select, control, highlight and navigate the\ndesign hierarchy and design objects (nets, pins, instances, paths, etc.)\nthrough detailed visualization and customization options. Find details\non how to use the [GUI](https://openroad.readthedocs.io/en/latest/main/README.html#gui). All the windows\naside from the layout are docking windows that can be undocked.  Also it\ncan be closed and reopened from the Windows menu.\n\n\nNote:  When you are using remote access, you will need to include -Y (or -X) option in your command to\nenable X11 applications to function properly over the network. By using the command \"ssh -Y\" followed\nby the remote servers' address or hostname, you can establish a secure connection and activate X11 forwarding.\nThis feature enables you to run graphical programs on the remote server and have their windows display\non your local machines desktop environment.\n\n\nIn this section, learn how to:\n\n1. Visualize design hierarchy\n2. Load ODB files for floorplan and layout visualization\n3. Trace the synthesized clock tree to view hierarchy and buffers\n4. Use heat maps to view congestion and observe the effect of placement\n5. View and trace critical timing paths\n6. Set display control options\n7. Zoom to object from inspector\n\nIf you have completed the RTL-GDS flow, then proceed to view the final\nGDS file under results directory `./results/sky130hd/ibex/base/`\n\nFor the `ibex` design uncomment the `DESIGN_CONFIG`\nvariable in the `Makefile` available [here](https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/Makefile).\n\n```\n# DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk\nDESIGN_CONFIG=./designs/sky130hd/ibex/config.mk\n# DESIGN_CONFIG=./designs/sky130hd/aes/config.mk\n```\n\n```shell\nmake gui_final\n```\n\n", "id:power_distribution_network_generator_10\n# Power Distribution Network Generator\n### Useful Developer Commands\n\nIf you are a developer, you might find these useful. More details can be found in the [source file](../src/PdnGen.cc) or the [swig file](PdnGen.i).\n\n| Command Name | Description |\n| ----- | ----- |\n| `name_cmp` | Compare 2 input strings `obj1` and `obj2` if they are equal. |\n| `check_design_state` | Check if the design is loaded. |\n| `get_layer` | Get the layer reference of the layer name. |\n| `get_voltage_domains` | Gets a Tcl list of power domains in design. |\n| `match_orientation` | Checks if a given orientation `orient` is within a list of orientations `orients`. |\n| `get_insts` | Get the Tcl list of instances. |\n| `get_masters` | Get the Tcl list of masters. |\n| `get_one_to_two` | If a Tcl list has one element `{x}`, Tcl list `{x x}` is returned. If a Tcl list of two elements `{y y}`, list as is returned. Otherwise, for any other list lengths, an error is triggered. |\n| `get_one_to_four` | Similar logic for the above function, except the logic only works for lists of length one, two, and four, respectively. All other list lengths trigger errors. |\n| `get_obstructions` | Get the Tcl list of layers. |\n| `get_starts_with` | If value starts with `POWER`, return 1; else if value starts with `GROUND` return 0; else return error. |\n| `get_mterm` | Find master terminal. |\n| `get_orientations` | Get the list of valid orientations. | \n\n", "id:flow-scripts-tutorial_18\n## OpenROAD GUI\n### Tracing The Clock Tree\n\nView the synthesized clock tree for `ibex` design:\n-   From the top Toolbar Click `Windows` -> `Clock Tree Viewer`\n\n\nOn RHS, click `Clock Tree Viewer` and top right corner, click\n`Update` to view the synthesized clock tree of your design.\n\nView clock tree structure below, the user needs to disable the metal\n`Layers` section on LHS as shown below.\n\n\nFrom the top Toolbar, click on the `Windows` menu to select/hide different\nview options of Scripting, Display control, etc.\n\n"], "answer": " To tackle this problem, follow the steps listed below:\\n\\nStep 1: Open the GUI from the OpenROAD shell using `gui::show`.\\n\\nStep 2: Load the design hierarchy in the GUI environment. You can use the method described in document `flow-scripts-tutorial_15` to load ODB files for visualization.\\n\\nStep 3: Use the developer's commands provided in the document `power_distribution_network_generator_10` to target specific instances or power domains. You can get a specific instance using command `get_insts` and also you can get a list of power domains using `get_voltage_domains`.\\n\\nStep 4: Now, in the GUI under `Windows` -> `Display Control`, hide or uncheck the instances or power domains that you do not want to visualize. This will ensure only your target instance or power domain is visualized, hence avoiding any overlaps or clutter.\\n\\nStep 5: You can close the GUI or stop the session once your debugging or analysis task is over. You can do this by using command `gui::hide`.\\n\\nRemember, this approach gives you the ability to analyze and debug specific parts of your design without distraction.\\n\\n\n"}
{"id": 43, "type": "vlsi_flow", "question": " Suppose as an experienced engineer, you are dealing with a digital design which has encountered a few issues during OpenROAD flow. The first issue is hold timing violations  after clock tree synthesis. Subsequently, during the Place and Route phase, the design encounters a significant number of antenna rule violations. How can these issues be resolved making use of `repair_timing` and `repair_design` commands accordingly?\n", "ref_num": 2, "reference": ["flow-scripts-tutorial_38", "antenna_rule_checker_0"], "reference_content": ["id:flow-scripts-tutorial_38\n\n### Timing Optimizations\n\n#### Timing Optimization Using repair_timing\n\nThe `repair_timing` command repairs setup and hold violations. It was\nrun after clock tree synthesis with propagated clocks.\n\nWhile repairing hold violations, buffers are not inserted since that may\ncause setup violations unless '-allow_setup_violations' is specified.\nUse `-slack_margin` to add additional slack margin.\n\n", "id:antenna_rule_checker_0\n# Antenna Rule Checker\n\nThis tool checks antenna violations and generates a report to indicate\nviolated nets. See LEF/DEF 5.8 Language Reference, Appendix C,\n\"Calculating and Fixing Process Antenna Violations\" (p.389) \nfor a [description](https://coriolis.lip6.fr/doc/lefdef/lefdefref/lefdefref.pdf) of antenna violations.\n\n\nAbbreviations Index:\n\n-   `PAR`: Partial Area Ratio\n-   `CAR`: Cumulative Area Ratio\n-   `Area`: Gate Area\n-   `S. Area`: Side Diffusion Area\n-   `C. Area`: Cumulative Gate Area\n-   `C. S. Area`: Cumulative Side (Diffusion) Area\n\nAntenna violations can be repaired after global routing with the `repair_design` command.\n\n"], "answer": " To address the timing violation, you will require executing the command `repair_timing` after clock tree synthesis. While repairing hold violations, buffers should not be inserted as they may cause setup violations unless `-allow_setup_violations` is specified. Also, the command can take an optional `-slack_margin` parameter to add additional slack margin. The command looks as follows:\\n\\n```tcl\\nrepair_timing -allow_setup_violations -slack_margin <margin_value>\\n```\\n\\nFor antenna rule violations that occur during detailed routing, the `repair_design` command is required. This command fixes these violations. \\n\\n\n"}
{"id": 44, "type": "functionality", "question": " During the chip designing process, suppose that detailed routing is causing issues, and the debug information from `drt` is difficult to decipher. How can you enable more specific debugging to help isolate the issue, particularly for a particular pin or for details of track assignment?\n", "ref_num": 1, "reference": ["detailed_routing_2"], "reference_content": ["id:detailed_routing_2\n### Detailed Route Debugging\n\nThe following command and arguments are useful when debugging error\nmessages from `drt` and to understand its behavior.\n\n```tcl\ndetailed_route_debug \n    [-pa]\n    [-ta]\n    [-dr]\n    [-maze]\n    [-net name]\n    [-pin name]\n    [-worker x y]\n    [-iter iter]\n    [-pa_markers]\n    [-dump_dr]\n    [-dump_dir dir]\n    [-pa_edge]\n    [-pa_commit]\n    [-write_net_tracks]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-pa` | Enable debug for pin access. |\n| `-ta` | Enable debug for track assignment. |\n| `-dr` | Enable debug for detailed routing. |\n| `-maze` | Enable debug for maze routing. | \n| `-net` | Enable debug for net name. |\n| `-pin` | Enable debug for pin name. |\n| `-worker` | Debugs routes that pass through the point `{x, y}`. |\n| `-iter` | Specifies the number of debug iterations. The default value is `0`, and the accepted values are integers `[0, MAX_INT`. |\n| `-pa_markers` | Enable pin access markers. |\n| `-dump_dr` | Filename for detailed routing dump. |\n| `-dump_dir` | Directory for detailed routing dump. |\n| `-pa_edge` | Enable visibility of pin access edges. |\n| `-pa_commit` | Enable visibility of pin access commits. |\n| `-write_net_tracks` | Enable writing of net track assigments. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " If detailed routing is causing issues, you can enable the debugging of a particular pin or track assignment using the `detailed_route_debug` command like this:\\n\\n```tcl\\ndetailed_route_debug -pin pin_name -ta\\n```\\n\\nHere, `pin_name` should be replaced with the name of the pin you want to enable debugging for, and the `-ta` flag enables the debugging of track assignment.\\n\\n\n"}
{"id": 45, "type": "functionality", "question": " After performing RTL to GDSII flow of the OpenROAD design, the engineer needs to connect the ring signals. However, they are also interested in checking a few specific nets and instances while they are performing these operations for debugging and verification. How can this be done using OpenROAD commands?\n", "ref_num": 2, "reference": ["chip-level_connections_11", "chip-level_connections_14"], "reference_content": ["id:chip-level_connections_11\n### Connecting Ring Signals\n\nOnce the ring is complete, use the following command to connect the ring signals.\n\n```tcl\nconnect_by_abutment\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:chip-level_connections_14\n# Chip-level Connections\n### Useful Developer Commands\n\nIf you are a developer, you might find these useful. More details can be found in the [source file](./src/ICeWall.cpp) or the [swig file](./src/pad.i).\n\n| Command Name | Description |\n| ----- | ----- |\n| `find_site` | Find site given site name. |\n| `find_master` | Find master given master name. |\n| `find_instance` | Find instance given instance name. |\n| `find_net` | Find net given net name. |\n| `assert_required` | Assert argument that is required for `cmd` |\n| `connect_iterm` | Connect instance terminals. Required inputs are: `inst_name`, `iterm_name`, `net_name`. |\n| `convert_tcl` | These functions read from $ICeWall::library parameters to generate a standalone Tcl script. |\n\n"], "answer": " 1. The user can connect the ring signals using the 'connect_by_abutment' command like this:\\n```tcl\\nconnect_by_abutment\\n```\\n\\n2. Similarly, a net or instance can be found using the 'find_net' or 'find_instance' commands as shown below:\\n```tcl\\nfind_net GIVEN_NET_NAME\\nfind_instance GIVEN_INSTANCE_NAME\\n```\\n\\n\n"}
{"id": 46, "type": "functionality", "question": " While synthesizing a clock tree, the engineer also needs to optimize the design by not allowing the inverter in the clock tree with multiple fanouts, to split up. So, how can this optimization be done?\n", "ref_num": 1, "reference": ["gate_resizing_12"], "reference_content": ["id:gate_resizing_12\n### Repair Clock Inverters\n\nThe repair_clock_inverters command replaces an inverter in the clock\ntree with multiple fanouts with one inverter per fanout.  This\nprevents the inverter from splitting up the clock tree seen by CTS.\nIt should be run before clock_tree_synthesis.\n\n```tcl\nrepair_clock_inverters\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The user needs to execute the 'repair_clock_inverters' command before performing a clock tree synthesis to achieve this:\\n```tcl\\nrepair_clock_inverters\\n```\\n\\n\n"}
{"id": 47, "type": "functionality", "question": " How would a user working on an ibex design set a power domain and define a power grid connectivity strategy for a specific set of layers in OpenROAD?\n", "ref_num": 2, "reference": ["read_UPF_utility_5", "power_distribution_network_generator_9"], "reference_content": ["id:read_UPF_utility_5\n### Create or Update Isolation Strategy\n\n```tcl \nset_isolation\n    [-domain domain]\n    [-applies_to applies_to]\n    [-clamp_value clamp_value]\n    [-isolation_signal isolation_signal]\n    [-isolation_sense isolation_sense]\n    [-location location]\n    [-update]\n    name\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-domain` | Power domain |\n| `-applies_to` | Restricts the strategy to apply one of these (`inputs`, `outputs`, `both`). |\n| `-clamp_value` | Value the isolation can drive (`0`, `1`). |\n| `-isolation_signal` | The control signal for this strategy. |\n| `-isolation_sense` | The active level of isolation control signal. |\n| `-location` | Domain in which isolation cells are placed (`parent`, `self`, `fanout`). |\n| `-update` | Only available if using existing strategy, will error if the strategy doesn't exist. |\n| `name` | Isolation strategy name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:power_distribution_network_generator_9\n### Add Connections\n\nThe `add_pdn_connect` command is used to define which layers in the power grid are to be connected together. During power grid generation, vias will be added for overlapping power nets and overlapping ground nets. The use of fixed vias from the technology file can be specified or else via stacks will be constructed using VIARULEs. If VIARULEs are not available in the technology, then fixed vias must be used.\n\n```tcl\nadd_pdn_connect \n    -layers list_of_two_layers\n    [-grid grid_name]\n    [-cut_pitch pitch_value]\n    [-fixed_vias list_of_fixed_vias]\n    [-dont_use_vias list_of_vias]\n    [-max_rows rows]\n    [-max_columns columns]\n    [-ongrid ongrid_layers]\n    [-split_cuts split_cuts_mapping]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-layers` | Layers to be connected where there are overlapping power or overlapping ground nets. |\n| `-grid` | Specifies the name of the grid definition to which this connection will be added (Default: Last grid created by `define_pdn_grid`). |\n| `-cut_pitch` | When the two layers are parallel, e.g., overlapping stdcell rails, specify the distance between via cuts. |\n| `-fixed_vias` | List of fixed vias to be used to form the via stack. |\n| `-dont_use_vias` | List or pattern of vias to not use to form the via stack. |\n| `-max_rows` | Maximum number of rows when adding arrays of vias. |\n| `-max_columns` | Maximum number of columns when adding arrays of vias. |\n| `-ongrid` | List of intermediate layers in a via stack to snap onto a routing grid. |\n| `-split_cuts` | Specifies layers to use split cuts on with an associated pitch, for example `{metal3 0.380 metal5 0.500}`. |\n\nExample usage:\n\n```tcl\nadd_pdn_connect -grid main_grid -layers {metal1 metal2} -cut_pitch 0.16\nadd_pdn_connect -grid main_grid -layers {metal2 metal4}\nadd_pdn_connect -grid main_grid -layers {metal4 metal7}\n\nadd_pdn_connect -grid ram -layers {metal4 metal5}\nadd_pdn_connect -grid ram -layers {metal5 metal6}\nadd_pdn_connect -grid ram -layers {metal6 metal7}\n\nadd_pdn_connect -grid rotated_rams -layers {metal4 metal6}\nadd_pdn_connect -grid rotated_rams -layers {metal6 metal7}\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " First, you will set a power domain named 'power_domain1'. To create a power domain, use the following code:\\n\\n```tcl\\nset_isolation power_domain1 -domain power_domain1\\n```\\n\\nThis command creates a power domain named 'power_domain1'. All of the following power distribution network strategies will be applied to this domain.\\n\\nNext, define power grid connectivity for a specific set of layers. Suppose you want to connect layers metal1 and metal2. Use the `add_pdn_connect` command as follows:\\n\\n```tcl\\nadd_pdn_connect -layers {metal1 metal2}\\n```\\n\\nThis command creates a connection in the power grid between the overlapping power or ground nets in the metal1 and metal2 layers.\\n\\n\n"}
{"id": 48, "type": "functionality", "question": " During the course of using OpenROAD for my design flow, I noticed a few high fanout nets connected to tie cells after completing my global_route process. This could potentially lead to timing and congestion problems. How can I correct this scenario?\n", "ref_num": 1, "reference": ["gate_resizing_9"], "reference_content": ["id:gate_resizing_9\n### Repair Tie Fanout\n\nThe `repair_tie_fanout` command connects each tie high/low load to a copy\nof the tie high/low cell.\n\n```tcl\nrepair_tie_fanout \n    [-separation dist]\n    [-verbose]\n    lib_port\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-separation` | Tie high/low insts are separated from the load by this value (Liberty units, usually microns). |\n| `-verbose` | Enable verbose logging of repair progress. |\n| `lib_port` | Tie high/low port, which can be a library/cell/port name or object returned by `get_lib_pins`. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To repair these fanout nets connected to tie cells, you just need the correct command `repair_tie_fanout` in complying with the specifications of your aim:\\n\\n```tcl\\nrepair_tie_fanout -separation 2 -verbose lib_port\\n```\\nBe aware that the values of \\\"separation\\\" and \\\"lib_port\\\" need to be replaced by actual values specific to your design. This command will connect each tie high/low load to a copy of the tie high/low cell, with the load separated by the specified distance in Liberty units.\\n\\n\n"}
{"id": 49, "type": "functionality", "question": " How to generate a congestion report?\n", "ref_num": 1, "reference": ["global_routing_1"], "reference_content": ["id:global_routing_1\n### Global Route\n\n```tcl\nglobal_route \n    [-guide_file out_file]\n    [-congestion_iterations iterations]\n    [-congestion_report_file file_name]\n    [-congestion_report_iter_step steps]\n    [-grid_origin {x y}]\n    [-critical_nets_percentage percent]\n    [-allow_congestion]\n    [-verbose]\n    [-start_incremental]\n    [-end_incremental]\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-guide_file` | Set the output guides file name (e.g., `route.guide`). |\n| `-congestion_iterations` | Set the number of iterations made to remove the overflow of the routing. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-congestion_report_file` | Set the file name to save the congestion report. The file generated can be read by the DRC viewer in the GUI (e.g., `report_file.rpt`). |\n| `-congestion_report_iter_step` | Set the number of iterations to report. The default value is `0`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-grid_origin` | Set the (x, y) origin of the routing grid in DBU. For example, `-grid_origin {1 1}` corresponds to the die (0, 0) + 1 DBU in each x--, y- direction. |\n| `-critical_nets_percentage` | Set the percentage of nets with the worst slack value that are considered timing critical, having preference over other nets during congestion iterations (e.g. `-critical_nets_percentage 30`). The default value is `0`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-allow_congestion` | Allow global routing results to be generated with remaining congestion. The default is false. |\n| `-verbose` | This flag enables the full reporting of the global routing. |\n| `-start_incremental` | This flag initializes the GRT listener to get the net modified. The default is false. |\n| `-end_incremental` | This flag run incremental GRT with the nets modified. The default is false. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The user can generate a congestion report by invoking the global_route command with the '-congestion_report_file' switch, specifying the filename they want to use for the output congestion report. Here is the syntax:\\n\\n```tcl\\nglobal_route -congestion_report_file congest.rpt\\n```\\n\\n\n"}
{"id": 50, "type": "gui&installation&test", "question": " Suppose a user needs to buffer input ports in their OpenROAD design but wants to limit the utilization threshold to avoid overloading hardware resources. Meanwhile, the user also wants to analyze timing data in the GUI post-buffering. How does the user go about this process?\n", "ref_num": 2, "reference": ["gate_resizing_6", "flow-scripts-tutorial_20"], "reference_content": ["id:gate_resizing_6\n### Buffer Ports\n\nThe `buffer_ports -inputs` command adds a buffer between the input and its\nloads.  The `buffer_ports -outputs` adds a buffer between the port driver\nand the output port. Inserting buffers on input and output ports makes\nthe block input capacitances and output drives independent of the block\ninternals.\n\n```tcl\nbuffer_ports \n    [-inputs] \n    [-outputs] \n    [-max_utilization util]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-inputs`, `-outputs` | Insert a buffer between the input and load, output and load respectively. The default behavior is `-inputs` and `-outputs` set if neither is specified. |\n| `-max_utilization` | Defines the percentage of core area used. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:flow-scripts-tutorial_20\n## OpenROAD GUI\n### Viewing Timing Report\n\nClick `Timing` -> `Options` to view and traverse specific timing paths.\nFrom Toolbar, click on the `Timing` icon, View `Timing Report` window added\nat the right side (RHS) of GUI as shown below.\n\n\nIn `Timing Report` Select `Paths` -> `Update`, `Paths` should be integer\nnumbers. The number of timing paths should be displayed in the current\nwindow as follows:\n\n\nSelect `Setup` or `Hold` tabs and view required arrival times and\nslack for each timing path segment.\n\nFor each `Setup` or `Hold` path group, path details have a specific `pin\nname, Time, Delay, Slew and Load` value with the clock to register, register\nto register and register to output data path.\n\n"], "answer": " The user can go through the following steps:\\n\\n1. Buffer the input ports while setting a maximum utilization. This is done with the `buffer_ports` command from the `gate_resizing_6` document, as follows:\\n```tcl\\nbuffer_ports -inputs -max_utilization util\\n```\\nIn the above, `util` is the maximum utilization threshold set by the user.\\n\\n2. Next, to analyze timing data in the GUI post-buffering, follow guidelines from the `flow-scripts-tutorial_20` document. First, start the OpenROAD GUI, then click on the `Timing Report` button on the toolbar. After loading the timing data, simply select Paths -> Update to view and traverse specific timing paths. You can get details like `pin name, Time, Delay, Slew and Load` value for each timing path.\\n\\n\n"}
{"id": 51, "type": "vlsi_flow", "question": " How to apply global utilization and max wire length constraints during the design repair and set a global routing region adjustment?\n", "ref_num": 2, "reference": ["gate_resizing_8", "global_routing_7"], "reference_content": ["id:gate_resizing_8\n### Repair Design\n\nThe `repair_design` command inserts buffers on nets to repair max slew, max\ncapacitance and max fanout violations, and on long wires to reduce RC delay in\nthe wire. It also resizes gates to normalize slews.  Use `estimate_parasitics\n-placement` before `repair_design` to estimate parasitics considered\nduring repair. Placement-based parasitics cannot accurately predict\nrouted parasitics, so a margin can be used to \"over-repair\" the design\nto compensate. \n\n```tcl\nrepair_design \n    [-max_wire_length max_length]\n    [-slew_margin slew_margin]\n    [-cap_margin cap_margin]\n    [-max_utilization util]\n    [-verbose]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-max_wire_length` | Maximum length of wires (in microns), defaults to a value that minimizes the wire delay for the wire RC values specified by `set_wire_rc`. |\n| `-slew_margin` | Add a slew margin. The default value is `0`, the allowed values are integers `[0, 100]`. |\n| `-cap_margin` | Add a capactitance margin. The default value is `0`, the allowed values are integers `[0, 100]`. |\n| `-max_utilization` | Defines the percentage of core area used. |\n| `-verbose` | Enable verbose logging on progress of the repair. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:global_routing_7\n### Set Global Routing Region Adjustment\n\n```tcl\nset_global_routing_region_adjustment\n    {lower_left_x lower_left_y upper_right_x upper_right_y}\n    -layer layer \n    -adjustment adjustment\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `lower_left_x`, `lower_left_y`, `upper_right_x` , `upper_right_y` | Bounding box to consider. |\n| `-layer` | Integer for the layer number (e.g. for M1 you would use 1). |\n| `-adjustment` | Float indicating the percentage reduction of each edge in the specified layer. |\n\nExample: `set_global_routing_region_adjustment {1.5 2 20 30.5} -layer Metal4 -adjustment 0.7`\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " 1. In order to repair design with the customization of utilization and wire length constraints, invoke repair_design command as follows:\\n```tcl\\nrepair_design -max_utilization 60 -max_wire_length 10\\n```\\nThis command sets the maximum utilization to 60% and the maximum wire length to 10 microns while repairing the design.\\n\\n2. Then, if you decide to adjust the global routing region, you can use set_global_routing_region_adjustment:\\n```tcl\\nset_global_routing_region_adjustment {1.5 2 20 30.5} -layer Metal4 -adjustment 0.7\\n```\\nThis will lead to a reduction of 0.7 on each edge of routing resources in Metal4 layer within the specified bounding box.\\n\\n\n"}
{"id": 52, "type": "gui&installation&test", "question": " How can we build OpenROAD with a custom installation path and then interact with OpenRoad and OpenDB via Python?\n", "ref_num": 2, "reference": ["install_3", "database_4"], "reference_content": ["id:install_3\n# Installing OpenROAD\n### Build using support script\n\n``` shell\n./etc/Build.sh\n# To build with debug option enabled and if the Tcl library is not on the default path\n./etc/Build.sh -cmake=\"-DCMAKE_BUILD_TYPE=DEBUG -DTCL_LIB=/path/to/tcl/lib\"\n```\n\nThe default install directory is `/usr/local`.\nTo install in a different directory use:\n\n``` shell\n./etc/Build.sh -cmake=\"-DCMAKE_INSTALL_PREFIX=<prefix_path>\"\n```\n\n", "id:database_4\n# OpenDB\n### Python\n\nAfter building successfully, run `openroad -python` to enable the Python\ninterpreter. You can find examples on using the API from Python under\n`test/python/` directory.\n\nTo list the full set of the Python classes exposed run `openroad -python`\nthen:\n```\nimport openroad\nimport odb\nprint(', '.join(dir(openroad)))\nprint(', '.join(dir(odb)))\n```\n\n"], "answer": " To build OpenROAD in a custom path, say `<prefix_path>`, the following commands can be run:\\n\\n```shell\\n./etc/Build.sh -cmake=\\\"-DCMAKE_INSTALL_PREFIX=<prefix_path>\\\"\\n```\\nNow to interact with OpenRoad and OpenDB via Python, Python interpreter can be enabled with:\\n\\n``` shell\\nopenroad -python\\n```\\n\\nThen in Python environment:\\n\\n```python\\nimport openroad\\nimport odb\\nprint(', '.join(dir(openroad)))\\nprint(', '.join(dir(odb)))\\n```\\n\\n\n"}
{"id": 53, "type": "gui&installation&test", "question": " I'm trying to visualize specific nets in my design within the OpenROAD GUI. Could you guide me on how to highlight or focus on a particular net and how to remove that focus when required?\n", "ref_num": 1, "reference": ["gui_7"], "reference_content": ["id:gui_7\n### Limit drawing to specific nets\n\n```\nfocus_net net\n          [-remove]\n          [-clear]\n```\n\nOptions description:\n- ``pin``: name of the net.\n- ``remove``: (optional) removes the net from from the focus.\n- ``clear``: (optional) clears all nets from focus.\n\n\n## Commands\n\n"], "answer": " To focus a particular net named \\\"net_name\\\" in the GUI, use the command:\\n```\\nfocus_net net_name\\n```\\nThis will highlight the mentioned net in your design view.\\n\\nTo remove a particular net from the focus, you need to use:\\n```\\nfocus_net net_name -remove\\n```\\nIf you want to clear all the nets from the focus, use:\\n```\\nfocus_net -clear\\n```\\n\\n\n"}
{"id": 54, "type": "functionality", "question": " I'd like to restructure my design for delay optimization in order to enhance the performance of my design. Could you explain how I can achieve this using OpenROAD?\n", "ref_num": 1, "reference": ["restructure_2"], "reference_content": ["id:restructure_2\n# Restructure\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-liberty_file` | Liberty file with description of cells used in design. This is passed to ABC. |\n| `-target` | Either `area` or `delay`. In area mode, the focus is area reduction, and timing may degrade. In delay mode, delay is likely reduced, but the area may increase. The default value is `area`. |\n| `-slack_threshold` | Specifies a (setup) timing slack value below which timing paths need to be analyzed for restructuring. The default value is `0`, and the allowed values are floats `[0, MAX_FLOAT]`. |\n| `-depth_threshold` | Specifies the path depth above which a timing path would be considered for restructuring. The default value is `16`, and the allowed values are `[0, MAX_INT]`. |\n| `-tielo_pin` | Tie cell pin that can drive constant zero. The format is `<cell>/<port>`. |\n| `-tiehi_pin` | Tie cell pin that can drive constant one. The format is `<cell>/<port>`. |\n| `-work_dir` | Name of the working directory for temporary files. If not provided, `run` directory would be used. |\n\n"], "answer": " \"Use the 'restructure' command in OpenROAD to perform this. You need to provide the information of the liberty file and target. Since you wish to target delay, the command you would use is:\\n```tcl\\nrestructure -liberty_file <path_to_liberty_file> -target delay\\n```\\nReplace <path_to_liberty_file> with the path to your particular liberty file. \\nThis will run the restructuring step targeting delay optimization.\\n\\n\n"}
{"id": 55, "type": "vlsi_flow", "question": " I'm planning to use OpenROAD to perform power-oriented tasks. This requires me to read a UPF file for power information then create some logic ports. What are the related commands to conduct these operations?\n", "ref_num": 2, "reference": ["read_UPF_utility_1", "read_UPF_utility_3"], "reference_content": ["id:read_UPF_utility_1\n### Read UPF\n\nSources the UPF file. \n\n```tcl\nread_upf\n    -file file\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-file` | Path to `.upf` file. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:read_UPF_utility_3\n### Create Logic Port\n\n```tcl\ncreate_logic_port\n    [-direction direction]\n    port_name\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-direction` | Direction of the port (`in`, `out`, `inout`). |\n| `port_name` | Port name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " 1. Firstly, sourcing the UPF file is done with `read_upf` command. Assuming your UPF file is located at `path/to/file.upf`, use the following command:\\n\\n```tcl\\nread_upf -file path/to/file.upf\\n```\\n\\n2. Next, to create a logic port, use the `create_logic_port` command. For example, to create an input port named `port1`, use:\\n\\n```tcl\\ncreate_logic_port -direction in port1\\n```\\n\\nBy using these commands you can interact with power-related features offered by OpenROAD.\\n\\n\n"}
{"id": 56, "type": "vlsi_flow", "question": " Given the design area of the semiconductor chip, as an engineer, you need to add power distribution networks and connect them with the appropriate layers. Also, assign specific nets to the bumps while setting the resistance and capacitance for both layers and vias. How can you accomplish these tasks using OpenROAD?\n", "ref_num": 3, "reference": ["power_distribution_network_generator_9", "chip-level_connections_5", "gate_resizing_2"], "reference_content": ["id:power_distribution_network_generator_9\n### Add Connections\n\nThe `add_pdn_connect` command is used to define which layers in the power grid are to be connected together. During power grid generation, vias will be added for overlapping power nets and overlapping ground nets. The use of fixed vias from the technology file can be specified or else via stacks will be constructed using VIARULEs. If VIARULEs are not available in the technology, then fixed vias must be used.\n\n```tcl\nadd_pdn_connect \n    -layers list_of_two_layers\n    [-grid grid_name]\n    [-cut_pitch pitch_value]\n    [-fixed_vias list_of_fixed_vias]\n    [-dont_use_vias list_of_vias]\n    [-max_rows rows]\n    [-max_columns columns]\n    [-ongrid ongrid_layers]\n    [-split_cuts split_cuts_mapping]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-layers` | Layers to be connected where there are overlapping power or overlapping ground nets. |\n| `-grid` | Specifies the name of the grid definition to which this connection will be added (Default: Last grid created by `define_pdn_grid`). |\n| `-cut_pitch` | When the two layers are parallel, e.g., overlapping stdcell rails, specify the distance between via cuts. |\n| `-fixed_vias` | List of fixed vias to be used to form the via stack. |\n| `-dont_use_vias` | List or pattern of vias to not use to form the via stack. |\n| `-max_rows` | Maximum number of rows when adding arrays of vias. |\n| `-max_columns` | Maximum number of columns when adding arrays of vias. |\n| `-ongrid` | List of intermediate layers in a via stack to snap onto a routing grid. |\n| `-split_cuts` | Specifies layers to use split cuts on with an associated pitch, for example `{metal3 0.380 metal5 0.500}`. |\n\nExample usage:\n\n```tcl\nadd_pdn_connect -grid main_grid -layers {metal1 metal2} -cut_pitch 0.16\nadd_pdn_connect -grid main_grid -layers {metal2 metal4}\nadd_pdn_connect -grid main_grid -layers {metal4 metal7}\n\nadd_pdn_connect -grid ram -layers {metal4 metal5}\nadd_pdn_connect -grid ram -layers {metal5 metal6}\nadd_pdn_connect -grid ram -layers {metal6 metal7}\n\nadd_pdn_connect -grid rotated_rams -layers {metal4 metal6}\nadd_pdn_connect -grid rotated_rams -layers {metal6 metal7}\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:chip-level_connections_5\n### Assigning a Net to a Bump\n\nTo assign a net to a bump.\n\n```tcl\nassign_io_bump \n    -net net\n    [-terminal iterm]\n    [-dont_route]\n    instance\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net` | Net to connect to. |\n| `-terminal` | Instance terminal to route to. |\n| `-dont_route` | Flag to indicate that this bump should not be routed, only perform assignment. |\n| `instance` | Name of the bump. |\n\nExample usage:\n\n```tcl\nassign_io_bump -net p_ddr_addr_9_o BUMP_6_0\nassign_io_bump -net p_ddr_addr_8_o BUMP_6_2\nassign_io_bump -net DVSS BUMP_6_4\nassign_io_bump -net DVDD BUMP_7_3\nassign_io_bump -net DVDD -terminal u_dvdd/DVDD BUMP_8_3\nassign_io_bump -net p_ddr_addr_7_o BUMP_7_1\nassign_io_bump -net p_ddr_addr_6_o BUMP_7_0\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gate_resizing_2\n### Set Layer RC\n\nThe `set_layer_rc` command can be used to set the resistance and capacitance\nfor a layer or via. This is useful if these values are missing from the LEF file,\nor to override the values in the LEF.\n\n```tcl\nset_layer_rc \n    [-layer layer]\n    [-via via_layer]\n    [-resistance res]\n    [-capacitance cap]\n    [-corner corner]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-layer` | Set layer name to modify. Note that the layer must be a routing layer. |\n| `-via` | Select via layer name. Note that via resistance is per cut/via, not area-based. |\n| `-resistance` | Resistance per unit length, same convention as `set_wire_rc`. |\n| `-capacitance` | Capacitance per unit length, same convention as `set_wire_rc`. |\n| `-corner` | Process corner to use. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To add the connections, use `add_pdn_connect` as follows:\\n\\n```tcl\\nadd_pdn_connect -grid main_grid -layers {metal1 metal2} -cut_pitch 0.16\\nadd_pdn_connect -grid main_grid -layers {metal2 metal4}\\nadd_pdn_connect -grid main_grid -layers {metal4 metal7}\\n```\\n\\nTo assign nets to bumps, the `assign_io_bump` command can be used:\\n\\n```tcl\\nassign_io_bump -net p_ddr_addr_9_o BUMP_6_0\\nassign_io_bump -net p_ddr_addr_8_o BUMP_6_2\\n```\\n\\nFinally, you can set the resistance and capacitance of layers and vias:\\n\\n```tcl\\nset_layer_rc -layer metal1 -resistance 0.2 -capacitance 0.1\\nset_layer_rc -via via1 -resistance 0.3 -capacitance 0.2\\n```\\n\\n\n"}
{"id": 57, "type": "functionality", "question": " What are tielo_pin and tiehi_pin in OpenROAD?\n", "ref_num": 1, "reference": ["restructure_0"], "reference_content": ["id:restructure_0\n# Restructure\n\nThe restructure module in OpenROAD (`rmp`) is based on \nan interface to ABC for local resynthesis. The package allows\nlogic restructuring that targets area or timing. It extracts a cloud of logic\nusing the OpenSTA timing engine, and passes it to ABC through `blif` interface.\nMultiple recipes for area or timing are run to obtain multiple structures from ABC;\nthe most desirable among these is used to improve the netlist.\nThe ABC output is read back by a `blif` reader which is integrated to OpenDB.\n`blif` writer and reader also support constants from and to OpenDB. Reading\nback of constants requires insertion of tie cells which should be provided\nby the user as per the interface described below.\n\n"], "answer": " tielo_pin and tiehi_pin are tie cell pin that can drive constant zero/one.\n"}
{"id": 58, "type": "functionality", "question": " How to make the pin placer to generate varuous and different pin placement solutions for larger design space exploration?\n", "ref_num": 2, "reference": ["pin_placement_7", "pin_placement_9"], "reference_content": ["id:pin_placement_7\n### Set Simulated Annealing Parameters\n\nThe `set_simulated_annealing` command defines the parameters for simulated annealing pin placement.\n\n```tcl\nset_simulated_annealing\n    [-temperature temperature]\n    [-max_iterations iter]\n    [-perturb_per_iter perturbs]\n    [-alpha alpha]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-temperature` | Temperature parameter. The default value is `1.0`, and the allowed values are floats `[0, MAX_FLOAT]`. |\n| `-max_iterations` | The maximum number of iterations. The default value is `2000`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-perturb_per_iter` | The number of perturbations per iteration. The default value is `0`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-alpha` | The temperature decay factor. The default value is `0.985`, and the allowed values are floats `(0, 1]`. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:pin_placement_9\n### Place All Pins\n\nUse the following command to perform pin placement:\n\n```tcl\nplace_pins \n    -hor_layers h_layers\n    -ver_layers v_layers\n    [-random_seed seed]\n    [-random]\n    [-corner_avoidance length]\n    [-min_distance distance]\n    [-min_distance_in_tracks]\n    [-exclude region]\n    [-group_pins pin_list]\n    [-annealing]\n    [-write_pin_placement file_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-hor_layers` | The layers to create the metal shapes of pins placed in horizontal tracks. It can be a single layer or a list of layer names. |\n| `-ver_layers` | The layers to create the metal shapes of pins placed in vertical tracks. It can be a single layer or a list of layer names. |\n| `-corner_avoidance` | The distance (in microns) from each corner within which pin placement should be avoided. |\n| `-min_distance` | The minimum distance between pins on the die boundary. This distance can be in microns (default) or in number of tracks between each pin. |\n| `-min_distance_in_tracks` | Flag that allows setting the min distance in number of tracks instead of microns. |\n| `-exclude` | A region where pins cannot be placed. Either `top|bottom|left|right:edge_interval`, which is the edge interval from the selected edge; `begin:end` for begin-end of all edges. |\n| `-group_pins` | A list of pins to be placed together on the die boundary. |\n| `-annealing` | Flag to enable simulated annealing pin placement. |\n| `-write_pin_placement` | A file with the pin placement generated in the format of multiple calls for the `place_pin` command. |\n\nThe `exclude` option syntax is `-exclude edge:interval`. The `edge` values are\n(top|bottom|left|right). The `interval` can be the whole edge, with the `*`\nvalue, or a range of values. For example, in `place_pins -hor_layers metal2\n-ver_layers metal3 -exclude top:* -exclude right:15-60.5 -exclude left:*-50`\nthree intervals are excluded: the whole top edge, the right edge from 15\nmicrons to 60.5 microns, and the left edge from its beginning to 50 microns.\n\n#### Developer Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-random_seed` | Specify the seed for random operations. |\n| `-random` | When this flag is enabled, the pin placement is random. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " 1. Your can use the set_simulated_annealing command to define the parameters for simulated annealing pin placement for various solutions. Use the command:\\n```\\nset_simulated_annealing\\n    [-temperature temperature]\\n    [-max_iterations iter]\\n    [-perturb_per_iter perturbs]\\n    [-alpha alpha]\\n```\\nwhere -temperature is the temperature parameter, -max_iterations is the maximum number of iterations, -perturb_per_iter is the number of perturbations per iteration, and -alpha is the temperature decay factor.\\n2. Then, you can run the ```place_pins``` command to place all pins:\\n```\\nplace_pins \\n    -hor_layers h_layers\\n    -ver_layers v_layers\\n    -annealing\\n```\\n-hor_layers/-ver_layers are The layers to create the metal shapes of pins placed in horizontal/vertical tracks.\n"}
{"id": 59, "type": "functionality", "question": " During macro placement, how should I push macros to the corners?\n", "ref_num": 1, "reference": ["macro_placement_0"], "reference_content": ["id:macro_placement_0\n# Macro Placement\n\nThe macro placement module in OpenROAD (`mpl`) is based on \nTritonMacroPlacer, an open-source ParquetFP-based macro cell placer.\nThe macro placer places macros/blocks honoring halos, channels\nand cell row \"snapping\".\nRun `global_placement` before macro placement.\n\nApproximately $\\Bigl\\lceil [{\\frac{numMacros}{3}}]^{1.5} \\Bigr\\rceil$ quadrisections\nof the initial placed mixed-size layout are explored and packed using\nParquetFP-based annealing. The best resulting floorplan according to a\nheuristic evaluation function is kept.\n\n"], "answer": " You can use the style \"corner_max_wl\" of the command \"macro_placement\" during macro placement. \"corner_max_wl\" means that choosing the partitions that maximise the wirelength of connections between the macros to force them to the corners. You can use the command:\\n```\\nmacro_placement -style corner_wax_wl\\n```\\n\n"}
{"id": 60, "type": "functionality", "question": " During macro placement, I want to decrease the notch (dead space) of the placement. How should i do that?\n", "ref_num": 1, "reference": ["hierarchical_macro_placement_1"], "reference_content": ["id:hierarchical_macro_placement_1\n### Hier-RTLMP algorithm\n\n```tcl\nrtl_macro_placer \n    [-max_num_macro max_num_macro]\n    [-min_num_macro min_num_macro]\n    [-max_num_inst max_num_inst]  \n    [-min_num_inst min_num_inst] \n    [-tolerance tolerance]     \n    [-max_num_level max_num_level] \n    [-coarsening_ratio coarsening_ratio]\n    [-num_bundled_ios num_bundled_ios]\n    [-large_net_threshold large_net_threshold]\n    [-signature_net_threshold signature_net_threshold]\n    [-halo_width halo_width] \n    [-fence_lx fence_lx] \n    [-fence_ly fence_ly]\n    [-fence_ux fence_ux]\n    [-fence_uy fence_uy]\n    [-area_weight area_weight] \n    [-outline_weight outline_weight] \n    [-wirelength_weight wirelength_weight]\n    [-guidance_weight guidance_weight]\n    [-fence_weight fence_weight] \n    [-boundary_weight boundary_weight]\n    [-notch_weight notch_weight]\n    [-macro_blockage_weight macro_blockage_weight]\n    [-pin_access_th pin_access_th]\n    [-target_util target_util]\n    [-target_dead_space target_dead_space]\n    [-min_ar min_ar]\n    [-snap_layer snap_layer]\n    [-bus_planning]\n    [-report_directory report_directory]\n    [-write_macro_placement file_name]\n```\n\n#### Generic Parameters\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-max_num_macro`, `-min_num_macro` | Maximum/minimum number of macros in a cluster. The default value is `0` for both, and the allowed values are integers `[0, MAX_INT]`. |\n| `-max_num_inst`, `-min_num_inst` | Maximum/minimum number of standard cells in a cluster. The default value is `0` for both, and the allowed values are integers `[0, MAX_INT]`. |\n| `-tolerance` | Add a margin to the minimum and maximum number of macros/std cells in a cluster. For min, we multiply by (1 - `tol`), and for the max (1 + `tol`). This is to improve the robustness of hierarchical clustering. The allowed values are floats `[0, 1)`, and the default value is `0.1`. |\n| `-max_num_level` | Maximum depth of physical hierarchical tree. The default value is `2`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-coarsening_ratio` | The larger the coarsening_ratio, the faster the convergence process. The allowed values are floats, and the default value is `10.0`. |\n| `-num_bundled_ios` | Specifies the number of bundled pins for the left, right, top, and bottom boundaries. The default value is `3`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-large_net_threshold` | Ignore nets with many connections during clustering, such as global nets. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-signature_net_threshold` | Minimum number of connections between two clusters to be identified as connected. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-halo_width` | Horizontal/vertical halo around macros (microns). The allowed values are floats, and the default value is `0.0`. |\n| `-fence_lx`, `-fence_ly`, `-fence_ux`, `-fence_uy` | Defines the global fence bounding box coordinates. The default values are the core area coordinates). |\n| `-pin_access_th` | Specifies the pin access threshold value of macros. The default value is `0.0`, and the allowed values are floats [0,1]. |\n| `-target_util` | Specifies the target utilization of `MixedCluster` and has higher priority than target_dead_space. The allowed values are floats, and the default value is `0.25`. |\n| `-target_dead_space` | Specifies the target dead space percentage, which influences the utilization of `StandardCellCluster`. The allowed values are floats, and the default value is `0.05`. |\n| `-min_ar` | Specifies the minimum aspect ratio $a$, or the ratio of its width to height of a `StandardCellCluster` from $[a, \\frac{1}{a}]$. The allowed values are floats, and the default value is `0.33`. |\n| `-snap_layer` | Snap macro origins to this routing layer track. The default value is 4, and the allowed values are integers `[1, MAX_LAYER]`). |\n| `-bus_planning` | Flag to enable bus planning. We recommend to enable bus planning for technologies with very limited routing layers such as SKY130 and GF180. As for technologies such as NanGate45 and ASAP7, we recommend to keep it disabled. |\n| `-report_directory` | Save reports to this directory. |\n| `-write_macro_placement` | Generates a file with the placement of the macros placed by HierRTLMP flow in the format of multiple calls for the `place_macro` command. |\n\n\n#### Simulated Annealing Weight parameters\n\nDo note that while action probabilities are normalized to 1.0, the weights are not necessarily normalized. \n\n| Switch Name | Description | \n| ----- | ----- |\n| `-area_weight` | Weight for the area of current floorplan.  The allowed values are floats, and the default value is `0.1`. |\n| `-outline_weight` | Weight for violating the fixed outline constraint, meaning that all clusters should be placed within the shape of their parent cluster.  The allowed values are floats, and the default value is `100.0`. |\n| `-wirelength_weight` | Weight for half-perimeter wirelength.  The allowed values are floats, and the default value is `100.0`. |\n| `-guidance_weight` | Weight for guidance cost or clusters being placed near specified regions if users provide such constraints.  The allowed values are floats, and the default value is `10.0`. |\n| `-fence_weight` | Weight for fence cost, or how far the macro is from zero fence violation.  The allowed values are floats, and the default value is `10.0`. |\n| `-boundary_weight` | Weight for the boundary, or how far the hard macro clusters are from boundaries. Note that mixed macro clusters are not pushed, thus not considered in this cost.  The allowed values are floats, and the default value is `50.0`. |\n| `-notch_weight` | Weight for the notch, or the existence of dead space that cannot be used for placement & routing. Note that this cost applies only to hard macro clusters.  The allowed values are floats, and the default value is `10.0`. |\n| `-macro_blockage_weight` | Weight for macro blockage, or the overlapping instances of the macro.  The allowed values are floats, and the default value is `10.0`. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The option \"-notch_weight\" of the command ```rtl_macro_placer ``` is used to control the ratio of notch of the macro placement. The default value of -notch_weight is 10.0. To further reduce the notch ratio, you can set a higher value of -notch_weight, say, 15, and use the command:\\n```\\nrtl_macro_placer -notch_weight 15\\n```\n"}
{"id": 61, "type": "functionality", "question": " What is the difference between the command ```set_dont_use``` and ```set_dont_touch```?\n", "ref_num": 2, "reference": ["gate_resizing_4", "gate_resizing_5"], "reference_content": ["id:gate_resizing_4\n### Set Don't Use\n\nThe `set_dont_use` command removes library cells from consideration by\nthe `resizer` engine and the `CTS` engine. `lib_cells` is a list of cells returned by `get_lib_cells`\nor a list of cell names (`wildcards` allowed). For example, `DLY*` says do\nnot use cells with names that begin with `DLY` in all libraries.\n\n```tcl\nset_dont_use lib_cells\nunset_dont_use lib_cells\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gate_resizing_5\n### Set Don't Touch\n\nThe `set_dont_touch` command prevents the resizer commands from\nmodifying instances or nets.\n\n```tcl\nset_dont_touch instances_nets\nunset_dont_touch instances_nets\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Both commands are used by the ```resizer``` engine. \\nThe ```set_dont_use``` command removes library cells from consideration by the resizer engine and the CTS engine, meanwhile, the ```set_dont_touch``` command prevents the resizer commands from modifying instances or nets.\n"}
{"id": 62, "type": "vlsi_flow", "question": " When using the command ```repair_timing```, why can we specify a value of maximal utilization? Why the utilization will increase during timing repair?\n", "ref_num": 1, "reference": ["gate_resizing_10"], "reference_content": ["id:gate_resizing_10\n### Repair Timing\n\nThe `repair_timing` command repairs setup and hold violations.  It\nshould be run after clock tree synthesis with propagated clocks.\nSetup repair is done before hold repair so that hold repair does not\ncause setup checks to fail.\n\nThe worst setup path is always repaired.  Next, violating paths to\nendpoints are repaired to reduced the total negative slack. \n\n```tcl\nrepair_timing \n    [-setup]\n    [-hold]\n    [-recover_power percent_of_paths_with_slack]\n    [-setup_margin setup_margin]\n    [-hold_margin hold_margin]\n    [-allow_setup_violations]\n    [-skip_pin_swap]\n    [-skip_gate_cloning]\n    [-repair_tns tns_end_percent]\n    [-max_utilization util]\n    [-max_buffer_percent buffer_percent]\n    [-verbose]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-setup` | Repair setup timing. |\n| `-hold` | Repair hold timing. |\n| `-recover_power` | Set the percentage of paths to recover power for. The default value is `0`, and the allowed values are floats `(0, 100]`. |\n| `-setup_margin` | Add additional setup slack margin. |\n| `-hold_margin` | Add additional hold slack margin. |\n| `-allow_setup_violations` | While repairing hold violations, buffers are not inserted that will cause setup violations unless `-allow_setup_violations` is specified. |\n| `-skip_pin_swap` | Flag to skip pin swap. The default value is `False`, and the allowed values are bools. |\n| `-skip_gate_cloning` | Flag to skip gate cloning. The default value is `False`, and the allowed values are bools. |\n| `-repair_tns` | Percentage of violating endpoints to repair (0-100). When `tns_end_percent` is zero (the default), only the worst endpoint is repaired. When `tns_end_percent` is 100, all violating endpoints are repaired. |\n| `-max_utilization` | Defines the percentage of core area used. |\n| `-max_buffer_percent` | Specify a maximum number of buffers to insert to repair hold violations as a percentage of the number of instances in the design. The default value is `20`, and the allowed values are integers `[0, 100]`. |\n| `-verbose` | Enable verbose logging of the repair progress. |\n\nUse`-recover_power` to specify the percent of paths with positive slack which\nwill be considered for gate resizing to save power. It is recommended that\nthis option be used with global routing based parasitics. \n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " Buffering is a command method for timing violation fix. After inserting buffers to the design, the total area of instances, and thus the utilization will be increased. Therefore, when using the command ```repair_timing```, the user can specify a value of -max_utilization to control the maximal utilization rate.\n"}
{"id": 63, "type": "functionality", "question": " When I run the ```detailed_placement``` command, I found that the positions of the cells did not change at all. Why and how can I resolve this?\n", "ref_num": 1, "reference": ["detailed_placement_1"], "reference_content": ["id:detailed_placement_1\n### Detailed Placement\n\nThe `detailed_placement` command performs detailed placement of instances\nto legal locations after global placement.\n\n```tcl\ndetailed_placement\n    [-max_displacement disp|{disp_x disp_y}]\n    [-disallow_one_site_gaps]\n    [-report_file_name filename]\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-max_displacement` | Max distance that an instance can be moved (in microns) when finding a site where it can be placed. Either set one value for both directions or set `{disp_x disp_y}` for individual directions. The default values are `{0, 0}`, and the allowed values within are integers `[0, MAX_INT]`. |\n| `-disallow_one_site_gaps` | Disable one site gap during placement check. |\n| `-report_file_name` | File name for saving the report to (e.g. `report.json`. |\n\n## Commands\n\n"], "answer": " The reason may be that you didn't specify the ```-max_displacement``` option. ```-max_displacement``` is the max distance that an instance can be moved (in microns) when finding a site where it can be placed, the default value of ```-max_displacement``` is set to 0.\\nYou can use the command in this way:\\n```\\ndetailed_placement -max_displacement disp\\n```\\nThe ```disp``` is the value of maximal displacement for each instance.\n"}
{"id": 64, "type": "vlsi_flow", "question": " I want to conduct clock tree synthesis (CTS) on a design, with the maximal slew under 10 ps and only use the buffer type \"BUF1X\". After CTS, I want to view the report. How should I do that in OpenROAD?\n", "ref_num": 3, "reference": ["clock_tree_synthesis_1", "clock_tree_synthesis_2", "clock_tree_synthesis_3"], "reference_content": ["id:clock_tree_synthesis_1\n### Configure CTS Characterization\n\n```tcl\nconfigure_cts_characterization \n    [-max_slew max_slew]\n    [-max_cap max_cap]\n    [-slew_steps slew_steps]\n    [-cap_steps cap_steps]\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-max_slew` | Max slew value (in the current time unit) that the characterization will test. If this parameter is omitted, the code would use max slew value for specified buffer in `buf_list` from liberty file. |\n| `-max_cap` | Max capacitance value (in the current capacitance unit) that the characterization will test. If this parameter is omitted, the code would use max cap value for specified buffer in `buf_list` from liberty file. |\n| `-slew_steps` | Number of steps that `max_slew` will be divided into for characterization. The default value is `12`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-cap_steps` | Number of steps that `max_cap` will be divided into for characterization. The default value is `34`, and the allowed values are integers `[0, MAX_INT]`. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:clock_tree_synthesis_2\n### Clock Tree Synthesis\n\n```tcl\nclock_tree_synthesis \n    -buf_list <list_of_buffers>\n    [-root_buf root_buf]\n    [-wire_unit wire_unit]\n    [-clk_nets <list_of_clk_nets>]\n    [-distance_between_buffers]\n    [-branching_point_buffers_distance]\n    [-clustering_exponent]\n    [-clustering_unbalance_ratio]\n    [-sink_clustering_enable]\n    [-sink_clustering_size cluster_size]\n    [-sink_clustering_max_diameter max_diameter]\n    [-balance_levels]\n    [-num_static_layers]\n    [-sink_clustering_buffer]\n    [-use_dummy_load]\n    [-insertion_delay]\n    [-sink_buffer_max_cap_derate derate_value]\n    [-delay_buffer_derate derate_value]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-buf_list` | Tcl list of master cells (buffers) that will be considered when making the wire segments (e.g. `{BUFXX, BUFYY}`). |\n| `-root_buffer` | The master cell of the buffer that serves as root for the clock tree. If this parameter is omitted, the first master cell from `-buf_list` is taken. |\n| `-wire_unit` | Minimum unit distance between buffers for a specific wire. If this parameter is omitted, the code gets the value from ten times the height of `-root_buffer`. |\n| `-clk_nets` | String containing the names of the clock roots. If this parameter is omitted, `cts` automatically looks for the clock roots automatically. |\n| `-distance_between_buffers` | Distance (in microns) between buffers that `cts` should use when creating the tree. When using this parameter, the clock tree algorithm is simplified and only uses a fraction of the segments from the LUT. |\n| `-branching_point_buffers_distance` | Distance (in microns) that a branch has to have in order for a buffer to be inserted on a branch end-point. This requires the `-distance_between_buffers` value to be set. |\n| `-clustering_exponent` | Value that determines the power used on the difference between sink and means on the CKMeans clustering algorithm. The default value is `4`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-clustering_unbalance_ratio` | Value determines each cluster's maximum capacity during CKMeans. A value of `0.5` (i.e., 50%) means that each cluster will have exactly half of all sinks for a specific region (half for each branch). The default value is `0.6`, and the allowed values are floats `[0, 1.0]`. |\n| `-sink_clustering_enable` | Enables pre-clustering of sinks to create one level of sub-tree before building H-tree. Each cluster is driven by buffer which becomes end point of H-tree structure. |\n| `-sink_clustering_size` | Specifies the maximum number of sinks per cluster. The default value is `20`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-sink_clustering_max_diameter` | Specifies maximum diameter (in microns) of sink cluster. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-balance_levels` | Attempt to keep a similar number of levels in the clock tree across non-register cells (e.g., clock-gate or inverter). The default value is `False`, and the allowed values are bool. |\n| `-clk_nets` | String containing the names of the clock roots. If this parameter is omitted, `cts` looks for the clock roots automatically. |\n| `-num_static_layers` | Set the number of static layers. The default value is `0`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-sink_clustering_buffer` | Set the sink clustering buffer(s) to be used. |\n| `-obstruction_aware` | Enables obstruction-aware buffering such that clock buffers are not placed on top of blockages or hard macros. This option may reduce legalizer displacement, leading to better latency, skew or timing QoR.  The default value is `False`, and the allowed values are bool. |\n| `-apply_ndr` | Applies 2X spacing non-default rule to all clock nets except leaf-level nets. The default value is `False`. |\n| `-no_insertion_delay` | Don't consider insertion delays in macro timing models in balancing latencies between macro cells and registers. This option prevents construction of separate clock trees for macro cells and registers.  The default value is `False`. |\n| `-use_dummy_load` | Applies dummy buffer or inverter cells at clock tree leaves to balance loads.  The default values is `False`. |\n| `-sink_buffer_max_cap_derate` | Use this option to control automatic buffer selection. To favor strong(weak) drive strength buffers use a small(large) value.  The default value is `0.01`, meaning that buffers are selected by derating max cap limit by 0.01. The value of 1.0 means no derating of max cap limit.  |\n| `-delay_buffer_derate` | This option is used with -insertion_delay option that balances latencies between macro cells and registers by inserting delay buffers.  The default values is `1.0`, meaning all needed delay buffers are inserted.  Value of 0.5 means only half of necessary delay buffers are inserted.  Value of 0.0 means no insertion of delay buffers. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:clock_tree_synthesis_3\n### Report CTS\n\nAnother command available from `cts` is `report_cts`. It is used to\nextract metrics after a successful `clock_tree_synthesis` run. These are:\n \n- Number of Clock Roots\n- Number of Buffers Inserted\n- Number of Clock Subnets\n- Number of Sinks.  \n\n```tcl\nreport_cts \n    [-out_file file]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-out_file` | The file to save `cts` reports. If this parameter is omitted, the report is streamed to `stdout` and not saved. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " 1. You should configure key CTS characterization parameters using the command:\\n```\\nconfigure_cts_characterization -max_slew 10\\n```\\n2. Then, run the command for CTS using the buffer \"BUF1X\":\\n```\\nclock_tree_synthesis -buf_list {BUF1X}\\n```\\n3. Finally, run the command ```report_cts``` to report the number of clock roots, the number of buffers inserted, the number of clock subnets and number of sinks:\\n```\\nreport_cts -out_file file\\n```\n"}
{"id": 65, "type": "gui&installation&test", "question": " How to add items to the menubar using OpenROAD's GUI?\n", "ref_num": 1, "reference": ["gui_2"], "reference_content": ["id:gui_2\n### Add items to the menubar\n\n```\ncreate_menu_item [-name name]\n                 [-path menu_path]\n                 -text item_text\n                 -script tcl_script\n                 [-shortcut key_shortcut] \n                 [-echo]\n```\n\nReturns: name of the new item, either ``name`` or ``actionX``.\n\nOptions description:\n- ``item_text``: The text to put on the item.\n- ``tcl_script``: The tcl script to evaluate when the button is pressed.\n- ``name``: (optional) name of the item, used when deleting the item.\n- ``menu_path``: (optional) Menu path to place the new item in (hierarchy is separated by /), defaults to \"Custom Scripts\", but this can also be \"Tools\" or \"New menu/New submenu\".\n- ``key_shortcut``: (optional) key shortcut to trigger this item.\n- ``echo``: (optional) indicate that the commands in the ``tcl_script`` should be echoed in the log.\n\nTo remove the item: \n\n```\ngui::remove_menu_item name\n```\n\n\n## Commands\n\n"], "answer": " In the OpenROAD's GUI, a menu item can be added using the command `create_menu_item` exposed by the Tcl interface:\\n\\n```tcl\\ncreate_menu_item -name myButton\\n                 -path CustomScripts\\n                 -text \\\"My Custom Button\\\"\\n                 -script {puts \\\"Hello world\\\"}\\n                 -shortcut \\\"Ctrl+x\\\" \\n                 -echo\\n```\\nThe name of the newly created item will be returned by the command.\\nIf you wish to remove the item that was created, you can use the `remove_menu_item` command as follows:\\n\\n```tcl\\ngui::remove_menu_item myButton\\n```\\n\\nThis will remove the button named \\\"myButton\\\" from the menubar.\\n\\n\n"}
{"id": 66, "type": "gui&installation&test", "question": " What does the Python Unit Test `test_swap_master` do? How can I run this test in parallel?\n", "ref_num": 2, "reference": ["unit_test_9", "unit_test_1"], "reference_content": ["id:unit_test_9\n# Python Unit Tests\n### TestInst.py:\n\nUnit Test for dbInst\n\n* `test_swap_master` testing swap master function\n\n", "id:unit_test_1\n# Python Unit Tests\n## Running tests\n\nFor running the python unit tests you will need to install first *testtools* and *unittest-parallel* which enables concurrent unit testing\n\n``` shell\npip3 install testtools\npip3 install unittest-parallel\n```\n\nThen, you can run the unit tests  in sequence by running\n\n``` shell\n../unitTests.sh\n```\n\nor in parallel by running\n\n``` shell\n../unitTests.sh parallel\n```\n\n**Note**: The test cases within each Unit Test run in parallel in both situations\n\n--------------------------------------------------------------------------\n\n"], "answer": " The `test_swap_master` is a unit test for the dbInst class in the OpenROAD framework. As the name suggests, it tests the functionality of the swap master function. This function is used to swap a cell instance in a design with another master cell.\\n\\nTo run the unit tests in parallel, you first need to install the packages *testtools* and *unittest-parallel* using the commands:\\n\\n```shell\\npip3 install testtools\\npip3 install unittest-parallel\\n```\\n\\nOnce the packages are installed, you can run the unit tests in parallel by executing:\\n\\n```shell\\n../unitTests.sh parallel\\n```\\nThis allows your test cases to execute at the same time, increasing the efficiency of your testing process.\\n\\n\n"}
{"id": 67, "type": "functionality", "question": " Once the design is routed, how can I estimate the parasitics?\n", "ref_num": 1, "reference": ["global_routing_12"], "reference_content": ["id:global_routing_12\n### Estimate Global Routing Parasitics\n\nTo estimate RC parasitics based on global route results, use the `-global_routing`\noption of the `estimate_parasitics` command.\n\n```{note}\nTo see the function definition for `estimate_parasitics`, refer to \n[Resizer docs](../rsz/README.md#estimate-parasitics).\n```\n\n```tcl\nestimate_parasitics -global_routing\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " You can estimate the parasitics after global routing by running:\\n\\n```tcl\\nestimate_parasitics -global_routing\\n```\\n\\n\n"}
{"id": 68, "type": "gui&installation&test", "question": " How can I implement the power grid of a design, analyze the power grid and then visualize the results in OpenROAD?\n", "ref_num": 3, "reference": ["power_distribution_network_generator_1", "IR_Drop_analysis_2", "gui_14"], "reference_content": ["id:power_distribution_network_generator_1\n### Build Power Grid\n\nBuild a power grid in accordance with the information specified.\n\n```tcl\npdngen \n    [-skip_trim]\n    [-dont_add_pins]\n    [-reset]\n    [-ripup]\n    [-report_only]\n    [-failed_via_report file]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-skip_trim` | Skip the metal trim step, which attempts to remove metal stubs. |\n| `-dont_add_pins` | Prevent the creation of block pins. |\n| `-reset` | Reset the grid and domain specifications. |\n| `-ripup` | Ripup the existing power grid, as specified by the voltage domains. |\n| `-report_only` | Print the current specifications. |\n| `-failed_via_report` | Generate a report file that can be viewed in the DRC viewer for all the failed vias (i.e., those that did not get built or were removed). |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:IR_Drop_analysis_2\n### Check Power Grid\n\n```tcl\ncheck_power_grid -net net_name\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net` | Name of the net to analyze. Must be a power or ground net name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:gui_14\n### Heat Maps\n\nThe currently availble heat maps are:\n\n- ``Power``\n- ``Routing``\n- ``Placement``\n- ``IRDrop``\n- ``RUDY`` [^RUDY]\n\nTo control the settings in the heat maps:\n\n```\ngui::set_heatmap name option\ngui::set_heatmap name option value\n```\n\nOptions description:\n- ``name`` is the name of the heatmap.\n- ``option`` is the name of the option to modify. If option is ``rebuild`` the map will be destroyed and rebuilt.\n- ``value`` is the new value for the specified option. This is not used when rebuilding map.\n\nThese options can also be modified in the GUI by double-clicking the underlined display control for the heat map.\n\n\nTo save the raw data from the heat maps ins a comma separated value (CSV) format:\n\n```\ngui::dump_heatmap name filename\n```\n\nOptions description: \n- ``name`` is the name of the heatmap.\n- ``filename`` path to the file to write the data to.\n\n[^RUDY]: RUDY means Rectangular Uniform wire DensitY, which can predict the routing density very rough and quickly. You can see this notion in [this paper](https://past.date-conference.com/proceedings-archive/2007/DATE07/PDFFILES/08.7_1.PDF) \n\n\n\n## Commands\n\n"], "answer": " 1. Run the 'pdngen' command to implement the power grid as documented in core_grid_snap.tcl.\\n\\n2. Use 'check_power_grid -net NETNAME' command to analyse the power grid, replace 'NETNAME' with the name of your power or ground net.\\n\\n3. To visualize the results of power grid analysis in OpenROAD GUI, use the Heat Maps feature with the command 'gui::set_heatmap Power rebuild'. You can also save the raw data from the heat maps in a CSV format by running `gui::dump_heatmap Power filename`, replace 'filename' with the path to the file you want to write the data to.\\n\\n\n"}
{"id": 69, "type": "functionality", "question": " While working on my semiconductor digital design, how to connect an external module to my present design?\n", "ref_num": 1, "reference": ["read_UPF_utility_3"], "reference_content": ["id:read_UPF_utility_3\n### Create Logic Port\n\n```tcl\ncreate_logic_port\n    [-direction direction]\n    port_name\n```\n\n#### Options\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-direction` | Direction of the port (`in`, `out`, `inout`). |\n| `port_name` | Port name. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " You can use OpenROAD's `create_logic_port` command to add logic ports when interconnecting external modules with your design. You need to define the direction of the port using `-direction` option and the name of the port. Here is an example of how to use it:\\n\\n```tcl\\ncreate_logic_port -direction in port1\\ncreate_logic_port -direction out port2\\n```\\nIn this example, `port1` is an input port from an external module to your design and `port2` is an output port from your design to the external module.\\n\\n\n"}
{"id": 70, "type": "functionality", "question": " I noticed that after using `repair_design` to fix my max slew, max capacitance, and max fanout violations, some instances are resized. If there are specific instances or nets that I don't want to be modified, how can I prevent them from being altered?\n", "ref_num": 2, "reference": ["gate_resizing_5", "flow-scripts-tutorial_37"], "reference_content": ["id:gate_resizing_5\n### Set Don't Touch\n\nThe `set_dont_touch` command prevents the resizer commands from\nmodifying instances or nets.\n\n```tcl\nset_dont_touch instances_nets\nunset_dont_touch instances_nets\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:flow-scripts-tutorial_37\n\n### Timing Optimizations\n\n#### Timing Optimization Using repair_design\n\nThe `repair_design` command inserts buffers on nets to repair `max\nslew, max capacitance and max fanout` violations and on long wires to\nreduce RC delay. It also resizes gates to normalize slews. Use\n`estimate_parasitics -placement` before `repair_design` to account\nfor estimated post-placement parasitics.\n\nRefer to the built-in example [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/rsz/test/repair_slew1.tcl).\n\nLaunch GUI by running the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/rsz/test/\nopenroad -gui\n```\n\nCopy and paste the below commands in the `Tcl Commands` section of GUI.\n\n```tcl\nsource \"helpers.tcl\"\nsource \"hi_fanout.tcl\"\nread_liberty Nangate45/Nangate45_typ.lib\nread_lef Nangate45/Nangate45.lef\nset def_file [make_result_file \"repair_slew1.def\"]\nwrite_hi_fanout_def $def_file 30\nread_def $def_file\n\ncreate_clock -period 1 clk1\nset_wire_rc -layer metal3\n\nestimate_parasitics -placement\nset_max_transition .05 [current_design]\n\nputs \"Found [sta::max_slew_violation_count] violations\"\n```\n\nThe number of violations log as:\n\n```\nFound 31 violations\n```\n\nThese violations were fixed by:\n\n```tcl\nrepair_design\n```\n\nThe log is as follows:\n\n```\n[INFO RSZ-0058] Using max wire length 853um.\n[INFO RSZ-0039] Resized 1 instance.\n```\n\nTo view violation counts again:\n\n```tcl\nputs \"Found [sta::max_slew_violation_count] violations\"\n```\n\nThe log follows:\n\n```\nFound 0 violations\n```\n\n`repair_design` fixed all 31 violations.\n\n"], "answer": " OpenROAD has a command `set_dont_touch` that can be used specifically for this. You can utilize this command to exclude certain instances or nets from being modified by `repair_design`.\\n\\nHere's how to use it:\\n\\n```tcl\\nset_dont_touch instance1 net1\\n```\\n\\nIn this example, `instance1` and `net1` will not be modified by the `repair_design` command.\\n\\nIf you later decide to allow modifications on these instances or nets, just use `unset_dont_touch`:\\n\\n```tcl\\nunset_dont_touch instance1 net1\\n```\\nNow, `instance1` and `net1` can be modified by the `repair_design` command.\\n\\n\n"}
{"id": 71, "type": "vlsi_flow", "question": " How to evaluate the internal, switching leakage power components?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_14"], "reference_content": ["id:flow-scripts-tutorial_14\n\n## Viewing Results And Logs\n\n### Power\n\nUse the report command to view individual power components i.e.\nsequential, combinational, macro and power consumed by I/O pads.\n\n```tcl\nreport_power\n```\n\nThe power output is as follows:\n\n```\n--------------------------------------------------------------------------\nGroup                  Internal  Switching    Leakage      Total\n                          Power      Power      Power      Power\n----------------------------------------------------------------\nSequential             5.58e-03   6.12e-04   1.67e-08   6.19e-03  19.0%\nCombinational          9.23e-03   1.71e-02   4.90e-08   2.63e-02  81.0%\nMacro                  0.00e+00   0.00e+00   0.00e+00   0.00e+00   0.0%\nPad                    0.00e+00   0.00e+00   0.00e+00   0.00e+00   0.0%\n----------------------------------------------------------------\nTotal                  1.48e-02   1.77e-02   6.57e-08   3.25e-02 100.0%\n                          45.6%      54.4%       0.0%\n```\n\n"], "answer": " The user should then check the power output using `report_power`. This command generates records and shows logistics of power consumption within a design.\\n\\\n"}
{"id": 72, "type": "functionality", "question": " During the design process, I mistakenly set some io pin constraints. How do I clear all the previously defined io pin constraints from my design?\n", "ref_num": 1, "reference": ["pin_placement_3"], "reference_content": ["id:pin_placement_3\n### Clear IO Pin Constraints\n\nThe `clear_io_pin_constraints` command clears all the previously-defined\nconstraints and pin shape patterns created with `set_io_pin_constraint` or\n`define_pin_shape_pattern`.\n\n```tcl\nclear_io_pin_constraints\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " You can clear all the previously defined IO pin constraints using the OpenROAD's 'clear_io_pin_constraints' command. Simply run the following command in the Tcl interface of OpenROAD:\\n\\n```tcl\\nclear_io_pin_constraints\\n```\\n\\nThis command will remove all the constraints and pin shape patterns that were previously defined using the 'set_io_pin_constraint' or 'define_pin_shape_pattern' commands in your design.\\n\\n\n"}
{"id": 73, "type": "vlsi_flow", "question": " When creating a new power grid definition and ensuring its validity, how can I specify the power straps to be promoted to block pins and also check if the placement legality after removing fillers?\n", "ref_num": 3, "reference": ["power_distribution_network_generator_3", "detailed_placement_4", "detailed_placement_5"], "reference_content": ["id:power_distribution_network_generator_3\n### Define Power Grid (General)\n\nDefine the rules to describe a power grid pattern to be placed in the design.\n\n```{warning}\n`define_pdn_grid` is overloaded with two different signatures. Take note of the arguments when using this function!\n```\n\n```tcl\ndefine_pdn_grid \n    [-name name] \n    [-voltage_domain list_of_domain_names] \n    [-pins list_of_pin_layers] \n    [-starts_with POWER|GROUND] \n    [-starts_with POWER|GROUND] \n    [-obstructions list_of_layers]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-name` | The name to use when referring to this grid definition. |\n| `-voltage_domain` | This grid's voltage domain name. Defaults to the last domain created. |\n| `-pins` | List of layers where the power straps will be promoted to block pins. |\n| `-starts_with` | Use `POWER` or `GROUND`  for the first placed strap. Defaults to `GROUND`. |\n| `-obstructions` | Layers to add routing blockages to avoid DRC violations. |\n\nExample usage:\n\n```tcl\ndefine_pdn_grid -name main_grid -pins {metal7} -voltage_domain {CORE TEMP_ANALOG}\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:detailed_placement_4\n### Remove Fillers\n\nThis command removes all filler cells.\n\n```tcl\nremove_fillers \n```\n\nNo arguments are needed for this function. \n\n## Commands\n\n", "id:detailed_placement_5\n### Check Placement\n\nThe `check_placement` command checks the placement legality. It returns\n`0` if the placement is legal.\n\n```tcl\ncheck_placement\n    [-verbose]\n    [-disallow_one_site_gaps]\n    [-report_filename filename]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-verbose` | Enable verbose logging. |\n| `-disallow_one_site_gaps` | Disable one site gap during placement check. |\n| `-report_file_name` | File name for saving the report to (e.g. `report.json`. |\n\n## Commands\n\n"], "answer": " Firstly, to define the power grid and specify the power straps to be promoted to block pins, you can use the `define_pdn_grid` command. Do specify the layer where the power straps will be promoted to block pins by using the `-pins` option. For example:\\n\\n```tcl\\ndefine_pdn_grid -name main_grid -pins {metal7} -voltage_domain {CORE TEMP_ANALOG}\\n```\\nYou can replace `{metal7}` with the name of the layer you're promoting to block pins. Also, replace `{CORE TEMP_ANALOG}` with the name of your grid's voltage domain if it is not the last domain created.\\n\\nNext, to check the placement legality, we first need to remove all filler cells. This can be done using `remove_fillers`:\\n\\n```tcl\\nremove_fillers\\n```\\nAfter successfully removing fillers, you can now check placement legality by running the `check_placement` command:\\n\\n```tcl\\ncheck_placement\\n```\\nThis command returns `0` if the placement is legal. If you wish to print more information during the process for debugging purposes or save a report, you can add the `-verbose` or `-report_filename filename` options respectively.\\n\\n\n"}
{"id": 74, "type": "functionality", "question": " What does it mean to set placement padding and how can I specifically set padding only for instances in my design?\n", "ref_num": 1, "reference": ["detailed_placement_2"], "reference_content": ["id:detailed_placement_2\n### Set Placement Padding\n\nThe `set_placement_padding` command sets left and right padding in multiples\nof the row site width. Use the `set_placement_padding` command before\nlegalizing placement to leave room for routing. Use the `-global` flag\nfor padding that applies to all instances. Use  `-instances`\nfor instance-specific padding.  The instances `insts` can be a list of instance\nnames, or an instance object returned by the SDC `get_cells` command. To\nspecify padding for all instances of a common master, use the `-filter`\n\"ref_name == <name>\" option to `get_cells`.\n\n```tcl\nset_placement_padding   \n    -global|-masters masters|-instances insts\n    [-right site_count]\n    [-left site_count]\n```\n\n#### Options\n\n```{warning}\nEither one of these flags must be set: `-global | -masters | -instances`.\nThe order of preference is `global > masters > instances`\n```\n\n| Switch Name | Description | \n| ----- | ----- |\n| `-global` | Set padding globally using `left` and `right` values. |\n| `-masters` |  Set padding only for these masters using `left` and `right` values. | \n| `-instances` | For `-instances`, you will set padding only for these insts using `left` and `right` values. |\n| `-left` | Left padding (in site count). |\n| `-right` | Right padding (in site count). |\n| `instances` | Set padding for these list of instances. Not to be confused with the `-instances` switch above. |\n\n## Commands\n\n"], "answer": " Setting placement padding means to reserve spaces on the left or the right of a cell during the initial placement. It is essential to reduce congestion and facilitate better routing. In OpenROAD, you can set placement padding specifically for instances using the `set_placement_padding` command with the `-instances` option as follows: \\n```tcl\\nset_placement_padding -instances insts -right [site_count] -left [site_count]\\n```\\nHere `insts` could be a list of instance names, or an instance object returned by the SDC `get_cells` command.\\n\\n\n"}
{"id": 75, "type": "gui&installation&test", "question": " I am having issues with DRC violations in my chip design after routing. How can I trace these violations using OpenROAD's GUI?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_22"], "reference_content": ["id:flow-scripts-tutorial_22\n## OpenROAD GUI\n### DRC Viewer\n\nYou can use the GUI to trace DRC violations and fix them.\n\nView DRC violations post routing:\n\n```shell\nless ./reports/sky130hd/ibex/base/5_route_drc.rpt\n```\n\nAny DRC violations are logged in the `5_route_drc.rpt` file, which is\nempty otherwise.\n\nFrom OpenROAD GUI, Enable the menu options `Windows` -> `DRC Viewer`. A\n`DRC viewer` window is added on the right side (RHS) of the GUI. From\n`DRC Viewer` -> `Load` navigate to `5_route_drc.rpt`\n\n\nBy selecting DRC violation details, designers can analyze and fix them. Here\nuser will learn how a DRC violation can be traced with the `gcd` design. Refer\nto the following OpenROAD test case for more details.\n\n```shell\ncd ./flow/tutorials/scripts/drt/\nopenroad -gui\n```\n\nIn the `Tcl Commands` section of GUI:\n\n```tcl\nsource drc_issue.tcl\n```\n\nPost detail routing in the log, you can find the number of violations left\nin the design:\n\n```\n[INFO DRT-0199] Number of violations = 7.\n```\n\nBased on `DRC Viewer` steps load `results/5_route_drc.rpt`. GUI as\nfollows\n\n\n`X mark` in the design highlights DRC violations.\n\nFrom `DRC Viewer` on RHS `expand` -> `Short`\n\nThis shows the number of `violations` in the design. Zoom the design\nfor a clean view of the violation:\n\n\n`output53` has overlaps and this causes the `short violation`.\n\nOpen the input DEF file `drc_cts.def` to check the source of the\noverlap.\n\nNote the snippet of DEF file where `output51` and `output53` have\nthe same placed coordinates and hence cause the placement violation.\n\n```\n- output51 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 267260 136000 ) N ;\n- output53 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 267260 136000 ) N ;\n```\n\nUse the test case provided in `4_cts.def` with the changes applied for\nupdated coordinates as follows:\n\n```\n- output51 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 267260 136000 ) N ;\n- output53 sky130_fd_sc_hd__clkbuf_1 + PLACED ( 124660 266560 ) N ;\n```\n\nClose the current GUI and re-load the GUI with the updated DEF to see\nfixed DRC violation in the design:\n\n```shell\nopenroad -gui\nsource drc_fix.tcl\n```\n\nIn the post detail routing log, the user can find the number of violations\nleft in the design:\n\n```\n[INFO DRT-0199] Number of violations = 0.\n```\n\nRouting completed with 0 violations.\n\n"], "answer": " You can use OpenROAD GUI's DRC Viewer to trace and fix DRC violations post-routing. First, navigate to the route report file `5_route_drc.rpt`. For example, in the command-line:\\n\\n```shell\\nless ./reports/sky130hd/ibex/base/5_route_drc.rpt\\n```\\n\\nIn OpenROAD GUI, enable the DRC Viewer: `Windows -> DRC Viewer`. Then load the `5_route_drc.rpt` file into the DRC Viewer. You can then trace your DRC violations and manually fix them. DRC violation for example, a `Short`, can be viewed by expanding the respective DRC violation in the DRC Viewer window. \\n\\nFor an overlap causing the `short violation`,you can alter the coordinates of the overlapping cells to fix the DRC violation, an example of this is the snippet of DEF file where `output51` and `output53` have the same placed coordinates.\\n\\n\n"}
{"id": 76, "type": "functionality", "question": " An engineer encounters setup timing violations in the synthesized design. The first few attempts at using repair_timing have been unsuccessful. He assumes the design's clock frequency may be too high. He wants to confirm this and fix the violation in an interactive mode. How should he proceed?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_40"], "reference_content": ["id:flow-scripts-tutorial_40\n\n### Timing Optimizations\n\n#### Fixing Setup Violations\n\nTo fix setup timing path violations, use `repair_timing -setup.`\n\nRefer to the following built-in example to learn more about fixing setup\ntiming violations.\n\nRefer to the built-in example [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/rsz/test/repair_setup4.tcl).\n\nLaunch OpenROAD in an interactive mode by running the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/rsz/test/\nopenroad\n```\n\nCopy and paste the following Tcl commands.\n\n```tcl\ndefine_corners fast slow\nread_liberty -corner slow Nangate45/Nangate45_slow.lib\nread_liberty -corner fast Nangate45/Nangate45_fast.lib\nread_lef Nangate45/Nangate45.lef\nread_def repair_setup1.def\ncreate_clock -period 0.3 clk\nset_wire_rc -layer metal3\nestimate_parasitics -placement\nreport_checks -fields input -digits 3\n```\n\nView the generated timing report with the slack violation.\n\n```\nStartpoint: r1 (rising edge-triggered flip-flop clocked by clk)\nEndpoint: r2 (rising edge-triggered flip-flop clocked by clk)\nPath Group: clk\nPath Type: max\nCorner: slow\n\n   Delay     Time   Description\n-----------------------------------------------------------\n   0.000    0.000   clock clk (rise edge)\n   0.000    0.000   clock network delay (ideal)\n   0.000    0.000 ^ r1/CK (DFF_X1)\n   0.835    0.835 ^ r1/Q (DFF_X1)\n   0.001    0.836 ^ u1/A (BUF_X1)\n   0.196    1.032 ^ u1/Z (BUF_X1)\n   0.001    1.033 ^ u2/A (BUF_X1)\n   0.121    1.154 ^ u2/Z (BUF_X1)\n   0.001    1.155 ^ u3/A (BUF_X1)\n   0.118    1.273 ^ u3/Z (BUF_X1)\n   0.001    1.275 ^ u4/A (BUF_X1)\n   0.118    1.393 ^ u4/Z (BUF_X1)\n   0.001    1.394 ^ u5/A (BUF_X1)\n   0.367    1.761 ^ u5/Z (BUF_X1)\n   0.048    1.809 ^ r2/D (DFF_X1)\n            1.809   data arrival time\n\n   0.300    0.300   clock clk (rise edge)\n   0.000    0.300   clock network delay (ideal)\n   0.000    0.300   clock reconvergence pessimism\n            0.300 ^ r2/CK (DFF_X1)\n  -0.155    0.145   library setup time\n            0.145   data required time\n-----------------------------------------------------------\n            0.145   data required time\n           -1.809   data arrival time\n-----------------------------------------------------------\n           -1.664   slack (VIOLATED)\n\n```\n\nFix setup violation using:\n\n```tcl\nrepair_timing -setup\n```\n\nThe log is as follows:\n\n```\n[INFO RSZ-0040] Inserted 4 buffers.\n[INFO RSZ-0041] Resized 16 instances.\n[WARNING RSZ-0062] Unable to repair all setup violations.\n```\n\nReduce the clock frequency by increasing the clock period to `0.9` and re-run\n`repair_timing` to fix the setup violation warnings. Such timing violations\nare automatically fixed by the `resizer` `post CTS` and `global routing.`\n\n```yvl\ncreate_clock -period 0.9 clk\nrepair_timing -setup\n```\n\nTo view timing logs post-repair timing, type:\n\n```tcl\nreport_checks -fields input -digits 3\n```\n\nThe log is as follows:\n\n```\nStartpoint: r1 (rising edge-triggered flip-flop clocked by clk)\nEndpoint: r2 (rising edge-triggered flip-flop clocked by clk)\nPath Group: clk\nPath Type: max\nCorner: slow\n\n   Delay     Time   Description\n-----------------------------------------------------------\n   0.000    0.000   clock clk (rise edge)\n   0.000    0.000   clock network delay (ideal)\n   0.000    0.000 ^ r1/CK (DFF_X1)\n   0.264    0.264 v r1/Q (DFF_X1)\n   0.002    0.266 v u1/A (BUF_X4)\n   0.090    0.356 v u1/Z (BUF_X4)\n   0.003    0.359 v u2/A (BUF_X8)\n   0.076    0.435 v u2/Z (BUF_X8)\n   0.003    0.438 v u3/A (BUF_X8)\n   0.074    0.512 v u3/Z (BUF_X8)\n   0.003    0.515 v u4/A (BUF_X8)\n   0.077    0.592 v u4/Z (BUF_X8)\n   0.005    0.597 v u5/A (BUF_X16)\n   0.077    0.674 v u5/Z (BUF_X16)\n   0.036    0.710 v r2/D (DFF_X1)\n            0.710   data arrival time\n\n   0.900    0.900   clock clk (rise edge)\n   0.000    0.900   clock network delay (ideal)\n   0.000    0.900   clock reconvergence pessimism\n            0.900 ^ r2/CK (DFF_X1)\n  -0.172    0.728   library setup time\n            0.728   data required time\n-----------------------------------------------------------\n            0.728   data required time\n           -0.710   data arrival time\n-----------------------------------------------------------\n            0.019   slack (MET)\n```\n\n"], "answer": " Firstly, the engineer would need to increase the clock period. This can be done with the `create_clock` command followed by the `-period` switch. The value provided to the `-period` switch determines the clock frequency for the design. A higher value for the `-period` switch would result in a lower clock frequency.\\n\\nNext, the `repair_timing` command should be issued with the `-setup` switch to instruct OpenROAD to attempt to fix setup timing violations.\\n\\nAfter this, the `report_checks` command should be used to generate a timing report. This report will be helpful in confirming if the violation was fixed successfully.\\n\\n\n"}
{"id": 77, "type": "functionality", "question": " How can I use OpenROAD to perform pin placement with a few custom requirements: placing the pins at a minimum distance of 15 microns, excluding a region, and grouping certain pins together while ensuring that the pin placement is random?\n", "ref_num": 1, "reference": ["pin_placement_9"], "reference_content": ["id:pin_placement_9\n### Place All Pins\n\nUse the following command to perform pin placement:\n\n```tcl\nplace_pins \n    -hor_layers h_layers\n    -ver_layers v_layers\n    [-random_seed seed]\n    [-random]\n    [-corner_avoidance length]\n    [-min_distance distance]\n    [-min_distance_in_tracks]\n    [-exclude region]\n    [-group_pins pin_list]\n    [-annealing]\n    [-write_pin_placement file_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-hor_layers` | The layers to create the metal shapes of pins placed in horizontal tracks. It can be a single layer or a list of layer names. |\n| `-ver_layers` | The layers to create the metal shapes of pins placed in vertical tracks. It can be a single layer or a list of layer names. |\n| `-corner_avoidance` | The distance (in microns) from each corner within which pin placement should be avoided. |\n| `-min_distance` | The minimum distance between pins on the die boundary. This distance can be in microns (default) or in number of tracks between each pin. |\n| `-min_distance_in_tracks` | Flag that allows setting the min distance in number of tracks instead of microns. |\n| `-exclude` | A region where pins cannot be placed. Either `top|bottom|left|right:edge_interval`, which is the edge interval from the selected edge; `begin:end` for begin-end of all edges. |\n| `-group_pins` | A list of pins to be placed together on the die boundary. |\n| `-annealing` | Flag to enable simulated annealing pin placement. |\n| `-write_pin_placement` | A file with the pin placement generated in the format of multiple calls for the `place_pin` command. |\n\nThe `exclude` option syntax is `-exclude edge:interval`. The `edge` values are\n(top|bottom|left|right). The `interval` can be the whole edge, with the `*`\nvalue, or a range of values. For example, in `place_pins -hor_layers metal2\n-ver_layers metal3 -exclude top:* -exclude right:15-60.5 -exclude left:*-50`\nthree intervals are excluded: the whole top edge, the right edge from 15\nmicrons to 60.5 microns, and the left edge from its beginning to 50 microns.\n\n#### Developer Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-random_seed` | Specify the seed for random operations. |\n| `-random` | When this flag is enabled, the pin placement is random. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The `place_pins` command is used for pin placement in OpenROAD, and its several options can be utilized to customize how the pins are placed. \\n\\nTo randomly place the pins at a minimum distance of 15 microns, you can use the command:\\n```tcl\\nplace_pins -hor_layers h_layers -ver_layers v_layers -min_distance 15 -random\\n```\\nThe `h_layers` and `v_layers` parameters represent the layers to create the metal shapes of pins placed in horizontal tracks and vertical tracks, respectively. The `-random` switch enables random placement of pins.\\n\\nTo exclude a region, the `-exclude` option can be used. Here's an example:\\n```tcl\\nplace_pins -hor_layers h_layers -ver_layers v_layers -exclude top:*-50\\n```\\nThe above command would exclude the top edge from its beginning to 50 microns.\\n\\nTo group certain pins together, you can use the `-group_pins` option and provide a list of pins as its argument. Here's an example:\\n```tcl\\nplace_pins -hor_layers h_layers -ver_layers v_layers -group_pins {pin1 pin2 pin3}\\n```\\nThe above command would ensure that pin1, pin2, and pin3 are placed together on the die boundary.\\n\\n\n"}
{"id": 78, "type": "functionality", "question": " How to run the global placement on CPU?\n", "ref_num": 1, "reference": ["global_placement_1"], "reference_content": ["id:global_placement_1\n### Global Placement\n\nWhen using the `-timing_driven` flag, `gpl` does a virtual `repair_design` \nto find slacks and\nweight nets with low slack. It adjusts the worst slacks (modified with \n`-timing_driven_nets_percentage`) using a multiplier (modified with \n`-timing_driven_net_weight_max`). The multiplier\nis scaled from the full value for the worst slack, to 1.0 at the\n`timing_driven_nets_percentage` point. Use the `set_wire_rc` command to set\nresistance and capacitance of estimated wires used for timing.\n\n```\nglobal_placement\n    [-timing_driven]\n    [-routability_driven]\n    [-skip_initial_place]\n    [-incremental]\n    [-bin_grid_count grid_count]\n    [-density target_density]\n    [-init_density_penalty init_density_penalty]\n    [-init_wirelength_coef init_wirelength_coef]\n    [-min_phi_coef min_phi_conef]\n    [-max_phi_coef max_phi_coef]\n    [-overflow overflow]\n    [-initial_place_max_iter initial_place_max_iter]\n    [-initial_place_max_fanout initial_place_max_fanout]\n    [-pad_left pad_left]\n    [-pad_right pad_right]\n    [-verbose_level level]\n    [-force_cpu]\n    [-skip_io]\n    [-routability_check_overflow routability_check_overflow]\n    [-routability_max_density routability_max_density]\n    [-routability_max_bloat_iter routability_max_bloat_iter]\n    [-routability_max_inflation_iter routability_max_inflation_iter]\n    [-routability_target_rc_metric routability_target_rc_metric]\n    [-routability_inflation_ratio_coef routability_inflation_ratio_coef]\n    [-routability_pitch_scale routability_pitch_scale]\n    [-routability_max_inflation_ratio routability_max_inflation_ratio]\n    [-routability_rc_coefficients routability_rc_coefficients]\n    [-timing_driven_net_reweight_overflow]\n    [-timing_driven_net_weight_max]\n    [-timing_driven_nets_percentage]\n```\n\n#### General Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-timing_driven` | Enable timing-driven mode. See [link](#timing-driven-arguments) for timing-specific arguments. |\n| `-routability_driven` | Enable routability-driven mode. See [link](#routability-driven-arguments) for routability-specific arguments. |\n| `-skip_initial_place` | Skip the initial placement (Biconjugate gradient stabilized, or BiCGSTAB solving) before Nesterov placement. Initial placement improves HPWL by ~5% on large designs. Equivalent to `-initial_place_max_iter 0`. | \n| `-incremental` | Enable the incremental global placement. Users would need to tune other parameters (e.g., `init_density_penalty`) with pre-placed solutions. | \n| `-bin_grid_count` | Set bin grid's counts. The internal heuristic defines the default value. Allowed values are integers `[64,128,256,512,...]`. |\n| `-density` | Set target density. The default value is `0.7` (i.e., 70%). Allowed values are floats `[0, 1]`. |\n| `-init_density_penalty` | Set initial density penalty. The default value is `8e-5`. Allowed values are floats `[1e-6, 1e6]`. |\n| `-init_wirelength_coef` | Set initial wirelength coefficient. The default value is `0.25`. Allowed values are floats. |\n| `-min_phi_coef` | Set `pcof_min` ($\\mu_k$ Lower Bound). The default value is `0.95`. Allowed values are floats `[0.95, 1.05]`. |\n| `-max_phi_coef` | Set `pcof_max` ($\\mu_k$ Upper Bound). Default value is 1.05. Allowed values are `[1.00-1.20, float]`. |\n| `-overflow` | Set target overflow for termination condition. The default value is `0.1`. Allowed values are floats `[0, 1]`. |\n| `-initial_place_max_iter` | Set maximum iterations in the initial place. The default value is 20. Allowed values are integers `[0, MAX_INT]`. |\n| `-initial_place_max_fanout` | Set net escape condition in initial place when $fanout \\geq initial\\_place\\_max\\_fanout$. The default value is 200. Allowed values are integers `[1, MAX_INT]`. |\n| `-pad_left` | Set left padding in terms of number of sites. The default value is 0, and the allowed values are integers `[1, MAX_INT]` |\n| `-pad_right` | Set right padding in terms of number of sites. The default value is 0, and the allowed values are integers `[1, MAX_INT]` |\n| `-verbose_level` | Set verbose level for `gpl`. The default value is 1. Allowed values are integers `[0, 5]`. |\n| `-force_cpu` | Force to use the CPU solver even if the GPU is available. |\n| `-skip_io` | Flag to ignore the IO ports when computing wirelength during placement. The default value is False, allowed values are boolean. |\n\n#### Routability-Driven Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-routability_check_overflow` | Set overflow threshold for routability mode. The default value is `0.2`, and the allowed values are floats `[0, 1]`. |\n| `-routability_max_density` | Set density threshold for routability mode. The default value is `0.99`, and the allowed values are floats `[0, 1]`. |\n| `-routability_max_bloat_iter` | Set bloat iteration threshold for routability mode. The default value is `1`, and the allowed values are integers `[1, MAX_INT]`.|\n| `-routability_max_inflation_iter` | Set inflation iteration threshold for routability mode. The default value is `4`, and the allowed values are integers `[1, MAX_INT]`. |\n| `-routability_target_rc_metric` | Set target RC metric for routability mode. The default value is `1.25`, and the allowed values are floats. |\n| `-routability_inflation_ratio_coef` | Set inflation ratio coefficient for routability mode. The default value is `2.5`, and the allowed values are floats. |\n| `-routability_max_inflation_ratio` | Set inflation ratio threshold for routability mode. The default value is `2.5`, and the allowed values are floats. |\n| `-routability_rc_coefficients` | Set routability RC coefficients. It comes in the form of a Tcl List `{k1, k2, k3, k4}`. The default value for each coefficient is `{1.0, 1.0, 0.0, 0.0}` respectively, and the allowed values are floats. |\n\n#### Timing-Driven Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-timing_driven_net_reweight_overflow` | Set overflow threshold for timing-driven net reweighting. Allowed value is a Tcl list of integers where each number is `[0, 100]`. |\n| `-timing_driven_net_weight_max` | Set the multiplier for the most timing-critical nets. The default value is `1.9`, and the allowed values are floats. |\n| `-timing_driven_nets_percentage` | Set the reweighted percentage of nets in timing-driven mode. The default value is 10. Allowed values are floats `[0, 100]`. |\n\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " You can enable the option ```force_cpu``` of the command ```global_placement```. Once enabled, the placement will be run on CPU even if the GPU is available.\n"}
{"id": 79, "type": "vlsi_flow", "question": " When I run clock tree synthesis (CTS) on my design, I found some buffers are placed on the macros. How should I adjust the command to avoid the macros to place on the macro?\n", "ref_num": 1, "reference": ["clock_tree_synthesis_2"], "reference_content": ["id:clock_tree_synthesis_2\n### Clock Tree Synthesis\n\n```tcl\nclock_tree_synthesis \n    -buf_list <list_of_buffers>\n    [-root_buf root_buf]\n    [-wire_unit wire_unit]\n    [-clk_nets <list_of_clk_nets>]\n    [-distance_between_buffers]\n    [-branching_point_buffers_distance]\n    [-clustering_exponent]\n    [-clustering_unbalance_ratio]\n    [-sink_clustering_enable]\n    [-sink_clustering_size cluster_size]\n    [-sink_clustering_max_diameter max_diameter]\n    [-balance_levels]\n    [-num_static_layers]\n    [-sink_clustering_buffer]\n    [-use_dummy_load]\n    [-insertion_delay]\n    [-sink_buffer_max_cap_derate derate_value]\n    [-delay_buffer_derate derate_value]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-buf_list` | Tcl list of master cells (buffers) that will be considered when making the wire segments (e.g. `{BUFXX, BUFYY}`). |\n| `-root_buffer` | The master cell of the buffer that serves as root for the clock tree. If this parameter is omitted, the first master cell from `-buf_list` is taken. |\n| `-wire_unit` | Minimum unit distance between buffers for a specific wire. If this parameter is omitted, the code gets the value from ten times the height of `-root_buffer`. |\n| `-clk_nets` | String containing the names of the clock roots. If this parameter is omitted, `cts` automatically looks for the clock roots automatically. |\n| `-distance_between_buffers` | Distance (in microns) between buffers that `cts` should use when creating the tree. When using this parameter, the clock tree algorithm is simplified and only uses a fraction of the segments from the LUT. |\n| `-branching_point_buffers_distance` | Distance (in microns) that a branch has to have in order for a buffer to be inserted on a branch end-point. This requires the `-distance_between_buffers` value to be set. |\n| `-clustering_exponent` | Value that determines the power used on the difference between sink and means on the CKMeans clustering algorithm. The default value is `4`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-clustering_unbalance_ratio` | Value determines each cluster's maximum capacity during CKMeans. A value of `0.5` (i.e., 50%) means that each cluster will have exactly half of all sinks for a specific region (half for each branch). The default value is `0.6`, and the allowed values are floats `[0, 1.0]`. |\n| `-sink_clustering_enable` | Enables pre-clustering of sinks to create one level of sub-tree before building H-tree. Each cluster is driven by buffer which becomes end point of H-tree structure. |\n| `-sink_clustering_size` | Specifies the maximum number of sinks per cluster. The default value is `20`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-sink_clustering_max_diameter` | Specifies maximum diameter (in microns) of sink cluster. The default value is `50`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-balance_levels` | Attempt to keep a similar number of levels in the clock tree across non-register cells (e.g., clock-gate or inverter). The default value is `False`, and the allowed values are bool. |\n| `-clk_nets` | String containing the names of the clock roots. If this parameter is omitted, `cts` looks for the clock roots automatically. |\n| `-num_static_layers` | Set the number of static layers. The default value is `0`, and the allowed values are integers `[0, MAX_INT]`. |\n| `-sink_clustering_buffer` | Set the sink clustering buffer(s) to be used. |\n| `-obstruction_aware` | Enables obstruction-aware buffering such that clock buffers are not placed on top of blockages or hard macros. This option may reduce legalizer displacement, leading to better latency, skew or timing QoR.  The default value is `False`, and the allowed values are bool. |\n| `-apply_ndr` | Applies 2X spacing non-default rule to all clock nets except leaf-level nets. The default value is `False`. |\n| `-no_insertion_delay` | Don't consider insertion delays in macro timing models in balancing latencies between macro cells and registers. This option prevents construction of separate clock trees for macro cells and registers.  The default value is `False`. |\n| `-use_dummy_load` | Applies dummy buffer or inverter cells at clock tree leaves to balance loads.  The default values is `False`. |\n| `-sink_buffer_max_cap_derate` | Use this option to control automatic buffer selection. To favor strong(weak) drive strength buffers use a small(large) value.  The default value is `0.01`, meaning that buffers are selected by derating max cap limit by 0.01. The value of 1.0 means no derating of max cap limit.  |\n| `-delay_buffer_derate` | This option is used with -insertion_delay option that balances latencies between macro cells and registers by inserting delay buffers.  The default values is `1.0`, meaning all needed delay buffers are inserted.  Value of 0.5 means only half of necessary delay buffers are inserted.  Value of 0.0 means no insertion of delay buffers. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The option ```-obstruction_aware``` of the command ```clock_tree_synthesis``` guarantees that clock buffers are not placed on top of blockages or hard macros. Thus, you can use the following command for CTS:\n"}
{"id": 80, "type": "functionality", "question": " During IR Drop analysis, how can I correctly write spice power grid of a specific net?\n", "ref_num": 1, "reference": ["IR_Drop_analysis_3"], "reference_content": ["id:IR_Drop_analysis_3\n### Write Spice Power Grid\n\n```tcl\nwrite_pg_spice\n    [-vsrc vsrc_file]\n    [-outfile out_file]\n    [-net net_name]\n    [-dx bump_pitch_x]\n    [-dy bump_pitch_y]\n    [-corner corner]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-vsrc` | File to set the location of the power C4 bumps/IO pins. See [Vsrc_aes.loc file](test/Vsrc_aes_vdd.loc) for an example and its [description](doc/Vsrc_description.md). |\n| `-dx`,`-dy` | Set the bump pitch to decide the voltage source location in the absence of a `vsrc` file. The default bump pitch is 140um if neither these arguments nor a `vsrc` file are given. |\n| `-net` | Name of the net to analyze. Must be a power or ground net name. |\n| `-outfile` | Write per-instance voltage written into the file. |\n| `-corner` | Corner to use for analysis. | \n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To write a Spice power grid for a specific net during an IR Drop analysis, you can use the `write_pg_spice` command as follows:\\n\\n```tcl\\nwrite_pg_spice -net net_name\\n```\\nPlease replace `net_name` with the name of the specific net you want to analyze.\\n\\n\n"}
{"id": 81, "type": "vlsi_flow", "question": " I am trying to define the IO sites for my pads using the make_io_sites command. However, I would like to know how offset influences this process and also want to adjust the density of my designs. How do I use the offset and density parameters in OpenROAD to adjust the placement of my design components?\n", "ref_num": 2, "reference": ["flow-scripts-tutorial_34", "chip-level_connections_6"], "reference_content": ["id:flow-scripts-tutorial_34\n\n### Macro or Standard Cell Placement\n\n#### Macro Placement\n\nIn this section, you will explore various placement options for macros\nand standard cells and study the impact on area and timing.\n\nRefer to the following built-in example [here](https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/gpl/test/macro01.tcl)\nto learn about macro placement.\n\nPlacement density impacts how widely standard cells are placed in the\ncore area. To view this in OpenROAD GUI run the following command(s) in the terminal in OpenROAD tool root directory:\n\n```shell\ncd ../tools/OpenROAD/src/gpl/test/\nopenroad -gui\n```\n\nIn the `Tcl Commands` section of GUI\n\nmacro01.tcl:\n```shell\nsource helpers.tcl\nset test_name macro01 \nread_lef ./nangate45.lef\nread_lef ./bp_be_top_macro.lef\nread_def ./$test_name.def\n\nglobal_placement -density 0.7\nset def_file [make_result_file $test_name.def]\nwrite_def $def_file\ndiff_file $def_file $test_name.defok\nsource report_hpwl.tcl\n```\n\n```tcl\nsource macro01.tcl\n```\n\nRead the resulting macro placement with a complete core view:\n\n| <img src=\"./images/macro_place_full_view.webp\" width=450px> | <img src=\"./images/macro_place_close_view.webp\" width=450px> |\n|:--:|:--:|\n| Figure 1: With density 0.7 | Figure 2: Zoomed view of macro and std cell placement|\n\nReduce the placement density and observe the impact on placement, by\nrunning below command in `Tcl Commands` section of GUI:\n\n```tcl\nglobal_placement -density 0.6\n```\n\nRead the resulting macro placement with a complete core view:\n\n| <img src=\"./images/placement_density_06_full.webp\" width=450px> | <img src=\"./images/placement_density_06_zoomed.webp\" width=450px> |\n|:--:|:--:|\n| Figure 1: With density 0.6 | Figure 2: Zoomed view of macro and std cell placement |\n\n", "id:chip-level_connections_6\n### Define IO Rows\n\nDefine an IO site for the pads to be placed into.\n\n```tcl\nmake_io_sites \n    -horizontal_site site\n    -vertical_site site\n    -corner_site site\n    -offset offset\n    [-rotation_horizontal rotation]\n    [-rotation_vertical rotation]\n    [-rotation_corner rotation]\n    [-ring_index index]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-horizontal_site` | Name of the site for the horizontal pads (east and west). |\n| `-vertical_site` | Name of the site for the vertical pads (north and south). |\n| `-corner_site` | Name of the site for the corner cells. |\n| `-offset` | Offset from the die edge to place the rows. |\n| `-rotation_horizontal` | Rotation to apply to the horizontal sites to ensure pads are placed correctly. The default value is `R0`. |\n| `-rotation_vertical` | Rotation to apply to the vertical sites to ensure pads are placed correctly. The default value is `R0`. |\n| `-rotation_corner` | Rotation to apply to the corner sites to ensure pads are placed correctly. The default value is `R0`. |\n| `-ring_index` | Used to specify the index of the ring in case of multiple rings. |\n\nExample usage:\n\n```tcl\nmake_io_sites -horizontal_site IOSITE_H -vertical_site IOSITE_V -corner_site IOSITE_C -offset 35\nmake_io_sites -horizontal_site IOSITE_H -vertical_site IOSITE_V -corner_site IOSITE_C -offset 35 -rotation_horizontal R180\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To adjust the offset of the placement of your IO sites, you can use the `-offset` parameter in the `make_io_sites` command. This will allow you to control the distance from the die edge where the rows are placed. Here is an example usage:\\n\\n```tcl\\nmake_io_sites -horizontal_site IOSITE_H -vertical_site IOSITE_V -corner_site IOSITE_C -offset 35\\n```\\n\\nTo control the density of your design placement, the `-density` parameter in the `global_placement` command can be used. Reducing density means standard cells will be placed more spread out in the core area. For example, you can reduce density by setting it to 0.6:\\n\\n```tcl\\nglobal_placement -density 0.6\\n```\\n\\nBy controlling these two parameters, you can manipulate both the location and density of your design components.\\n\\n\n"}
{"id": 82, "type": "gui&installation&test", "question": " The user must output a screenshot of a semiconductor layout with specific display settings. The requirements include hiding metal1 layer, showing routing tracks, and saving it in a user-defined resolution of 0.5 microns per pixel in a file named layout.png. How can this be achieved using OpenROAD?\n", "ref_num": 1, "reference": ["gui_3"], "reference_content": ["id:gui_3\n### Save screenshot of layout\n\nThis command can be both be used when the GUI is active and not active.\n\n```\nsave_image [-resolution microns_per_pixel]\n           [-area {x0 y0 x1 y1}]\n           [-width width]\n           [-display_option {option value}]\n           filename\n```\n\nOptions description:\n- ``filename`` path to save the image to.\n- ``x0, y0`` first corner of the layout area (in microns) to be saved, default is to save what is visible on the screen unless called when gui is not active and then it selected the whole block.\n- ``x1, y1`` second corner of the layout area (in microns) to be saved, default is to save what is visible on the screen unless called when gui is not active and then it selected the whole block.\n- ``microns_per_pixel`` resolution in microns per pixel to use when saving the image, default will match what the GUI has selected.\n- ``width`` width of the output image in pixels, default will be computed from the resolution. Cannot be used with ``-resolution``.\n- ``option`` specific setting for a display option to show or hide specific elements. For example, to hide metal1 ``-display_option {Layers/metal1 false}``, to show routing tracks ``-display_option {Tracks/Pref true}``, or to show everthing ``-display_option {* true}``.\n\n## Commands\n\n"], "answer": " The user should execute the following command in OpenROAD:\\n```\\nsave_image -resolution 0.5 -display_option {Layers/metal1 false} -display_option {Tracks/Pref true} layout.png\\n```\\n\\n\n"}
{"id": 83, "type": "functionality", "question": " The user has a layout design that involves multiple io constraints and pin shape patterns and wants to start from a clean state. How can they utilize OpenROAD to accomplish this and what would the Tcl command look like?\n", "ref_num": 1, "reference": ["pin_placement_3"], "reference_content": ["id:pin_placement_3\n### Clear IO Pin Constraints\n\nThe `clear_io_pin_constraints` command clears all the previously-defined\nconstraints and pin shape patterns created with `set_io_pin_constraint` or\n`define_pin_shape_pattern`.\n\n```tcl\nclear_io_pin_constraints\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " The user should execute the following command in OpenROAD:\\n```\\nclear_io_pin_constraints\\n```\\n\\n\n"}
{"id": 84, "type": "functionality", "question": " Why are tools like 'grt' and 'rsz' using Flute3 and how can this affect my OpenROAD design flow?\n", "ref_num": 1, "reference": ["flute_0"], "reference_content": ["id:flute_0\n# Flute3\n\nFlute3 is an open-source rectilinear Steiner minimum tree heuristic with\nimprovements made by UFRGS students and James Cherry. This tool is used\nfor the calculation of wirelength in `grt` and `rsz`. \n\nThe version in this repository uses\nCMake and C++ namespace, and has dynamic memory allocation. Flute3 can handle nets with any degree.\n\n"], "answer": " Flute3 is a core underlying tool that is used for the estimation of wirelength during the resizing and global routing processes in OpenROAD. It provides a heuristic to calculate the Steiner minimum tree, which is a graph connecting all the given nodes such that the total wirelength (also known as the sum of edge weights) is minimized.\\n\\nThis is particularly important in VLSI physical design where optimizing the wirelength can lead to better performance in terms of power, area, and timing.\\n\\nThus, the effect of Flute3 on your OpenROAD design flow would be in the optimization of the wirelength during the global routing (grt) and resizing (rsz) processes, which further influences the overall quality of the final design implementation including aspects like area, power, and performance.\\n\\n\n"}
{"id": 85, "type": "gui&installation&test", "question": " How can I view the clock tree of my design, created by synthesis from the OpenROAD flow?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_18"], "reference_content": ["id:flow-scripts-tutorial_18\n## OpenROAD GUI\n### Tracing The Clock Tree\n\nView the synthesized clock tree for `ibex` design:\n-   From the top Toolbar Click `Windows` -> `Clock Tree Viewer`\n\n\nOn RHS, click `Clock Tree Viewer` and top right corner, click\n`Update` to view the synthesized clock tree of your design.\n\nView clock tree structure below, the user needs to disable the metal\n`Layers` section on LHS as shown below.\n\n\nFrom the top Toolbar, click on the `Windows` menu to select/hide different\nview options of Scripting, Display control, etc.\n\n"], "answer": " Launch the OpenROAD GUI by running the following command:\\n```shell\\n    openroad -gui\\n```    \\nContinue by clicking on 'Windows' from the top Toolbar and select 'Clock Tree Viewer'. On the right-hand side, click 'Clock Tree Viewer' and on the top right corner, click 'Update' to view the synthesized clock tree of your design.\\n\n"}
{"id": 86, "type": "vlsi_flow", "question": " While designing the power distribution network in OpenROAD, how can one customize the network's standards and constraints, such as the metal layers used, the width of each metal layer, and limits on the number of rows and columns when adding via arrays?\n", "ref_num": 1, "reference": ["power_distribution_network_generator_14"], "reference_content": ["id:power_distribution_network_generator_14\n# Power Distribution Network Generator\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-net` | The inner net where the power ring exists. |\n| `-outerNet` | The outer net where instances/pins that need to get connected exist. |\n| `-layers` |  The metal layers for vertical stripes within inner power ring. |\n| `-cut_pitch` | Distance between via cuts when the two layers are parallel, e.g., overlapping stdcell rails. (Default:200 200) |\n| `-fixed_vias` | List of fixed vias to be used to form the via stack. |\n| `-max_rows` | Maximum number of rows when adding arrays of vias. (Default:10) |\n| `-max_columns` | Maximum number of columns when adding arrays of vias. (Default:10) |\n| `-metalwidths` | Width for each metal layer. |\n| `-metalspaces` | Spacing of each metal layer. |\n| `-ongrid` | List of intermediate layers in a via stack to snap onto a routing grid. |\n| `-insts` | List of all the instances that contain the pin that needs to get connected with power ring. (Default:nothing) |\n\n"], "answer": " To customize these specific features of the power distribution network, you can utilize the following switches when running the power distribution network generator:\\n\\n1. For specifying the metal layers to be used for vertical stripes, you’d utilize the `-layers` option. You should pass the specific lists of metal layers you want to use in the format `-layers layer1 layer2 ...`\\n\\n2. For setting the width of each metal layer, utilize the `-metalwidths` switch followed by the value for each metal width.\\n\\n3. Maximum numbers of rows and columns when adding arrays of vias can be set using the `-max_rows` and `-max_columns` switches respectively, followed by the value you want to set.\\n\\n\n"}
{"id": 87, "type": "gui&installation&test", "question": " How to create a button in OpenROAD's GUI to load specific LEF files automatically?\n", "ref_num": 1, "reference": ["flow-scripts-tutorial_24"], "reference_content": ["id:flow-scripts-tutorial_24\n\n## OpenROAD GUI\n### Customizing The GUI\n\nCustomize the GUI by creating your own widgets such as menu bars,\ntoolbar buttons, dialog boxes, etc.\n\nRefer to the [GUI](https://openroad.readthedocs.io/en/latest/main/README.html#gui).\n\nCreate `Load_LEF` toolbar button in GUI to automatically load\nspecified `.lef` files.\n\n```shell\nopenroad -gui\n```\n\n\nTo view `load_lef.tcl`, run the command:\n\n```shell\nless ./flow/tutorials/scripts/gui/load_lef.tcl\n```\n\n```tcl\nproc load_lef_sky130 {} {\n    set FLOW_PATH [exec pwd]\n    read_lef $FLOW_PATH/../../../platforms/sky130hd/lef/sky130_fd_sc_hd.tlef\n    read_lef $FLOW_PATH/../../../platforms/sky130hd/lef/sky130_fd_sc_hd_merged.lef\n}\ncreate_toolbar_button -name \"Load_LEF\" -text \"Load_LEF\" -script {load_lef_sky130} -echo\n```\n\nFrom OpenROAD GUI `Tcl commands`:\n\n```tcl\ncd ./flow/tutorials/scripts/gui/\nsource load_lef.tcl\n```\n\n`Load_LEF` toolbar button added as follows:\n\n\n\nFrom Toolbar menus, Click on `Load_LEF.` This loads the specified `sky130`\ntechnology `.tlef` and `merged.lef` file in the current OpenROAD GUI\nas follows:\n\n"], "answer": " To create a custom toolbar button in the GUI to load specific .lef files, first, define a procedure in Tcl that loads the .lef files with the `read_lef` command. The procedure may look like this:\\n\\n```tcl\\nproc load_lef_files {} {\\n    read_lef /path/to/lef_file1.lef\\n    read_lef /path/to/lef_file2.lef\\n    # Add more files as necessary\\n}\\n```\\nNow, add a toolbar button that calls this procedure when pressed with the `create_toolbar_button` command. The -echo flag will print a message in the console whenever the button is pressed:\\n\\n```tcl\\ncreate_toolbar_button -name \\\"Load_LEF\\\" -text \\\"Load_LEF\\\" -script {load_lef_files} -echo\\n```\\nNow, whenever you open OpenROAD and press the `Load_LEF` button, your specified .lef files will automatically be loaded into the program.\\n\n"}
{"id": 88, "type": "vlsi_flow", "question": " How can you perform global placement considering routability and how to compare the parasitics of the design after placement with a reference .spef file?\n", "ref_num": 2, "reference": ["global_placement_1", "parasitics_extraction_5"], "reference_content": ["id:global_placement_1\n### Global Placement\n\nWhen using the `-timing_driven` flag, `gpl` does a virtual `repair_design` \nto find slacks and\nweight nets with low slack. It adjusts the worst slacks (modified with \n`-timing_driven_nets_percentage`) using a multiplier (modified with \n`-timing_driven_net_weight_max`). The multiplier\nis scaled from the full value for the worst slack, to 1.0 at the\n`timing_driven_nets_percentage` point. Use the `set_wire_rc` command to set\nresistance and capacitance of estimated wires used for timing.\n\n```\nglobal_placement\n    [-timing_driven]\n    [-routability_driven]\n    [-skip_initial_place]\n    [-incremental]\n    [-bin_grid_count grid_count]\n    [-density target_density]\n    [-init_density_penalty init_density_penalty]\n    [-init_wirelength_coef init_wirelength_coef]\n    [-min_phi_coef min_phi_conef]\n    [-max_phi_coef max_phi_coef]\n    [-overflow overflow]\n    [-initial_place_max_iter initial_place_max_iter]\n    [-initial_place_max_fanout initial_place_max_fanout]\n    [-pad_left pad_left]\n    [-pad_right pad_right]\n    [-verbose_level level]\n    [-force_cpu]\n    [-skip_io]\n    [-routability_check_overflow routability_check_overflow]\n    [-routability_max_density routability_max_density]\n    [-routability_max_bloat_iter routability_max_bloat_iter]\n    [-routability_max_inflation_iter routability_max_inflation_iter]\n    [-routability_target_rc_metric routability_target_rc_metric]\n    [-routability_inflation_ratio_coef routability_inflation_ratio_coef]\n    [-routability_pitch_scale routability_pitch_scale]\n    [-routability_max_inflation_ratio routability_max_inflation_ratio]\n    [-routability_rc_coefficients routability_rc_coefficients]\n    [-timing_driven_net_reweight_overflow]\n    [-timing_driven_net_weight_max]\n    [-timing_driven_nets_percentage]\n```\n\n#### General Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-timing_driven` | Enable timing-driven mode. See [link](#timing-driven-arguments) for timing-specific arguments. |\n| `-routability_driven` | Enable routability-driven mode. See [link](#routability-driven-arguments) for routability-specific arguments. |\n| `-skip_initial_place` | Skip the initial placement (Biconjugate gradient stabilized, or BiCGSTAB solving) before Nesterov placement. Initial placement improves HPWL by ~5% on large designs. Equivalent to `-initial_place_max_iter 0`. | \n| `-incremental` | Enable the incremental global placement. Users would need to tune other parameters (e.g., `init_density_penalty`) with pre-placed solutions. | \n| `-bin_grid_count` | Set bin grid's counts. The internal heuristic defines the default value. Allowed values are integers `[64,128,256,512,...]`. |\n| `-density` | Set target density. The default value is `0.7` (i.e., 70%). Allowed values are floats `[0, 1]`. |\n| `-init_density_penalty` | Set initial density penalty. The default value is `8e-5`. Allowed values are floats `[1e-6, 1e6]`. |\n| `-init_wirelength_coef` | Set initial wirelength coefficient. The default value is `0.25`. Allowed values are floats. |\n| `-min_phi_coef` | Set `pcof_min` ($\\mu_k$ Lower Bound). The default value is `0.95`. Allowed values are floats `[0.95, 1.05]`. |\n| `-max_phi_coef` | Set `pcof_max` ($\\mu_k$ Upper Bound). Default value is 1.05. Allowed values are `[1.00-1.20, float]`. |\n| `-overflow` | Set target overflow for termination condition. The default value is `0.1`. Allowed values are floats `[0, 1]`. |\n| `-initial_place_max_iter` | Set maximum iterations in the initial place. The default value is 20. Allowed values are integers `[0, MAX_INT]`. |\n| `-initial_place_max_fanout` | Set net escape condition in initial place when $fanout \\geq initial\\_place\\_max\\_fanout$. The default value is 200. Allowed values are integers `[1, MAX_INT]`. |\n| `-pad_left` | Set left padding in terms of number of sites. The default value is 0, and the allowed values are integers `[1, MAX_INT]` |\n| `-pad_right` | Set right padding in terms of number of sites. The default value is 0, and the allowed values are integers `[1, MAX_INT]` |\n| `-verbose_level` | Set verbose level for `gpl`. The default value is 1. Allowed values are integers `[0, 5]`. |\n| `-force_cpu` | Force to use the CPU solver even if the GPU is available. |\n| `-skip_io` | Flag to ignore the IO ports when computing wirelength during placement. The default value is False, allowed values are boolean. |\n\n#### Routability-Driven Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-routability_check_overflow` | Set overflow threshold for routability mode. The default value is `0.2`, and the allowed values are floats `[0, 1]`. |\n| `-routability_max_density` | Set density threshold for routability mode. The default value is `0.99`, and the allowed values are floats `[0, 1]`. |\n| `-routability_max_bloat_iter` | Set bloat iteration threshold for routability mode. The default value is `1`, and the allowed values are integers `[1, MAX_INT]`.|\n| `-routability_max_inflation_iter` | Set inflation iteration threshold for routability mode. The default value is `4`, and the allowed values are integers `[1, MAX_INT]`. |\n| `-routability_target_rc_metric` | Set target RC metric for routability mode. The default value is `1.25`, and the allowed values are floats. |\n| `-routability_inflation_ratio_coef` | Set inflation ratio coefficient for routability mode. The default value is `2.5`, and the allowed values are floats. |\n| `-routability_max_inflation_ratio` | Set inflation ratio threshold for routability mode. The default value is `2.5`, and the allowed values are floats. |\n| `-routability_rc_coefficients` | Set routability RC coefficients. It comes in the form of a Tcl List `{k1, k2, k3, k4}`. The default value for each coefficient is `{1.0, 1.0, 0.0, 0.0}` respectively, and the allowed values are floats. |\n\n#### Timing-Driven Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-timing_driven_net_reweight_overflow` | Set overflow threshold for timing-driven net reweighting. Allowed value is a Tcl list of integers where each number is `[0, 100]`. |\n| `-timing_driven_net_weight_max` | Set the multiplier for the most timing-critical nets. The default value is `1.9`, and the allowed values are floats. |\n| `-timing_driven_nets_percentage` | Set the reweighted percentage of nets in timing-driven mode. The default value is 10. Allowed values are floats `[0, 100]`. |\n\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:parasitics_extraction_5\n### Comparing SPEF files\n\nThe `diff_spef` command compares the parasitics in the reference database `<filename>.spef`.\nThe output of this command is `diff_spef.out`\nand contains the RC numbers from the parasitics in the database and the\n`<filename>.spef`, and the percentage RC difference of the two data.\n\n```tcl\ndiff_spef\n    [-file filename]                \n    [-r_res]\n    [-r_cap]\n    [-r_cc_cap]\n    [-r_conn]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-file` | Path to the input `.spef` filename. |\n| `-r_res` | Read resistance. |\n| `-r_cap` | Read capacitance. |\n| `-r_cc_cap` | Read coupled capacitance. |\n| `r_conn` | Read connections. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " First, perform the global placement considering routability.\\n\\n```tcl\\nglobal_placement\\n     -routability_driven\\n```\\n\\nAfter performing the placement, you can compare the parasitics of your design with a reference .spef file by using the `diff_spef` command.\\n\\n```tcl\\ndiff_spef\\n     -file /path/to/reference.spef\\n```\\n\\nIn the above command, replace `/path/to/reference.spef` with the actual path to your reference .spef file.\\n\\n\n"}
{"id": 89, "type": "vlsi_flow", "question": " How can we define a pattern of power and ground stripes in a single layer, perform pin placement in specific layers, and then remove IO rows to finalize a design when working with OpenROAD?\n", "ref_num": 3, "reference": ["power_distribution_network_generator_7", "pin_placement_9", "chip-level_connections_7"], "reference_content": ["id:power_distribution_network_generator_7\n### Add Stripes\n\nDefines a pattern of power and ground stripes in a single layer to be added to a power grid.\n\n```tcl\nadd_pdn_stripe \n    -layer layer_name\n    [-grid grid_name]\n    [-width width_value]\n    [-followpins]\n    [-extend_to_core_ring]\n    [-pitch pitch_value]\n    [-spacing spacing_value]\n    [-offset offset_value]\n    [-starts_with POWER|GROUND]\n    [-extend_to_boundary]\n    [-snap_to_grid]\n    [-number_of_straps count]\n    [-nets list_of_nets]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-layer` | The layer name for these stripes. |\n| `-grid` | The grid to which this stripe definition will be added. (Default: Last grid defined by `define_pdn_grid`). |\n| `-width` | Value for the width of the stripe. |\n| `-followpins` | Indicates that the stripe forms part of the stdcell rails, pitch and spacing are dictated by the stdcell rows, and the `-width` is not needed if it can be determined from the cells. |\n| `-extend_to_core_ring` | Extend the stripes to the core PG ring. |\n| `-pitch` | Value for the distance between each power/ground pair. |\n| `-spacing` | Optional specification of the spacing between power/ground pairs within a single pitch defaults to `pitch / 2`. |\n| `-offset` | Value for the offset of the stripe from the lower left corner of the design core area. |\n| `-starts_with` | Use `POWER` or `GROUND`  for the first placed strap. Defaults to `GROUND`. |\n| `-extend_to_boundary` | Extend the stripes to the boundary of the grid. |\n| `-snap_to_grid` | Snap the stripes to the defined routing grid. |\n| `-number_of_straps` | Number of power/ground pairs to add. |\n| `-nets` | Limit straps to just this list of nets. |\n\nExample usage:\n\n```tcl\nadd_pdn_stripe -grid main_grid -layer metal1 -followpins\nadd_pdn_stripe -grid main_grid -layer metal2 -width 0.17 -followpins\nadd_pdn_stripe -grid main_grid -layer metal4 -width 0.48 -pitch 56.0 -offset 2 -starts_with GROUND\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:pin_placement_9\n### Place All Pins\n\nUse the following command to perform pin placement:\n\n```tcl\nplace_pins \n    -hor_layers h_layers\n    -ver_layers v_layers\n    [-random_seed seed]\n    [-random]\n    [-corner_avoidance length]\n    [-min_distance distance]\n    [-min_distance_in_tracks]\n    [-exclude region]\n    [-group_pins pin_list]\n    [-annealing]\n    [-write_pin_placement file_name]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-hor_layers` | The layers to create the metal shapes of pins placed in horizontal tracks. It can be a single layer or a list of layer names. |\n| `-ver_layers` | The layers to create the metal shapes of pins placed in vertical tracks. It can be a single layer or a list of layer names. |\n| `-corner_avoidance` | The distance (in microns) from each corner within which pin placement should be avoided. |\n| `-min_distance` | The minimum distance between pins on the die boundary. This distance can be in microns (default) or in number of tracks between each pin. |\n| `-min_distance_in_tracks` | Flag that allows setting the min distance in number of tracks instead of microns. |\n| `-exclude` | A region where pins cannot be placed. Either `top|bottom|left|right:edge_interval`, which is the edge interval from the selected edge; `begin:end` for begin-end of all edges. |\n| `-group_pins` | A list of pins to be placed together on the die boundary. |\n| `-annealing` | Flag to enable simulated annealing pin placement. |\n| `-write_pin_placement` | A file with the pin placement generated in the format of multiple calls for the `place_pin` command. |\n\nThe `exclude` option syntax is `-exclude edge:interval`. The `edge` values are\n(top|bottom|left|right). The `interval` can be the whole edge, with the `*`\nvalue, or a range of values. For example, in `place_pins -hor_layers metal2\n-ver_layers metal3 -exclude top:* -exclude right:15-60.5 -exclude left:*-50`\nthree intervals are excluded: the whole top edge, the right edge from 15\nmicrons to 60.5 microns, and the left edge from its beginning to 50 microns.\n\n#### Developer Arguments\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-random_seed` | Specify the seed for random operations. |\n| `-random` | When this flag is enabled, the pin placement is random. |\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n", "id:chip-level_connections_7\n### Remove IO Rows\n\nWhen the padring is complete, the following command can remove the IO rows to avoid causing confusion with the other tools.\n\n```tcl\nremove_io_rows\n```\n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " First, you need to define a pattern for the power and ground stripes. Here is how you can do it:\\n```tcl\\nadd_pdn_stripe \\n    -layer metal1\\n    -grid grid1\\n    -width 0.5\\n    -pitch 1.0\\n    -spacing 0.5\\n    -offset 0.1\\n    -starts_with POWER\\n    -number_of_straps 5\\n```\\nThen, you can place pins on your chip using the `place_pins` command:\\n```tcl\\nplace_pins \\n    -hor_layers metal1\\n    -ver_layers metal2\\n    -random\\n    -min_distance 0.5\\n    -min_distance_in_tracks\\n```\\nAfter you have placed the pins, you can remove the IO rows on your chip with the `remove_io_rows` command:\\n```tcl\\nremove_io_rows\\n```\\n\n"}
{"id": 90, "type": "vlsi_flow", "question": " How can I repair both setup and hold timing violations, and restrict the percentage of paths taken into consideration in the power recovery process using OpenROAD?\n", "ref_num": 1, "reference": ["gate_resizing_10"], "reference_content": ["id:gate_resizing_10\n### Repair Timing\n\nThe `repair_timing` command repairs setup and hold violations.  It\nshould be run after clock tree synthesis with propagated clocks.\nSetup repair is done before hold repair so that hold repair does not\ncause setup checks to fail.\n\nThe worst setup path is always repaired.  Next, violating paths to\nendpoints are repaired to reduced the total negative slack. \n\n```tcl\nrepair_timing \n    [-setup]\n    [-hold]\n    [-recover_power percent_of_paths_with_slack]\n    [-setup_margin setup_margin]\n    [-hold_margin hold_margin]\n    [-allow_setup_violations]\n    [-skip_pin_swap]\n    [-skip_gate_cloning]\n    [-repair_tns tns_end_percent]\n    [-max_utilization util]\n    [-max_buffer_percent buffer_percent]\n    [-verbose]\n```\n\n#### Options\n\n| Switch Name | Description |\n| ----- | ----- |\n| `-setup` | Repair setup timing. |\n| `-hold` | Repair hold timing. |\n| `-recover_power` | Set the percentage of paths to recover power for. The default value is `0`, and the allowed values are floats `(0, 100]`. |\n| `-setup_margin` | Add additional setup slack margin. |\n| `-hold_margin` | Add additional hold slack margin. |\n| `-allow_setup_violations` | While repairing hold violations, buffers are not inserted that will cause setup violations unless `-allow_setup_violations` is specified. |\n| `-skip_pin_swap` | Flag to skip pin swap. The default value is `False`, and the allowed values are bools. |\n| `-skip_gate_cloning` | Flag to skip gate cloning. The default value is `False`, and the allowed values are bools. |\n| `-repair_tns` | Percentage of violating endpoints to repair (0-100). When `tns_end_percent` is zero (the default), only the worst endpoint is repaired. When `tns_end_percent` is 100, all violating endpoints are repaired. |\n| `-max_utilization` | Defines the percentage of core area used. |\n| `-max_buffer_percent` | Specify a maximum number of buffers to insert to repair hold violations as a percentage of the number of instances in the design. The default value is `20`, and the allowed values are integers `[0, 100]`. |\n| `-verbose` | Enable verbose logging of the repair progress. |\n\nUse`-recover_power` to specify the percent of paths with positive slack which\nwill be considered for gate resizing to save power. It is recommended that\nthis option be used with global routing based parasitics. \n\n## Commands\n\n```{note}\n- Parameters in square brackets `[-param param]` are optional.\n- Parameters without square brackets `-param2 param2` are required.\n```\n\n"], "answer": " To repair setup and hold violations while limiting the percentage of paths considered in the power recovery process, you can use the `repair_timing` command as follows:\\n\\n```tcl\\nrepair_timing -setup -hold -recover_power 70\\n```\\nIn this command, `-setup` and `-hold` options instruct OpenROAD to repair setup and hold timing violations respectively, while `-recover_power 70` bounds the power recovery process to only 70% of paths with positive slack.\\n\\n\n"}