Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Use percent of minimum clock period

オープン
  • 何か問題がありますか？
#4,583 コメント 7 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@migueldalberto がすでに取り組んでいます。

2026年9月30日 から。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
55/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
領域
performance

調査の方向性

Start with the linked pull request and comment, then trace where the cts__timing__setup__ws metric and its percent delta are calculated. Update the calculation to use the minimum clock period instead of WNS, and verify that the resulting metric table reports the intended percentage.

索引モデルが issue の本文から書いたものです。

説明

Description

Worst negative slack (WNS) is a poor number to compare runs by. It mystifies more often than it explains:

  1. Percent of a small number. make metadata rules compare WNS by percent, so a few picoseconds read as a large change. From #4580 (comment):

    Metric target base delta limit band
    cts__timing__setup__ws -0.624158 -0.518657 20.34 % -0.618657 PeriodPadding 5.0 %

  2. WNS measures the SDC, not the tool. WNS covers every path group, including in2reg, reg2out and in2out paths whose constraints are often approximate, such as set_output_delay [expr $clk_period * 0.2]. In OpenROAD's repair_setup_parallel_eval_default_sequence test (gcd, asap7, 220 ps; the setup-repair stack The-OpenROAD-Project/OpenROAD#11794 … The-OpenROAD-Project/OpenROAD#11805), the worst endpoint for the whole run is the output resp_msg[13]. Its required time comes from that arbitrary 44 ps, so the repair's effect on the design never shows in WNS.

  3. TNS has the same small-number problem. The clock period is chosen so WNS ends up slightly negative, so TNS sums only the few endpoints that fail: two in the gcd test by the end. It swings from case to case. If the failing paths are ones a change can't fix, its effect on everything else stays hidden.

  4. On a large design, WNS ranks changes the wrong way. On XiangShan's tile (asap7, about 2.7 M instances, at global route; The-OpenROAD-Project/bazel-orfs#1356), against a 2,000 ps target:

    Change Worst path Endpoints ≥ 2,000 ps Excess over 2,000 ps
    control 2,504 ps 5,259 733 ns
    placement cohesion 2,524 ps 4,336 548 ns
    cohesion + a logic cut 2,419 ps 5,741 763 ns

    By the worst path, the second change looks worse and the third looks best. By the endpoints that fail, it's the other way round. The SDC there also asks 473 ps, so nearly every endpoint violates and TNS against it says nothing.

Suggested Solution

  1. Compare by the minimum reg2reg clock period: the clock period minus the reg2reg worst slack, in percent of that period, not of WNS. It's the same idea as timing__fmax, which @maliberty pointed out is already reported, but restricted to register-to-register paths: those are the paths the flow can close, while the other groups' constraints are often guesses.

    Measuring reg2reg only also takes the SDC's accuracy out of the question.

    • ORFS's .sdc files often constrain IO with rough budgets, such as 0.2 × the period. With a reg2reg metric those budgets stop mattering for the comparison, which makes the SDCs easier to maintain. Measuring reg2reg alone is fine for tracking the tools.
    • set_input_delay and set_output_delay still deserve targeted tests of their own, especially where a flow repairs hold heavily on purpose.
    • An accidental set_input_delay hold buffer infestation probably deserves an error message in OpenROAD, with an explicit override for designs that mean it. That's where an input delay's min value leaves the input paths with hold violations nobody intended, and hold repair fills the design with delay buffers.

  2. For A/B comparisons, look at more than one path: the reg2reg endpoints within a band around the period, before and after; how many improved and by how much, and how many got worse. The profiler in The-OpenROAD-Project/OpenROAD#11796 already records WNS/TNS trajectories and failing endpoint counts, and looks like a natural place for that per-endpoint view.

  3. Optionally, a floor to read the period against: the one-flop-loop floor, the worst path from a register back to itself. No clock skew or retiming can beat it, so when the period sits at the floor, only that loop's wire, cells or logic can help. On XiangShan's tile it's 2,151 ps, above the 2,000 ps target, which no tuning of the flow could have revealed by WNS alone (bazel-orfs#1356).

Additional Context

The reg2reg-only point matters for designs whose IO constraints are budgets, not real requirements. In theory there could be designs with no reg2reg paths, and those would need a fallback.

主要言語
Verilog
スター
767
フォーク
544
平均マージ
2日 3時間
マージ済み PR（30日）
96

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

The-OpenROAD-Project/OpenROAD-flow-scripts のほかの issue

The-OpenROAD-Project/OpenROAD-flow-scripts の issue をすべて見る

似ている issue

Performance の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。