Abstraction Levels and Hardware Design

Introduction
Design of anything, from an ERP application to an embedded software system to a hardware device to a mechanical object, is done at some level of abstraction. Simply, a level of abstraction is the vocabulary that the designer uses to describe the thing being built. The notion of abstraction levels came into vogue with software systems, since there were several obvious levels: machine code, assembly language, Fortran, subroutine libraries, and eventually interpreted application languages like SQL. In hardware design, we are familiar with several levels of abstraction: polygon, transistor, gate, and register-transfer (RTL). It has been apparent for some time that the register-transfer level is too low for the size of hardware systems which are being fabricated, due to increasing chip capacity. However, there hasn't been much agreement on just what constitutes a higher level of abstraction.

Levels of abstraction
A level of abstraction is usually understood in terms of the language of design. Often, the language defines the level, but that doesn't have to be the case. A level of abstraction is determined by the objects that can be manipulated and the operations that can be performed on them. In programming terms, the objects are data types and the operations are the operators that can be used in expressions and control constructs.

As described in a 1975 paper by Jack Dennis [2], there are three ways to implement a level of abstraction: interpretation, translation, and extension.

Interpretation
Interpretation is a technique for dynamically realizing the semantics of a language. A good example of a level of abstraction being implemented by interpretation is a micro-coded processor. The instructions visible to the programmer are implemented by a lower level processor which interprets the programmer-visible instructions. You can also make the argument that the use of a low-level VLIW processor to implement an algorithm is an example of interpretation. There aren't many other examples of the use of interpretation in hardware design.

Translation
Translation is the most easily recognized form of abstraction implementation. Synopsys' Design Compiler translates RTL Verilog into a netlist, a process called logic synthesis. There has never been a widely accepted definition of the register-transfer level. The traditional definition is that RTL is whatever Design Compiler accepts. A better definition is that RTL is a representation where the activity in each clock cycle is explicitly defined.

Behavioral synthesis was an easily identified analog of logic synthesis. It translated language at a behavioral level to RTL (or directly to gates). In general, behavioral level code is written using the same data types as RTL, but it is unscheduled and unallocated. That is, the data objects and the operations on them are specified, but the resources and the schedule of cycles required are not specified.

Extension
Extension is not as widely recognized in hardware design as translation and interpretation, but is potentially the most useful. Extension is accomplished by defining new data types and operations in the same language that is used in the next lower level. Object oriented languages make creating new levels of abstraction in a single language particularly easy, and in fact, that is the primary virtue of C++. SystemC is nothing more than a hardware level of abstraction implemented by extension in C++. More important is that using C++, additional data types and operations can be defined to create higher levels than the base SystemC level.

LEVELS OF HARDWARE DESIGN
We can now define the following levels of abstraction for hardware design.
RTL (translation)
The most widely used language for writing RTL code is Verilog. RTL code can also be written in SystemC. The code is characterized by arithmetic expressions, including conditionals and control constructs, which execute in a fixed schedule of cycles. The data objects, registers and wires, typically correspond to hardware objects. Parallelism is explicitly represented in the form of processes triggered by signals on wires.

Behavioral (translation)
Behavioral code looks like normal sequential code found in a general purpose programming language. It does, however, have structural information in the form of modules and ports. Behavioral code normally also has the ability to represent parallel processes. Behavioral code could be written in a variety of languages, like SystemC, Verilog, SystemVerilog, or VHDL. It can't be written in C because of the need to describe structure and parallelism.

Behavioral + data types (extension)
When you add non-standard data types to the previous behavioral level, you get this level. Obvious data types are fixed point and floating point. Other possibilities are structures that can have some common operations. For example, you could have a pixel data type where operators would include logical or arithmetic operators. Another example would be a vector data type that had addition and multiplication operators defined. Code written using such a data type is clearly higher-level than behavioral code.

Transaction (extension)
The next layer up adds transaction objects to the previous level. This level is now widely known as the TLM, for transaction level modeling. A transaction object is an abstraction of an interface between modules (or more generally, concurrent processes). An example would be a fifo. The transaction object would take the place of several ports in the module port list. The operations done on the object would be get and put, and perhaps query status. Another example would be an AMBA bus interface. This is clearly a meaningful abstraction over behavioral code.

Domain (extension)
The next layer up includes what, for lack of a better term, we will call domain level. An example would be an object like a FIR filter. Operations on a FIR filter would typically simply be input and output. What is the difference between a domain level object and a canned subroutine? Not much, except that it has access to all the resources of the lower levels. It would also be parameterizable, perhaps substantially.

The common thread of these levels is that they can all be automatically processed with a high-level synthesis program like Forte Design Systems' Cynthesizer. The other common thread is that all of the levels obtained by extension (levels 3-5) depend on an object-oriented language that allows objects and operators to be defined. We can say that high-level synthesis allows design to be done at level 5, as opposed to behavioral synthesis, which enables design at level 2.

AN EXAMPLE
As an example, we will take a 4x4 matrix multiply algorithm and illustrate it at each level from lowest level to highest level. The code for this algorithm, written in C, is as follows.

The algorithm operates on two matrices supplied by the environment, in this case the subroutine's caller. We will now show hardware implementations of this algorithm written at various levels of abstraction.

RTL
The matrix multiply can be implemented at RTL, a fragment of which is shown in Figure 1. In this example, each cycle is completely described. The resources are also defined. Note that the loop control has been made explicit, and the innermost loop has been unrolled. The code specifies how many adders and multipliers there are, and what order they execute in. The original C code used a floating point data type. For hardware, it is customary to convert the data representation to fixed point, and that is what is shown here. A fixed point representation of (32,8) has been chosen, implemented as a simple signed 32-bit quantity. The multfp part is assumed to provide the appropriate shifting, rounding, and overflow operation for a fixed point multiply. This has assumed that the four multiplies and three additions can take place in a single cycle.

1.This is a RTL fragment of a 4x4 matrix multiply.