Interpreting MILP solution & RTL module selection #269
Closed
QinYuan2000
started this conversation in
Change proposal
Replies: 1 comment
-
|
Implemented in #317. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Interpreting MILP solution & RTL module selection
Introduction
Currently, Dynamatic classifies buffer components as either opaque or transparent, and a single channel may include both types. In the buffer placement pass, MILP solutions map to slot numbers of these two types (①). The opacity is then translated into timing attributes for the Data (D), Valid (V), and Ready (R) signals (②). In the handshake-to-HW pass, these timing attributes and slot numbers are propagated as HW parameters (③), while a JSON file defines how to instantiate buffer HW modules based on these parameters (④).
In this flow, two interpretation steps decide buffer HW module types:
Problem
With new buffer placement algorithms proposed, we introduce a framework in (#228) to support multiple algorithms. Existing RTL instances become insufficient because additional buffer modules and combinations are needed. This leads to several issues:
Solution
In the new framework, available buffer HW modules are explicitly tracked. We plan to treat each basic module as a distinct type in the buffer placement pass, ensuring it cannot be represented by other modules. The only design choice then occurs when translating MILP outputs to the slot number of each basic module type (①), after which all steps are direct mappings. Consequently, timing attributes and slot numbers no longer determine HW module types; slot numbers are simply passed as parameters.
Beta Was this translation helpful? Give feedback.
All reactions