Reconfiguring Design -> Handel-C backs top-down software development

Handel-C backs top-down hardware development

Handel-C backs top-down hardware development
By Kjell Torklesson, Vice President, Engineering Celoxica Ltd., Abingdon, Oxfordshire, England, EE Times
February 21, 2002 (11:29 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020208S0053

Hardware-based methodologies used in ASICs and FPGAs have evolved from a bottom-up approach in which hardware functionality is developed by describing circuit structure. To this end, such approaches have focused on maintaining low-level design control. But there are limitations if these techniques are used exclusively to address a large design area.

One of the first problems arises because most functionality consists of both sequential and parallel logic, whereas hardware-description languages (HDLs) have evolved from an exclusively parallel world for describing the hardware rather than the desired function. What is needed is a language that raises the level of abstraction sufficiently for the designer to describe in the briefest possible way the desired function, not its underlying structural detail.

While register-transfer-level (RTL) subsets of HDLs, such as VHDL and Verilog, do provide a functional interpretation of the hardware description to enable the generation of hardware structure at compile time, their parallel nature requires the design engineer to add extra logic for sequential execution.

For example, in the typical HDL approach a finite-state machine is expressed as a case statement, with code cut up in pieces and put into the case statement depending in which clock cycle it is to be executed. The order of execution is then controlled by conditional settings of the state in each of these pieces.

This is essentially GOTO programming. Given the inadequacies of GOTO programming, something that was abandoned decades ago in the software world, the code becomes less readable and potentially dangerous, as in, for instance, creating infinite loops.

By introducing a language similar to ANSI-C to the hardware design process, designers gain a language that is sequential by default with a high-level flow that is geared for programming functionality. But hardware is parallel and this needs to be accounted for if a software-influenced hardware design methodology based entirely on C is going to succeed at the RT level.

There are two high-level alternatives: behavioral compilation or the addition of a simple way to express parallelism. Behavioral compilers seem ideal, automating the processes between software input and hardware output. But today's compilers give the user little control over the quality of the output. They have been likened to a long, dark tunnel where the input is hard to relate to the output should the result need optimizing.

In contrast, adding a construct for parallelism delivers a level of abstraction over RTL without compromising manual control over the result. Handel-C is an example of such a hardware-programming language with a control flow that is clear to the designer. Handel-C closely corresponds with a typical software flow and provides the essential extensions required to describe hardware. These include flexible data widths, parallel processing and communications between parallel threads.

Sequent ial by default, Handel-C has a par construct. When a block of code is qualified by par, statements are executed concurrently and synchronized at the block end. This simple construct allows for the expression of mixed sequential and parallel flows in compact and readable code. The hardware designer can begin with software programs compiled in the Handel-C compiler to generate a sequential solution. Then the designer can gradually use parallel constructs and pipelining to optimize the design. When the user sets the key variable widths, the language can deduce most of those that remain.

A high-level approach such as the Handel-C methodology provides a level of abstraction that makes it easier for designers to address a larger design space and find the correct solution for making a design smaller or faster.

For example, the DK1 design suite that is used with Handel-C has the look and feel of a software envi ronment. The debugger provides in-depth features normally found only in software development. These include breakpoints, single stepping, variable watches and the ability to follow parallel threads of execution. The hardware designer can step through the design just like a software design system using this approach.

Co-simulation and verification facilities are built into the tool chain, facilitating co-design with instruction-set simulators and VHDL simulators such as ModelSim. A key benefit is that hardware-software partitioning decisions can be changed at any stage in the design process.

Synthesis in this design system correlates to software compilation in that it is very fast; software designers are accustomed to compiling changes to their designs quickly and testing the results. This enables them to take many turns, make smaller changes and quickly recompile.

Predefined libraries much like the standard libraries of ANSI-C and other software environments to hardware design create opportuniti es for simplifying the development of new functionality as well as encouraging design reuse. Besides relying on third parties and other teams for intellectual property, users have the ability to create their own functional blocks and import others.

Such an approach can combine the ability to easily address registers, memory and peripherals. Built into Handel-C are capabilities for accessing internal and external memory as well as registers. By means of libraries of predefined functions, common application programming interfaces shield users from low-level interfaces to ease the integration of FPGAs to physical resources, including both peripherals and processors — the latter enabling hardware/software co-design. It is an approach that can mean significant time savings, giving the designer more time to concentrate on core functionality. n