[Tracker] Handshake-to-HW lowering

[mortbopet]

This issue intends to track the progress on completing the handshake-to-hw lowering, and by doing so, transition off of our current FIRRTL-based lowering path.

The

• [x] implement top-level lowering c7c07659335580fc531ac58e840be056b8c8fcd8
• [ ] Implement generic handshake operations
  • These are your unit-rate actors, muxes, ... - we should have all of the capabilities needed in hw, comb to elaborate these operations.
• [ ] Determine a memory abstraction
  • FIRRTL provides a memory operation that greatly simplifies lowering memories in the current flow. The seq dialect does not yet have such memory abstraction. To transition, we therefore need to figure out whether to implement first-class support in the seq dialect, or if some other route is needed.
• [ ] Determine a top-level memory interface
  • In this new lowering flow, all ground types (data signals) are modeled using ESI channels (ready, valid, data signals). This leaves us with the question of how to expose a memory connection at the top-level (and internally, in the hardware module). Designing around ESI interfaces ideally allows us to compose different hardware modules, and so we'd equally want a memory interface abstraction from ESI.

[mikeurbach]

Regarding generate, I understand the desire to use this functionality, but it seems that will require more thinking. Is it possible to alleviate some of the pain with helpers in C++? Rather than defining generate features in the IR, how hard would it be to have builder methods for each Handshake component that are generic w.r.t. their input/output types at the C++ level?

I'm all for defining generate at the HW level, but this seems like it will require design discussions etc. to get right, and it might be quicker to make progress on Handshake to HW without it.

[teqdruid]

You could add it to the handshake dialect and see how it goes... That's the general recommendation for anything controversial.

On Thu, Mar 3, 2022, 6:08 PM Mike Urbach @.***> wrote:

Regarding generate, I understand the desire to use this functionality, but it seems that will require more thinking. Is it possible to alleviate some of the pain with helpers in C++? Rather than defining generate features in the IR, how hard would it be to have builder methods for each Handshake component that are generic w.r.t. their input/output types at the C++ level?

I'm all for defining generate at the HW level, but this seems like it will require design discussions etc. to get right, and it might be quicker to make progress on Handshake to HW without it.

— Reply to this email directly, view it on GitHub https://github.com/llvm/circt/issues/2704#issuecomment-1058270784, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALNXYA27AWEZXOVCBP47SLU6DWXVANCNFSM5PUBS63Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mortbopet]

Regarding generate, I understand the desire to use this functionality, but it seems that will require more thinking. Is it possible to alleviate some of the pain with helpers in C++? Rather than defining generate features in the IR, how hard would it be to have builder methods for each Handshake component that are generic w.r.t. their input/output types at the C++ level?

Unless I'm misunderstanding your proposal, I don't think such a solution would look that much different than what we already have today in handshake-to-firrtl.

I'll be experimenting a bit with this generate concept locally and present my thoughts/findings at a later ODM. Alongside this, it's exposing quite a bit of missing stuff from the current state of parametric modules which nevertheless should be good contributions.

[mikeurbach]

I don't think such a solution would look that much different than what we already have today in handshake-to-firrtl

That is correct. I'm excited to see what you uncover by pushing on this.