Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Use percent of minimum clock period

Đang mở
  • Có gì không ổn?
#4,583 6 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@migueldalberto đang làm issue này rồi.

Từ ngày 30/9/2026.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Lĩnh vực
performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Verilog
Star
767
Fork
544
Merge trung bình
2 ngày 3 giờ
Pull request đã merge (30 ngày)
97

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của The-OpenROAD-Project/OpenROAD-flow-scripts

Tất cả issue của The-OpenROAD-Project/OpenROAD-flow-scripts

Issue tương tự

Thêm issue về Performance

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.