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.

Article Scheduling using behavioral templates Share on Authors: Tai Ly Synopsys Inc., 700B E. Middlefield Road, Mountain View, CA Synopsys Inc., 700B E. Middlefield Road, Mountain View, CAView Profile , David Knapp Synopsys Inc., 700B E. Middlefield Road, Mountain View, CA Synopsys Inc., 700B E. Middlefield Road, Mountain View, CAView Profile , Ron Miller Synopsys Inc., 700B E. Middlefield Road, Mountain View, CA Synopsys Inc., 700B E. Middlefield Road, Mountain View, CAView Profile , Don MacMillen Synopsys Inc., 700B E. Middlefield Road, Mountain View, CA Synopsys Inc., 700B E. Middlefield Road, Mountain View, CAView Profile Authors Info & Claims DAC '95: Proceedings of the 32nd annual ACM/IEEE Design Automation ConferenceJanuary 1995 Pages 101–106https://doi.org/10.1145/217474.217514Published:01 January 1995 52citation351DownloadsMetricsTotal Citations52Total Downloads351Last 12 Months0Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The authors introduce EP1, a new encoding problem where the objective is to find an encoding so that the binary logic function has a minimal number of outputs after column compaction. Whereas state assignment is restricted to functions which have only one multiple-valued output variable (the next state variable), EP1 is important for functions which have many multiple-valued output variables, for example, control stores and other components of finite state machines which often occupy large fractions of the total chip area. This is particularly useful in high-level synthesis, where datapath components can often be reallocated or resynthesized to accept arbitrary or near-arbitrary control codes. A heuristic solution to EP1 is given, and experimental results are provided.>

Fasolt is a program that optimizes a register-level datapath design. Fasolt is unique in that it uses layout information to drive the choice of optimizing transformations; hence it is feedback-driven, because it uses low-level information to drive high-level decision making. Fasolt 1.0 uses critical path and channel density to select pairs of wire bundles to be merged, which may necessitate retiming. Hence scheduling and allocation can take wiring into account in a novel way, which has been sufficient to given 10 and 50% area reductions in naive initial designs.>

This paper presents a program named RLEXT (Register Level Exploration Tool), which allows a user to manually modify a register-level datapath design. The allowed operations are addition and deletion of components and connections. Any component not an i/o port, a register, or an addressable memory may be added or deleted. Any wire or connection of a pin to a wire may be added or deleted. The unique aspect of RLEXT is that the continued ability of the datapath to support its behavioral specifications is guaranteed: that is, if the user makes changes that would impair the datapath's ability to carry out the desired function, RLEXT will automatically repair the datapath so that it is once again able to express the specified behavior.

This paper describes ADAM, an integrated Advanced Design AutoMation system, with focus on the knowledge-based synthesis subsystem. Working parts of this subsystem include a number of design activities and utilities, and a unified, multidimensional, hierarchical design representation. Two aspects of the synthesis subsystem are described in detail: the design planner and the natural language interface. The planner builds a plan for synthesis and analysis activities, drawing inferences from a knowledge base represented by a semantic net. The natural language interface accepts system-level behavioral specifications. Both of these packages are currently being implemented.