Constraints

Constraints

Each component has a set of constraints that are attached to it that affect the mapping and reuse opportunities available to the component. The constraints are expressed in the following format:

- !Component
  constraints:
    spatial: <Spatial constraint dictionary>
    temporal: <Temporal constraint dictionary>
    dataspace: <Dataspace constraint dictionary>

Alternatively, constraints may be expressed in a separate file by using the following format:

constraints:
  version: 0.4
  targets:
  - target: <Name of component>
    type: <Spatial, temporal, or dataspace>
    constraints: <Constraint dictionary>
  - target: <Name of component>
    ...
  - target: <Name of component>
    ...

Spatial AND Temporal Constraints

The following constraints are available and have the same behavior for both spatial and temporal constraints:

  • permutation: An ordered list of rank names that specify the loop order for the component. For example, "permutation: [G, F, E, D, C, B, A]" would indicate that G is the innermost loop and A is the outermost loop.
  • factors: A list of loop factors, each expressed as a string of the form "RANK=FACTOR". For example, "P=12" would indicate that a loop of "for P in [0..12)". Also permitted are inequalities, such as "P<12", "P>12", "P<=12", and "P>=12".
  • factors_only: Like factors, but only the listed factors are applied. All other factors are set to 1.
  • no_iteration_over_dataspaces: A list of dataspaces over which there should be no temporal iteration. There is no iteration over ANY of the listed dataspaces for loops directly below this component. Note that parent and child components may still iterate over these dataspaces.
  • must_iterate_over_dataspaces: A list of dataspaces over which there must be temporal iteration. There must be iteration over ALL of the listed dataspaces for loops directly below this component. Note that parent and child components may still iterate over different dataspaces.
  • maximize_dims: A list-of-lists of ranks that should be maximized when mapping over the component. For example, [[P, Q], [R, S]] would indicate that, if there is capacity and the ranks are large enough, the P and Q ranks should be mapped to their maximum values. If there is leftover fanout after mapping P and Q, the R and S ranks should be maximized. Within each list, earlier elements have precedence if the same fanout can be achieved in multiple ways.

Spatial Constraints

The following spatial constraints are available:

  • no_reuse: A list of dataspaces for which multicast and reduction opportunities (spatial reuse) are disallowed.
  • no_link_transfer: A list of dataspaces for which link transfer opportunities are disallowed.
  • maximize_dims_capacity: The maximum number to which we should maximize ranks. For example, if we set maximize_dims_capacity: 16 and maximize_dims: [[A, B]], and both A and B are set to 8 in the problem, then when maximizing ranks, we will create spatial loops "for A in [0..8)" and "for B in [0..2)", totaling up to our capacity of 16. By default, this is set to the spatial fanout of the component.
  • split: Given a permutation, ranks before the split index are mapped to the spatial X dimension, and ranks after the split index are mapped to the spatial Y dimension. For example, if the permutation is ABCDEF and the split index is 2, then A and B are mapped to spatial X and CDEF are mapped to spatial Y.

Temporal Constraints

The following temporal constraints are available:

  • no_reuse: A list of dataspaces for which temporal reuse opportunities are disallowed. This only affects parent-level loops; child loops may still reuse data from these dataspaces.
  • maximize_dims_capacity: The maximum number to which we should maximize ranks. For example, if we set maximize_dims_capacity: 16 and maximize_dims: [[A, B]], and both A and B are set to 8 in the problem, then when maximizing ranks, we will create temporal loops "for A in [0..8)" and "for B in [0..2)", totaling up to our capacity of 16. This is required for temporal loops if maximize_dims is set.
  • rmw_first_update: Usually, the first "update" of a component is just a write. If this constraint is set, the first update is a read & write.

Dataspace Constraints

The following dataspace constraints are available:

  • no_coalesce: A list of dataspaces for which coalescing opportunities are disallowed. This means that data from these dataspaces cannot be coalesced into a single access to a parent or child component. For example, an adder sums several values, coalescing them into one output (i.e., reusing the output for multiple additions). On the other hand, some networks may not coalesce; if the same piece of data is propagated through multiple times, it must be fetched from backing storage multiple times.
  • bypass: A list of dataspaces which bypass this component. This means that data from these dataspaces is not stored in this component, but is instead directly transferred between the parents/children of this component.
  • keep: A list of dataspaces which are kept in this component. This means that data from these dataspaces is stored in this component, and is not directly transferred between the parents/children of this component. `keep_only: Like keep, but only the listed dataspaces are kept. All other dataspaces are bypassed.