Skip to content
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

Partial Streaming FFTs #415

Open
2 tasks
UnsignedByte opened this issue Feb 22, 2024 · 3 comments
Open
2 tasks

Partial Streaming FFTs #415

UnsignedByte opened this issue Feb 22, 2024 · 3 comments
Assignees
Labels

Comments

@UnsignedByte
Copy link
Collaborator

I will be implementing partial streaming the same way spiral does: Instantiating a set number of stages and reusing them (I.E. a 4 stage FFT using 1 stage total). In this way the latency will be NStages/NInstantiated where NInstantiated is the number of actual butterfly units.

If time permits, I might look into partial streaming FFTs using iterative stages but I'm not sure whether that would be worth it, depends on what design space results we can get.

  • Partial Streaming FFT
  • Iterative Stages in partial streaming (?)
@UnsignedByte UnsignedByte self-assigned this Feb 22, 2024
@rachitnigam
Copy link
Member

Awesome! I think the primary goals are:

  • Matching the throughput of Spiral FFTs
  • Minimizing the use of assume to only "algebraic properties" that Filament's encoding cannot reason about. We have a bunch of assume that actually encode circuit properties that we should get rid of (and implement features needed to get rid of them)

Iterative streaming would be weird because the throughput would be terrible; we already have this problem because we have to flush the butterfly pipelines when doing stage reuse.

@UnsignedByte
Copy link
Collaborator Author

What do you mean by "circuit properties"? Are we talking about the assume statements used to speed up compilation?

@rachitnigam
Copy link
Member

Nope, I mean assumes that state that a particular module's output parameter is equal to one or equal to another output parameter. Those kinds of properties should not be encoded using assume statements.

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

No branches or pull requests

2 participants