Skip to content

Generalize Parmys Mult_Split to Allow for Multipliers Whose Input Widths are not Equal #3143

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

WhiteNinjaZ
Copy link
Contributor

Description

This PR fixes issue #2532. Several benchmarks including difeq2.v and mcml.v where failing parmys on the 7-series due to the 7-series DSP blocks having unequal input widths (25x18). This was caused due to parmys assuming that input widths where always equal in its multiplier splitter. This PR removes that assumption and allows for both types of multipliers to be split properly.

How Has This Been Tested?

Several Verilog designs with a variety of multiplier sizes where synthesized onto a modified version of the k6_frac_N10 arch that included multipliers of various sizes and different input widths (i.e. 18x25). The 7series_BRAM_DSP_carry.xml arch was also used for testing.

Types of changes

  • 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
  • All new and existing tests passed

@WhiteNinjaZ WhiteNinjaZ changed the title Generalize Parmys multiplication Generalize Parmys Mult_Split to Allow for Multipliers Whose Input Widths are not Equal Jun 16, 2025
Copy link
Contributor

@AmirhosseinPoolad AmirhosseinPoolad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @WhiteNinjaZ, great fix! I didn't review your code changes in Parmys (Leaving that for someone more experienced in that part of the codebase) but since you added a new circuit to vtr_nightly_test2/vtr_xilinx_qor you should generate golden results for it because it would fail the NightlyTestManual CI test otherwise.

Keep in mind that I'm changing the way the results for this test is being parsed in #3138 so make sure you rebase/merge your changes after that PR is merged and generate golden results on top of the new master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants