Knowledge Center
Knowledge Center

Behavioral Synthesis

Transformation of a design described in a high-level of abstraction to RTL


Behavioral synthesis has quite a long history, with a substantial body of academic work dating back to the late 1980s. There were several commercial behavioral synthesis products introduced in the 1990s, most notably Behavioral Compiler from Synopsys and Monet from Mentor Graphics. These products had a chequered and mostly unsuccessful history.

Behavioral synthesis in its original form simply provided a time and resource abstraction. That is, the input was written in a procedural form. The synthesizer would schedule the code and create a state machine to sequence through the appropriate number of clock cycles to accomplish the computation. The primary determinant of how many states the computation would take is how many operations can be performed in parallel. That is, how many operations can occur in each state. This is determined both by the dependency graph and by how many hardware resources are available. For example, if a computation requires five add operators that are independent of each other, it could be done in one cycle if there were five adders available, or 5 cycles if there was just one adder available.

Behavioral synthesis uses a high-level untimed, or partially timed, functional description. There were several reasons why behavioral synthesis was not successful. The issue of input language was one of the most prominent.

The commercial products all used either Verilog or VHDL as their input language. This was a natural choice, indeed probably the only viable choice at the time. However, while both languages could support procedural code within the context of their hardware description semantics, the original description of an algorithm was never done in either language. Algorithms were nearly always originally written in a general purpose programming language, usually C or C++.

In order to use behavioral synthesis, the algorithm had to be translated to Verilog or VHDL. This was an awkward procedure, in part because the underlying semantics of the two languages differ, and in part because VHDL, and Verilog are not very good behavioral languages. Thus, using behavioral synthesis did not save as much effort as designing at a higher level of abstraction promised. Although SystemVerilog adds new constructs to Verilog at a somewhat higher level of abstraction, it has still not proven itself as a good behavioral language.

Another reason behavioral synthesis did not reach commercial success was difficulty with timing. When the synthesis program produced RTL to perform a computation, it had to predict how many levels of logic could fit into a clock cycle and fill the states of the state machine accordingly. However, the synthesis program relied on an internal model of what the later optimization programs, i.e. logic synthesis and place and route, could do, and that model was not particularly accurate.

As a result, it often would produce RTL in which not all the logic could be executed in a single cycle. That is, there would be a long path that violated timing at the desired clock frequency. There was little, if anything, the user could do to correct the problem at the source level, short of changing the code completely. If you changed the input code or the constraints, the resulting RTL would usually be very different from the previous RTL, and the new problems it had would have little, if any, relationship to the previous problems.

The final big problem with behavioral synthesis was verification. The verification environment would be written to work with the design in its original, behavioral form. Once the design had been debugged, then RTL would be produced by the synthesis program and the result simulated with the verification environment in order to verify that the synthesis process had produced a correct transformation. However, this often did not work. The problem was that the timing abstraction of the behavioral code was reflected in the verification environment code at the external interfaces. The result was that the synthesis program would change the cycle timing of the interface operations, so the verification environment would no longer communicate properly with the design.


Changing The Design Flow


Synthesis: Next Steps In SoC Design