Upgrade to Yosys 0.53

[loglav03]

Description

Upgraded Yosys to the latest version 0.53.

Related Issue

Motivation and Context

The current version of Yosys in VTR can't be compile with gcc-15, and there are new features that will require a newer version of Yosys.

How Has This Been Tested?

Ran the required CI tests, fixed run failures, compared QoR results, and updated golden results.

Types of changes

• [ x] Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• [ x] All new and existing tests passed

Summary of QoR:

Tables:
QoR_Tables.zip
Summary_of_tables.xlsx

• VTR Flow Runtime: Generally a slightly faster runtime. Around a 2% to 6% decrease in overall runtime.
• Parmys Synth Time: Significantly faster parmys synth time. Around a 20% to 40% decrease in synth time.
• ABC Synth Time: Slightly faster abc synth time. Around a 2% to 8% decrease in synth time.
• Number of CLBs: Similar or slightly better number of CLBs. Around a 2% decrease in number of CLBs.
• Memory: Almost no change. Less than 1% increase or decrease.
• Number of Pre and Post Packed Blocks: Almost no change. At most 1% increase or decrease.
• Device Grid Tiles: Mostly the same but can slightly differ by a small percentage.
• Pack Time: Slightly faster pack time. Around a 5% to 10% decrease in pack time.
• Place Time: Generally a faster place time. Around a 10% overall decrease in place time.
• Minimum Channel Width: Overall similar min chan width. Fluctuates across all tables (increases and decreases), but averages out to be not much of a difference.
• Routed Wirelength: Similar difference as the minimum channel width.
• Min. Chan. Width Route Time: On average, minimum channel width route time has a 35% increase.
• Crit. Path Routed Wirelength: On average, crit. path routed wirelength has a 7% increase.
• Crit. Path Delay: On average, a 2% decrease in crit. path delay.
• Crit. Path Route Time: On average, a 2% decrease in crit. path route time.

[loglav03]

@vaughnbetz -- Hi Vaughn, not sure if you saw my email with the QoR comparison tables, so I added you here with the tables attached for review. I wanted to check if the results of these QoR are okay to update the golden results.

vtr_strong_soft_multipliers_compare.xlsx
vtr_strong_global_nonuniform_compare.xlsx
vtr_strong_cin_tie_off_compare.xlsx
vtr_reg_basic_no_timing_compare.xlsx
nightly_test3_reg_qor_chain_compare.xlsx

[AlexandreSinger]

How to regenerate golden results:
https://docs.verilogtorouting.org/en/latest/README.developers/#generating-new-qor-golden-result

[vaughnbetz]

The QoR comparisons you posted all look good @loglav03 . Synthesis time is down significantly. On the only test listed with significant size circuits (nightly_test3_reg_qor_chain, which uses the VTR designs) parmys time is down by 33%, ab_synth time is down by 11%, and total flow l runtime is down 7%. pre-packed blocks and post-packed blocks are essentially unchanged, as are CLB count, RAM count and multiplier count, and the final critical path delay and wirelength are changed small amounts and for the better (0.4% less wirelength, .1% critical path delay reduction -- note that the best numbers from these come from "crit_path_routed_wirelength and "critical_path_delay" which use a channel width of 1.3 * Wmin). Individual circuits also look OK from the VTR design suite.

The other smaller circuits tests also all look good.

Go ahead and update any golden results necessary.

The only remaining thing that would be good to see is a QoR comparison on Koios. I'm confident it will be fine given these results, but it's still better to be safe. Please link a spreadsheet here.

In this PR's description it would be good to say what version of yosys or what date of yosys code you are updating to, so we can refer back to it here if needed in the future.

After that, this should be fine to check in.

[AlexandreSinger]

We will need to run and regenerate the NightlyTests as well. These are run once a week and their golden results will also need to be updated.

@AmirhosseinPoolad You currently have a PR open that will slightly change the golden results and you were updating them recently (#3138 ). We cannot merge both of these PRs at the same time since both will change the golden results in different ways. One needs to be merged first, the other rebased and golden results regenerated, and the second merged. How close are you to having that other PR done?

[AlexandreSinger]

Regarding the QoR, it looks good to me. The Parmys synth time for Koios has been grueling, so I am very happy with this update! Overall the results seem fine. Once Amir P's PR that should resolve the issue with the Koios results not being collected properly.

[AmirhosseinPoolad]

@AmirhosseinPoolad You currently have a PR open that will slightly change the golden results and you were updating them recently (#3138 ). We cannot merge both of these PRs at the same time since both will change the golden results in different ways. One needs to be merged first, the other rebased and golden results regenerated, and the second merged. How close are you to having that other PR done?

Merge this one first, that PR still needs around a day of work.

[AmirhosseinPoolad]

On a second thought, let's actually do this, I think it would make the most sense:

1. Merge Change QoR parsing configs to use the fixed channel width variant #3138 without changing nightly test golden results
2. Merge this PR
3. Run the nightly tests
4. Use the artifacts added by Change QoR parsing configs to use the fixed channel width variant #3138 to get new golden results based on that run
5. Do another PR that regenerates all the golden results

The current QoR failures aren't concerning and after discussion with @vaughnbetz we agreed to basically go with a fresh set of golden results. The only issue is nightlytest2 which had an error while parsing QoR. Not entirely sure why.

[AlexandreSinger]

@AmirhosseinPoolad That course of action makes sense to me. Regarding:

The only issue is nightlytest2 which had an error while parsing QoR.

I recommend removing your change then just for the config filesNightlyTest2 before merging your PR!

Are you ok with leading this effort to merge these two PR and regenerate the Golden Results?

[AmirhosseinPoolad]

I recommend removing your change then just for the config filesNightlyTest2 before merging your PR!

Oh sorry if I wasn't super clear, that was on VTR master for last night's tests:
https://github.com/verilog-to-routing/vtr-verilog-to-routing/actions/runs/15659834367/job/44115967870

Check Nightly Test 2. Regarding merging the two PRs and regenerating the results, I will do it.