Pipelining

[benreynwar]

Hi all,

I've been enjoying checking out calyx and really like the way it's trying to separate out the control information. The big limiting factor at the moment is the lack of support for pipelining, since although I could write a pipelined design, I'd lose the advantage of the separate control information, since the control description would basically be that every group is always active.

I'm curious what you-all's plans are for supporting pipelineing more elegantly in the future. I've thought a bit about it, and haven't really come to any conclusion except it's probably pretty hard :).

As a concrete example, in Figure 6 of the calyx paper you show the control for a matrix-muliply unit. If I wanted to use this unit to process a stream of matrix multiplications, I'd want to have par{t0;l0;} firing for the second multiplication at the same time as the final use of pe_00 was happening for the first multiplication. Currently I'd have to write a new control sequence to describe this, rather than just saying do the original sequence multiple times, and please pipeline it if you can.

Cheers,
Ben

[sampsyo]

Hi, @benreynwar—awesome! Glad you're having a good time exploring. 😃

As you have certainly inferred, first-class support for pipelines (both statically and dynamically timed) is something we have also talked about a lot (e.g., #200), and it's a high priority for us. (In fact, it just came up again at our weekly meeting this week!) Part of what makes it tricky is that it has deep implications for the group interface semantics that Calyx bakes in.

I'll let others weigh in too, but roughly speaking, these design goals are in play:

• Something roughly like a pipeline control statement that compiles down to lower-level seq & par
• Clear rules for validity, i.e., which resources are safe to use in each pipeline stage
• Support for both fixed-latency pipelines (with statically known IIs) and dynamic/handshaked pipelines (potentially with backpressure)

Anyway, with some of the underlying semantics getting a bit clearer lately, hopefully we're on track to having a more coherent design in the not-too-distant future!

[rachitnigam]

Hey @benreynwar, as Adrian mentioned, pipelining is the next big thing we're tackling in the design of Calyx. I think the central question for us is what is the level of abstraction for pipelines? Is it a magical operator that automatically attempts to pipeline as much as possible or is it some low-level representation that verifies that the pipeline specification is valid and generates hardware. Furthermore, we'd like to keep with Calyx's philosophy of optimization using the control language.

I think in the short-term, we'd like to support a restricted pipelining operator in the spirit of #200. In the long term, we'd like tackle mixing latency-sensitive and latency-insensitive pipelines; supporting one or the other isn't terribly hard but it'd be really cool if we could say something like, "every pipeline is compilable and when you give latency information, we remove a bunch of hardware" (this is currently true of other Calyx operators).

[benreynwar]

Great, thanks for the info (I hadn't seen #200). It's exciting to see this project taking shape!

[rachitnigam]

The implementation of a pipelined MAC unit that can be driven from another components seems like it fits @benreynwar's original specification: #632