Games / Command flash cards / OpenROAD flow commands / Design reports and checks

Design reports and checks

Each card shows a command to explain. A missed card returns later in the round and starts the schedule over. A card answered correctly moves up the schedule and next appears after 1, 3, 7, then 21 days. Keys 1 to 4 choose an option, h shows a hint, and Enter moves on. A hint keeps the card where it is on the schedule. An ordering card is answered by clicking its items in order, and one wrong click ends it. Time values are in nanoseconds. Progress is stored in this browser.

SourceThese cards follow OpenROAD's own commands, checked against the signatures printed by the tool (OpenROAD 26Q3) and the documentation of the module that implements each one. Each answer links to that module's documentation. Commands differ between versions, and commercial tools use different names entirely. Reference: OpenROAD module documentation (OpenROAD on GitHub).
All 8 cards in this section, with answers
  • report_design_area
    Prints the instance area and the core's utilization.

    Hint: Two numbers, and the second is a ratio.

    Utilization is that instance area divided by the core area. It is the number a flow watches across stages, because repair and clock tree synthesis both add cells. OpenROAD reference

  • report_cell_usage
    Prints how many instances of each kind of cell the design contains.

    Hint: It counts, it does not measure.

    The counts show what the flow has been doing: how many buffers were added, how many fillers, how many taps. -stage labels a report so counts from different stages can be compared. OpenROAD reference

  • report_wire_length -global_route -summary
    Prints the total wirelength taken from the global routing result.

    Hint: Wirelength can be counted from an estimate or from the real wires.

    Wirelength is the usual quality measure for placement and routing. -detailed_route counts the finished wires instead, -net limits the report to given nets, and without -summary each net is listed. OpenROAD reference

  • report_floating_nets
    Reports the nets that have no driver.

    Hint: A net needs something at both ends. Ask which end is missing here.

    An undriven net is usually a netlist mistake: a missing connection or logic that was removed. It is checked before placement, because such a net has no meaningful timing. report_overdriven_nets reports the opposite case. OpenROAD reference

  • report_long_wires 10
    Prints the ten longest nets in the design, longest first.

    Hint: The number is a count, not a length.

    The longest nets are where wire delay and slew problems start, so the list is a quick way to find candidates for buffering or for a placement fix. OpenROAD reference

  • report_buffers
    Reports the library buffers that optimization is allowed to use.

    Hint: It concerns the library, not the netlist.

    Usable buffers are the standard-cell buffers left after clock buffers, always-on buffers, level shifters, and cells marked set_dont_use are excluded. Their threshold voltage, site, footprint, and leakage are listed too. -filtered shows the smaller set actually used for rebuffering. OpenROAD reference

  • if {![design_is_routed]} { error "not routed" }
    Returns whether every net is routed, so a script can test it.

    Hint: The square brackets and the if say what kind of command this is.

    Flow scripts use such checks as gates between stages, so a later stage does not run on a design that is not ready. -verbose lists what is missing. OpenROAD reference

  • if {![all_pins_placed]} { place_pins -hor_layers metal3 -ver_layers metal2 }
    Returns whether every I/O (Input/Output) pin has a position yet.

    Hint: Another gate in a script. Ask what it is guarding against.

    Pins may come from the floorplan file or from place_pins. The check lets a script place them only when they are missing, rather than overwriting positions that were given on purpose. OpenROAD reference