Interpreting MILP solution & RTL module selection

[QinYuan2000]

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:

1. Translating MILP results to timing attributes (opacity).
2. Generating HW module based on these timing attributes and slot numbers.

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:

• Buffer types cannot be differentiated simply using timing attributes and slot numbers.
• The handshake-to-HW pass should not make any intelligent choices, yet it does when selecting modules based on timing attributes and slot numbers.
• Splitting buffer module selection into two steps complicates maintenance (e.g., what if someone changed one but forgot the other?).

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.

[QinYuan2000]

Implemented in #317.