Team Arénaire

Members
Overall Objectives
Scientific Foundations
Application Domains
Software
New Results
Contracts and Grants with Industry
Other Grants and Activities
Dissemination
Bibliography

Section: Scientific Foundations

Hardware Arithmetic Operators

A given computing application may be implemented using different technologies, with a large range of tradeoffs between the various aspects of performance, unit cost, and non-recurring costs (including development effort).

In each case, the computation is broken down into elementary operations, executed by elementary hardware elements, or arithmetic operators . In the software approach, the operators used are those provided by the microprocessor. In the ASIC or FPGA approaches, these operators have to be built by the designer, or taken from libraries. The design of hardware arithmetic operators is one of the goals of the Arénaire project.

A hardware implementation may lead to better performance than a software implementation for two main reasons: parallelism and specialization. The second factor, from the arithmetic point of view, means that specific data types and specific operators may be used which would require costly emulation on a processor. For example, some cryptography applications are based on modular arithmetic and bit permutations, for which efficient specific operators can be designed. Other examples include standard representations with non-standard sizes, and specific operations such as multiplication by constants.

A circuit may be optimized for speed or area (circuit cost). In addition, power consumption is becoming an increasingly important challenge in embedded applications. Here again, data and operator specialization has to be combined with generic power-aware techniques to achieve the lowest power consumption.

Those considerations motivate the study of arithmetic operators for ASIC and FPGA. More specifically we consider the following aspects.

Number Representation

The choice of a number representation system may ease the implementation of a given operation. A typical example is the logarithmic number system , where a number is represented by its logarithm in radix 2. In this system, the multiplication and the division are exact (involving no rounding) and easy, but the addition becomes very expensive. A more standard example is that of redundant number systems, like carry-save and borrow-save, often used within multipliers and dividers to allow very fast addition of intermediate results. We also work on other number systems such as finite fields or residue number systems for cryptography. In the case of computations on real values, we consider two different solutions with fixed-point and floating-point number systems.

Algorithms

Many algorithms are available for the implementation of elementary operators. For example, there are two classes of division algorithms: digit-recurrence and function iteration. The choice of an algorithm for the implementation of an operation depends on (and sometimes imposes) the choice of a number representation. Besides, there are usually technological constraints (area and power budget, available low-level libraries).

Research is active on algorithms for the following operations:

Architectures and Tools

Implementing an algorithm (typically defined by equations) in hardware is a non-trivial task. For example, control signals are needed for correct initialization, most circuits involve memory elements and clock signals which have to be managed carefully, etc.

In this process, computer-aided design tools play a major role. Unfortunately, such tools currently have very poor arithmetic support (typically only radix-2 integer representations, with simple adders and sometimes multipliers). Improving this situation by developing specific design tools is an important research direction.

Finally, even though an algorithm has been formally proven, its hardware realization needs to be checked, as errors may be introduced by the synthesis process and in the physical realization. For this purpose, test vectors are used to validate the final circuit. For small circuits, such vectors may exhaustively test all the combinations of the inputs. When this exhaustive approach becomes impractical, it is the responsibility of the designer to provide test vectors ensuring sufficient coverage of all the possible faults. This again is a non-trivial task.


previous
next

Logo Inria