Repository navigation
Conversation
What: 16 timing-path cases on asap7, gf180mcu, Nangate45, sky130hd and sky130hs, each run with -phases LEGACY. Why: the golden logs show that the later changes of the setup repair stack leave LEGACY unchanged. How: DEF, SDC and Tcl per case with golden logs; no code change. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
What: remove the experimental MT1, MEASURED_VT_SWAP and LEGACY_MT policies with the MeasuredVtSwap move, turn the RSZ_* environment knobs into fields of a new OptimizationPolicyConfig, and rename the report_delay_estimator_accuracy estimators to legacy and stage_window. Why: PARALLEL_EVAL replaces the MT policies and the delay estimator accuracy report replaces the measured VT swap; a run should not depend on its shell. The estimator names legacy_mt and mt named the removed policies, and stage_window says which model runs. How: the policies, their phase tokens, tests and architecture notes go, with the target prewarm hook that only LEGACY_MT used; the knobs, including the STA slew bias of the delay estimator, are config fields; -estimator accepts legacy and stage_window only. LEGACY results do not change, nor do any results when no RSZ_* variable is set. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
What: repair_timing -setup gains -profile_mode and -profile_dir. Mode 1 records time per stage and WNS/TNS samples, mode 2 adds the moves, journals and database edits; each call writes one run_N directory. Why: to see where setup repair spends its time and how timing moves, without changing the repair. How: RepairSetupProfiler observes hooks in MoveCommitter, Resizer, Rebuffer and the LEGACY, LAST_GASP and CRIT_VT_SWAP policies; the progress table moves into ProgressReporter. Mode 0 changes nothing. Signed-off-by: Jaehyun Kim <jhkim@precisioninno.com>
|
This PR exceeds the recommended size of 1000 lines. Please make sure you are NOT addressing multiple issues with one PR. Note this PR might be rejected due to its size. |
|
Note The number of changes in this pull request is too large for Gemini Code Assist to generate a review. |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b3702e0e1b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Codex looks minor but maybe worth a follow up later |
2 participants
Part 3 of 12 of the PARALLEL_EVAL setup repair stack. It builds on #11795 and also shows the commits of parts 1 to 2; its own change is the last commit.
Summary
repair_timing -setupspends its time and how WNS and TNS move. Mode 0, the default, writes nothing and costs nothing.Changes
repair_timing -setupgains-profile_modeand-profile_dir; each call writes onerun_Ndirectory.stats.csv(time per stage),timing.csv(WNS/TNS samples) andmetadata.csv; mode 2 addsevents.csvwith the candidates, moves, ECO journals and database edits.MoveCommitterreports each apply and journal,ResizerandRebuffertime their parasitics and timing updates, and the LEGACY, LAST_GASP and CRIT_VT_SWAP policies mark their stages, passes and stop reasons.ProgressReporterwith the same output.Stack