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

Add stallable primitives #1935

Merged
merged 3 commits into from
Feb 27, 2024
Merged

Add stallable primitives #1935

merged 3 commits into from
Feb 27, 2024

Conversation

andrewb1999
Copy link
Collaborator

Create a file for stallable primitives and add a stallable multiplier. Stallable primitives are very similar to pipelined primitives but have to ability to stall if an input stall signal is set to 1. When stall is 1, the multiplier will hold all values in inner registers at their current state until the stall value returns to 0. These kinds of primitives are useful for stallable pipelines which can arise when dealing with input dependent dynamic behavior.

I'm adding this as a separate primitives file instead of just changing the pipelined primitives to add a stall signal because in most use cases of pipelined primitives we don't want this signal. It likely could be optimized away by RTL synthesis, but I don't want users to have to think about it if they don't have to.

// A latency-sensitive multiplier that takes 4 cycles to compute its result.
// If stall is set to a value of 1, the multiplier will stall until the value is
// set back to 0.
static<4> primitive stallable_mult[WIDTH] (
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks great! Does this need an enable signal? I'm wondering if there is a way to combine pipelined and stallable implementations by tying stall to zero for the former.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

An enable signal on this kind of thing is kinda meaningless because there can't be a done signal. The only reason to have an enable signal would be to prevent garbage values from being passed through the multiplier in hopes of reducing power utilization. And yes, we could combine these with pipelined primitives by tying the stall signal to zero since RTL synthesis should easily be able to optimize out the stall signal in that case, but I just want to reduce the complexity exposed to the user (i.e. they shouldn't see the stall signal in the interface if they don't need to use it). Any changes to the internal implementation is fine for me as long as this condition of users not seeing the stall signal if they just want to use a regular pipelined primitive holds.

Copy link
Contributor

@rachitnigam rachitnigam left a comment

Choose a reason for hiding this comment

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

Couple of questions! We also need to add these to this file: https://github.com/calyxir/calyx/blob/main/calyx-stdlib/src/primitives.rs

@rachitnigam
Copy link
Contributor

Okay, LGTM! Merge this baby!

@andrewb1999 andrewb1999 merged commit f52e552 into main Feb 27, 2024
7 checks passed
@andrewb1999 andrewb1999 deleted the stallable-prims branch February 27, 2024 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants