A kind of implementation constraint for the high-level synthesis is a resource binding constraint. In this case, a particular operation is required to be implemented by a given resource. These constraints are motivated by the designer's previous knowledge, or intuition, that one particular choice is the best and that other choices do not need investigation.

Architectural synthesis with resource binding constraints is often referred to as synthesis from partial structure. Design systems that support such a feature allow a designer to specify a circuit in a wide spectrum of ways, ranging from a full behavioral model to a structural one. This modeling capability may be useful to leverage previously designed components.

When binding constraints are specified, a resource binding must be compatible with them. In particular, a partial binding may be part of the original specification. This corresponds to specifying a binding for a subset of the operations $U\subseteq V_o$ . A resource binding is compatible with a partial binding when its restriction to the operations $U$ is identical to the partial binding itself.

A partial binding is defined as a relation $\beta$ between an operation vertex into the behavioral specification and the functional unit instance where it will have to be executed: $\beta(v_l) = (t,r)$ where $v_l\in V_o$ is an operation of type $l$ to be executed, $t$ is a functional unit that is able to executed the operation type $l$ and $r$ is an integer representing the instance of the functional unit in the design. The following algorithms will accept this information as a constraint, without investigate why it has been imposed.

Binding constraints in the Bambu tool

Once the internal representation has been created and the informations about resources and constraints have been loaded, some additional informations can be added to ensure that operations will be bounded on specific resources. In fact, as described in many books regarding high-level synthesis, the allocation task can be performed before scheduling one and a partial binding can be introduced to partially control the area occupation on the final design.

In Bambu tool, this information can be provided by an XML file, where the binding constraints are specified (see src_frontend_HLS_constraintsIOParser). The information can be represented as follows:

  <constraints>
    <HLS_constraints>
      <binding_constraints vertex_name="simple_add_1_28_38" 
                           fu_name="plus_expr_FU" fu_index="0"/>
      <binding_constraints vertex_name="simple_add_1_28_39" 
                           fu_name="plus_expr_FU" fu_index="0"/>
    </HLS_constraints>
  </constraints>

where simple_add_1_28_38 and simple_add_1_28_39 are both bound to functional unit plus_expr_FU:0. Note that forces the two operations to be executed in different control steps (provided they are not in mutual exclusion), since they can not use the same functional unit in the same control step.

In the mixed high-level synthesis, this information is used for chromosome encoding and it allows to perform design space exploration oriented to optimize the figures of merit and search the best trade-offs between execution time (spreading operations in different functional units, to reduce latency, this leads to increase area occupation) and area occupation (trying to concentrate operations in the same functional units, this could lead to increase latency, as explained above).

Storing binding constraints

This information is so added to the HLS_constraints data structure as additional constraints to be met by the final design. Note that the following steps simply use this datastructure to have informations about binding constraints. In particular, the method HLS_constraints::bind_vertex_to_fu can be used to bind an operation of the behavioral specification to a functional unit. The binding constraints are so stored in the datastructure HLS_constraints::binding_constraints as a map between the operation name (as given by the macro GET_NAME) and a pair of strings representing the library name and the functional unit name.

Therefore, the algorithms will be executed as usual on operations where no constraints have been specified. The algorithms will have the freedom to assign the operations to any admissible and free functional units. At the opposite, if constraints have been imposed, the algorithms will have to satisfy them, since they can be considered as a request formulated by the designer to consider the final design as feasible.