Implementable resource binding

The synthesis algorithm explores the different possible resource binding alternatives by iterating these three tasks. We describe now Hebe s formulation of the design space, and how it is explored in obtaining a desired implementation. 

Formulating the Design Space. More specifically, a resource pool is a set of hardware resources (e.g. implementations of models) with an upper-bound on the number of instances of each type of hardware resources that the user allows in the final implementation. A resource binding is a matching of the operations (i.e. the vertices of the sequencing graph) to specific resources in the... 

A procedure or function model may be called by another model. The call indicates a request to execute the functionality defined by the called model, which is implemented by a particular instance of the hardware block corresponding to the invoked model. Therefcxe, from the standpoint of synthesis, a hardware resource is a model that can be shared in the hardware implementation. Resource sharing in high-level synthesis can be constrained by explicitly binding a call to a specific instance of the implementation. 

With the design space formulated as a set of resource bindings for a given resource allocation, Hebe explores the design space to find a favorable implementation with respect to a particular design goal, such as minimal area ot minimal latency. Any valid implementation must satisfy both resource and timing constraints. 

A resource binding is valid if it is possible to resolve its resource conflicts and still satisfy the required timing constraints. For a given resource binding recall that an instance operation set 0(t,i) of 0 is a subset of vertices that are bound to an allocated resource instance (t, t). Obviously, resource conflicts will occur if the vertices in 0( t,i) can execute in parallel. An implementable binding is defined as follows. 

There are two types of model calls hardware-unbound and hardware-bound calls. A hardware-unbound call is a call where the particular instance of the called model used to implement the call is not specified. The synthesis system has the freedom to implement multiple hardware-unbound calls with one or more hardware resources. In some cases, however, the designer may wish to invoke a specific instance of the called model in the final implementation. This can be achieved by explicitly declaring an instance of the called model, similar to variable declarations. This hardware-bound call then invokes the declared instance of the model by binding the call in the resulting hardware. 

HardwareC supports two categories of design constraints timing and resource constraints. Timing constraints define upper and lower bounds on the time separation between operations. Resource constraints specify the number of resource components available, and partially bind calls to specific instances in the hardware implementation. The designer can also imbed arbitrary constraints in the description. This capability allows the designer to convey information that may be used by later synthesis steps. 

---