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>
...
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.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.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.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.