Skip to content

Carry-save-adder circuit generation - #5409

Open
maartenboersma wants to merge 2 commits into
chipsalliance:mainfrom
Aurora7913:carrysave
Open

Carry-save-adder circuit generation#5409
maartenboersma wants to merge 2 commits into
chipsalliance:mainfrom
Aurora7913:carrysave

Conversation

@maartenboersma

Copy link
Copy Markdown
Contributor

Summary

For efficient many-term addition, a tree starting with a carry-save adder is typically a good implementation choice.

Although modern logic synthesizers may automatically select an adder tree implementation, in our experience is it helpful to start synthesis with a netlist that already has the desired structure. It helps not only for the result quality, but also for the result stability.

This pull request introduces a Csa (Carry Save Adder) function to reduce an arbitrary number of UInt input terms to two UInt output terms. The sum of the two output terms is equal to the sum of the input terms.

Release Notes

Addition of a Carry Save Adder function to reduce many input terms to two.

@seldridge seldridge added the Feature New feature, will be included in release notes label Jun 10, 2026
@adkian-sifive

Copy link
Copy Markdown
Member

Please add tests

x.length match {
case 0 => Seq(0.U(0.W))
case 1 => x
case 2 => x

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I am confused by this 2 entry case, shouldn't we be adding them?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I understand your confusion and appreciate your suggestion. Yes we could, and I agree that from an API point-of-view, it is cleaner to return the final sum as single UInt.

I intentionally chose to return the sum in redundant form (as two terms), leaving the final addition to the user. This is more flexible circuit-wise because:

  1. can exploit that the LSB in the second term is constant-zero: if needed, can OR in an additional +1 without significant timing impact.
  2. in high-frequency designs with many input terms, user can choose to insert a pipeline register stage after reduction, before the final adder.
  3. in case more terms are to be added to the result later, it is area-efficient to keep the sum in redundant form as long as possible.

I will think of a way to offer both.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Discussed in Chisel dev. Maybe the public apply method should return a single UInt with a private recursive function (basically what you have here). Then some of these other use cases can be different function names depending on their arguments and return value types. For example if you want to return the two arguments you should return a tuple rather than a Seq (but of course keep the private recursive method using Seqs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature New feature, will be included in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants