Synthesis from C and other programing languages.

The advantages of using a general purpose language to describe both hardware and software are becoming apparent: designs can be ported easily and tested in software environments before implementation in hardware. There is also the potential benefit that software engineers can be used to generate ASICs: they are normally cheaper to employ than ASIC engineers! The practical benefit of such approaches is not fully proven, but there is great potential.

The software programming paradigm, where a serial thread of execution runs around between various modules is undoubtedly easier to design with than the forced parallelism of expressions found in RTL-style coding. Ideally, a new thread should only be introduced when there is a need for concurrent behaviour in the expression of the design. A product from »COMPILOGIC is typical of the new generation of such EDA tools. It claims the following:

• Compile C to RTL Verilog for synthesis to FPGA and ASIC hardware.
• Compile C to Test-Bench for Verilog simulation.
• Compiler options to control design's size and performance.
• Global analysis optimizes C-program intentions in hardware.
• Automatic and controlled parallelism and pipelining.
• Generates readable Verilog for integration and modification.
• Options to assist tracing/debugging HDL generated.
• Includes command line and GUI programmer's workbench.

However, we cannot compile general C/C++ programs to hardware: they tend to use too many language features. Java and C\# are better, owing to stronger typing and banning of arithmetic on object handles (all subscription operations apply to first-class arrays).

Must be finite state:

• all recursion bounded, otherwise we have unknown stack space use,
• all dynamic storage allocation outside of infinite loops, or at least also freed inside the same loops (needs advanced heap shape analysis as currently being developed here in Cambridge),
• perhaps use only boolean logic and integer arithmetic, although in principle floating point can be compiled to hardware without problem,
• limited string handling (most string handling packages rely on garbage collection),
• very limited standard library support because there is no operating system present to provide most of the services.

A given function can generally be done in half as many clock cycles using twice as much silicon, although name aliases and control hazards (dependence on run-time input data) can limit this. As well as the C/C++ input code we require additional directives over speed, area and perhaps power. The area directives may specify the number of RAMs or how to map arrays into shared DRAM.

Trading (or folding) such time for space is basically a matter of unwinding loops or introducing new loops.

Hazards can limit the amount of unrolling possible, including limited numbers of ports on RAMs and user-set budgets on the number of certain components instantiated, such as adders or multipliers. Products available : SystemCrafter, Catapult, SimVision, CoCentric, ... others.