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

Pipeline multiply and other primitives #928

Open
mikeurbach opened this issue Feb 21, 2022 · 3 comments
Open

Pipeline multiply and other primitives #928

mikeurbach opened this issue Feb 21, 2022 · 3 comments
Labels
C: Library Calyx's standard library S: Needs Triage Issue needs some thinking

Comments

@mikeurbach
Copy link
Collaborator

This came up over here: #909 (comment). The multiplier and some of the other non-trivial primitives use multiple stages internally, and it should be possible to pipeline them with II=1. Now that we are starting to push on statically timed pipelines this could yield some nice improvements.

@mikeurbach mikeurbach changed the title Pipeline multiply and other pipelined Pipeline multiply and other primitives Feb 21, 2022
@rachitnigam rachitnigam added C: Library Calyx's standard library S: Needs Triage Issue needs some thinking labels Feb 22, 2022
@rachitnigam
Copy link
Contributor

Outlining an implementation sketch for anyone interested in implementing this. The current [std_mult_pipe][smp] is actually already pipelined internally so that Xilinx tools infer them as DSPs. However, the interface does not expose any way to use the multiplier in a pipelined way because it only implements a one-sided ready-valid interface. To make this work, we can start off with the primitive and expose a proper, double-sided read-valid interface. This new primitive should probably be exposed in a separate library file. Next, we can change the code generation for SCF programs to explicitly model reads and writes to/from the multiplier when generating the pipeline so that they can be pushed into the right stages.

@rachitnigam
Copy link
Contributor

One idea for doing this is using the primitives generated from Filament designs and exposing two ports: One that allow access to the pipelined execution and another one that registers the output. If a design doesn't use the latter, it'll get optimized into a purely pipelined operator

@rachitnigam
Copy link
Contributor

Once we wrap up #1725, we can start working on this. The new interface is flexible enough to allow for modules to be pipelined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Library Calyx's standard library S: Needs Triage Issue needs some thinking
Projects
None yet
Development

No branches or pull requests

2 participants