The case for C/C++ hardware design

By Randy Allen and Daniel Gajski

As the complexity of hardware functionality continues to increase, hardware and software development are beginning to meld into a single amalgam. As hardware and software converge, the current schism in design languages will disappear. We believe this schism will resolve in favor of C and C++ solutions, supported by a methodology of successive refinement. An early blurring is just now becoming evident, as hardware is starting to encompass simple software functionality. As more complexity is encapsulated in hardware, the difference between hardware and software functionality — and hardware and software engineers — will dramatically decrease.

Yet, one key difference that currently exists is the language of expression. Hardware design is dominated by the use of Verilog and VHDL — languages that were created at a time when hardware engineers knew exactly what gates they wanted where. While C was born in the same era and spirit, it has since evolved beyond those early beginnings.

C++ extends the basic computational facilities in C to encompass more friendly mechanisms for data abstraction, object-oriented development, separation of interface definition from the functional implementation, data encapsulation, and extensibility. These practices are considered valuable not just for software design but for any design — hardware design, software design, or even space shuttle design.

Ultimately, the level of highest abstraction will be the one that survives, and that is clearly the software domain. This transition will not be abrupt, but it will occur more as an evolution than a revolution. The most likely transition will be along the lines that software followed as it evolved from a strict use of hand-coded assembler in the fifties to extensive use of compilers in the sixties.

At first, only non-critical portions of time-to-market-driven designs will be affected at higher levels. Over time, more sophisticated compiler and synthesis technology augmented by increasing hardware functionality will extend the reach of automatic techniques until only extremely critical portions of highly performance-driven designs will be implemented at the register transfer level (RTL).

Eventually — and "eventually" is still a long ways away — the difference between software design and hardware design will become simply a matter of the options invoked on the C compiler ("cc" versus "cc -silicon"). Technically, translating C directly into silicon is not a difficult process: the research community has been discussing silicon compilers since the early 1980s.

The quality of results of such a direct translation is a different matter, and is the main reason for "eventually". No such project has yet produced implementation results that would be considered acceptable by current hardware engineers.

Successive refinement

As design abstraction evolves upward, methodologies will also evolve upward with improving tools and support. Following the software evolution, the most likely methodology push is toward successive refinement —an extremely successful methodology in software development.

Successive refinement initially specifies a design at high level devoid of implementation detail. This step is common in current-day hardware design methodologies. However, rather than immediately translating the entire design to an implementation level, successive refinement lowers the design in piecewise fashion toward implementation levels.

The refinement process stops at the point at which automatic tools are able to generate satisfactory results. What constitutes "satisfactory results" varies from piece to piece. For extremely time-critical pieces, refinement may well proceed down to the physical level. However, for less critical pieces or for pieces well suited to automatic tools, refinement can easily stop at a high level.

Over time, improvements in automatic methods and increases in hardware functionality will extend the pieces handled automatically to where whole designs can be implemented by "cc -silicon". In the near term, however, tools are not going to be good enough and manual refinement will be required. This means that the version of C used must allow for the expression of hardware at lower levels, not just the algorithmic level.

Similar capabilities were necessary in early C compilers for software design — the ".asm" directive permitted programmers to drop into assembly in critical regions. As compilers and processor speeds have improved, the assembly features are now rarely used. Similarly, as tools improve and hardware functionality continues to increase, lower-level hardware primitives will eventually fall into disuse.

Over the past decade, several different projects have undertaken the task of extending C to support hardware, including (SpecC at the University of California, Irvine ), HardwareC, Handel-C at Oxford University (now moved to Embedded Solutions Ltd.), SystemC++ at C Level Design Inc., SystemC at Synopsys Inc., and Cynlib at CynApps.

These projects fall roughly into two complementary categories. One category, exemplified by SpecC, has focused on adding keywords to the basic C language, supporting hardware description at a high level as a basis for synthesis. The other category, exemplified by Cynlib, exploits the extensibility of C++ to provide a basic set of hardware primitives that can be easily extended into higher level support. These complementary approaches span all levels of hardware description.Levels of abstraction

Hardware specification most naturally falls into four levels: algorithmic, modular, cycle-accurate, and RTL. The algorithmic level specifies only the behavior of the design, with no specific implementation detail. At the modular level, the design is partitioned into components that communicate through a clearly (although not necessarily completely) specified protocol.

Cycle accuracy introduces the notion of a clock and a time at which events occur, but without necessarily specifying completely the implementation details of the events. RTL, of course, specifies the implementation of the events but without relying on a particular implementation technology.

Each level of refinement requires corresponding language support. Given that C has been used to describe software algorithms for roughly 30 years, the algorithmic level requires almost no extensions. "Almost no" means that unlike software, an essential element of a hardware algorithm is a precisely sized data type.

The difference between 7-bit and 8-bit multiples in software is meaningless on any machine with a word size greater than 8 bits; it is extremely significant in terms of both behavior and cost of a hardware algorithm. Accordingly, a precise statement of the sizes of data types is an essential aspect of hardware algorithms. SpecC supports arbitrarily sized unsigned variables with the "bit" data type; Cynlib provides arbitrarily sized unsigned and signed variables using the templated "Uint" and "Int" classes, respectively.

Partitioning requires a notion of an object — the equivalent of an HDL module — and a communication mechanism, such as HDL ports. SpecC implements module objects with behaviors, and at the lowest level provides a port notion of communication between behaviors. Cynlib provides both the CynModule class, which emulates modules, and In and Out classes for primitive port communications.

In both languages, it is simple to build higher-level communication mechanisms, such as channels, FIFOs, and pipelines on top of the simple primitives. Another important aspect of both languages is the ability to separate interface from functionality, thereby permitting intellectual property to be distributed in protected fashion.

Cycle accuracy requires the notion of a clock and the ability to schedule events to react to clock changes. Cynlib provides a library routine and scheduling kernel that permits arbitrary methods to be executed on significant clock events and variable changes. SpecC provides the basic forms of concurrency most commonly used to schedule parallel events, as well as a notion of time and delay between events.

Finally, RTL description requires the notion of an explicit state machine. C provides these naturally via the switch statement, although both SpecC and Cynlib provide enhancements that make recognition and optimization of these easier.

The primary benefits of higher level design and C/C++-based methodologies are dependent on the development of more sophisticated synthesis tools. Such tools will enable true design reuse by taking care of implementation details, thereby permitting design specification at a level relatively devoid of implementation technology.

Implementation details will be entered as options to the synthesis tool, allowing the same specification to be reused in many different contexts. Partitioning components betwe en hardware and software is simplified and easier to change when all components are specified in the same language.Simplifying verification

There are compelling reasons for adopting C-based methodologies now, even as technology and tools are still evolving. A C-based hardware methodology places both hardware and software in the same language. This simplifies software verification, which is typically one of the critical bottlenecks in a product release.

With a HDL-based methodology, software verification typically either has to wait until hardware prototypes are ready, or else has to depend upon a complex verification environment based on a foreign language interface into the HDL. This would include the programming language interface (PLI) for Verilog and a variety of interfaces for VHDL.

The first case means a long delay before software testing can begin; in the second case, the complexity of the environment is often the source of as many bugs as the software proper. By placing both hardware and software in the same language, a C-based hardware methodology allows simpler, earlier testing of software.

Correspondingly, a C-based methodology also simplifies hardware testing. Because HDLs are not very expressive with respect to testing constructs, hardware testbenches are commonly written in C or specific testbench languages, again requiring a complex verification environment. This environment is tremendously simplified when the hardware is described in C or C++.

The true benefit of a C-based successive refinement methodology derives from getting more reliable product to market faster. The most expensive product flaws to find and correct are those that occur in the higher level specification of the product. The reasons are twofold. First, individual components can be tested in isolation to detect logic flaws, but specification flaws, and in particular, interface flaws, are found only when all the components are tested together.

Successive refinement enables early testing of the entire system, but most methodologies used today are unable to test entire systems until actual hardware prototypes are assembled. Since this occurs late in the design process, by definition specification flaws are not found until late in development.

Second, a specification flaw almost always involves more than one component of the design, and certainly involves the high-level behavior of some component. Either case can require extensive redesign of one or more components, which is expensive. By comparison, logic flaws are very inexpensive in that they can usually be found by component testing and are localized in terms of the rework required.

Eventually, hardware design will be something that can be done by any undergraduate who has taken a programming course in C. There is much research and technology that has to be developed before that statement becomes true, but the trend of merging hardware and software is undeniable. Also undeniable is the drive toward higher levels of abstraction for hardware design. C-based methodologies are not the factors driving those trends, but they do appear to be the most likely solution to the problems that arise as hardware design moves in this direction.

Randy Allen is Vice President of Engineering at CynApps Inc., Santa Clara, Calif.; Daniel Gajski is Professor at the University of California, Irvine.

See related chart