Behavioral synthesis methodology for HDL-based specification and validation

This paper describes a HDL synthesis based design methodology that supports user adoption of behavioral-level synthesis into normal design practices.The use of these techniques increases understanding of the HDL descriptions before synthesis, and makes the comparison of pre-and post-synthesis design behavior through simulation much more direct.This increases user confidence that the specification does what the user wants, i.e. that the synthesized design matches the specification in the ways that are important to the user.At the same time, the methodology gives the user a powerful set of tools to specify complex interface timing, while preserving a user's ability to delegate decision-making authority to software in those cases where the user does not wish to restrict the options available to the synthesis algorithms. OverviewThis paper describes a synthesis methodology that uses high-level synthesis (HLS) of behavioral hardware-description language (HDL) descriptions.HLS has the distinguishing characteristic that operations are automatically scheduled, i.e. assigned to states, as opposed to lower-level synthesis, in which operations are assigned to states by the user [1, 2, 3].For example, in an HDL description of a square root function, an operand x would be loaded, a series of operations would follow, and a single result r would be returned.The read x and the write r might be fixed to particular states or times by a communication protocol, but the internal operations that compute the square root would be automatically scheduled.A prospective user of HLS will then ask a number of questions.These will likely include the following:• How can I constrain I/O operations to fall into particular cycles, or range of cycles, to meet existing protocols?• How can I constrain I/O operations to have particular timing relationships?For example, how can I constrain a data ready strobe to be synchronous with data on data ports?• How can I be confident that my interface timing specification really works with the surrounding hardware?• How can I give the scheduling software optimization opportunities when my timing specification is not rigid?For example, I might not care exactly when data was transferred, as long as a corresponding strobe remains synchronized with the data.Thus the strobe and data should be locked together, but the locked strobe/ data pair of operations could move.