Introduction

An architecture description in ArchC is divided in two parts: the Instruction Set Architecture (AC_ISA) description and the Architecture elements (AC_ARCH) description. In the AC_ISA description the designer provides all details about the instruction set such as: instruction names, formats, sizes as well as each instruction behavior and the information required to decode it. In the AC_ARCH description the designer lists architectural resources like storage modules, pipeline structure etc.

AC_ARCH Description

ArchC uses structural information about the resources available in the architecture in order to automatically generate a simulator. The designer must provide such information in the (AC_ARCH) description, which is basically composed of storage elements and pipeline declarations.

The level of detail used in this description will depend on the abstraction level that the designer wants for his/her model. For example, one may want to simulate the instruction set of the MIPS architecture, without considering its pipeline. This makes the instruction behavior description very simple and also demands few structural information. On the other hand, for cycle-accurate models, the designer must provide ArchC with more details about the processor structure, as shown in the figure below:

AC_ISA Description

The AC_ISA description gives ArchC all information it needs to automatically synthesize a decoder, along with the behavior of each instruction in the architecture. This description is divided into two files, one containing the instruction and format declarations and another containing the instruction behavior.

Figure 2 shows an example of an AC_ISA description extracted from our MIPS model. It contains instructions, formats, decoding information and assembly syntax declarations, illustrating the main characteristics of an ISA description in ArchC. Every instruction must have a previously declared format associated to it. The designer declares an instruction through the keyword ac_instr and he/she can assign it a format by using C++ style templates. In the example, format Type_R is associated to instruction add. This allows the designer to access each instruction field individually when describing instruction behaviors. Assembly language symbols, like register names, can be grouped through the ac_asm_map construct. The instruction syntaxes and operand encoding are specified by the set_asm construct, which resembles the printf/scanf family of functions in the C language. Furthermore, pseudo instructions can be described based on previously created instructions through the pseudo_insn construct. In the example, we declared the MIPS register names (using the reg identifier) and used them as an operand type in the declaration of the syntax of the add instruction. We also created the MIPS pseudo instruction li (load immediate).




Figure 3 shows an example of a behavior description in ArchC. It presents part of the behavior of the MIPS instruction add. Notice that the code is divided, by means of a C++ switch statement, so that ArchC can identify which operations are executed at each pipeline stage. A similar switch statement can also be used to describe multi-cycle instructions when required. ArchC allows behavior descriptions to be expressed in several levels of abstraction. For example, at the very early stages of the design, cycle-accuracy may not be important. Normally, the first model of a new architecture does not have timing information. For this preliminary model, the behavior of a given instruction would be just a sequence of C++ statements representing the operations that this instruction would execute in the hardware. In this last case, the generated simulator would execute one instruction per cycle.

Memory Hierarchy

All storage device objects in ArchC are instances of the same base class, called ac_storage. This class provides a number of simulation features, like delayed assignment support, update logs for simulation debugging, statistics for architecture exploration, support for various architecture wordsizes, etc. Considering how data is stored, these objects act like containers, i.e., the data is stored into arrays and is accessible through read and write methods.

In order to allow a more detailed description, including a memory subsystem, we created a Storage Class Hierarchy, inheriting the base class ac_storage mentioned above, and specializing it to model registers, register banks, and even caches. An object of the cache simulation class, called ac_cache, can be customized by the designer, by defining the following attributes: number of words at each cache line, number of lines in the cache, set associativity, replacement policy, and writing scheme.

Figure 4 shows a memory hierarchy composed of three levels: 2 caches (L1 e L2), and one memory (MEM). L1 is declared as a direct-mapped, 128 lines (blocks), 2 words/line, write-through, write-around cache. L2 is declared as a two-way set-associative, 256 lines, 1 word/line, randomly replaced, write-through, write-around cache. In ArchC, hierarchies are described by the cache's method bindsTo. This method takes as argument the cache device which is the next cache level down in the hierarchy. In Figure 5, L1 is supplied by L2, that is supplied by the lower level MEM, as shown by the two last lines of the description.

Below are all possibilities available for cache declaration arguments in ArchC, following the argument order in the ac_cache declaration:

1. Associativity:
    "dm", "2w", "4w", ..., "fully"

2. Number of Lines (blocks)

3. Number of words at each line (block)

4. Replacement strategy (not used for direct-mapped ("dm") caches):
    "lru" (LEAST RECENTLY USED)
    "random" (RANDOM)

5. Write policy:
    "wt" (WRITE-THROUGH)
    "wb" (WRITE-BACK)

6. Write policy:
    "war" (WRITE-AROUND)
    "wal" (WRITE-ALLOCATE)

Direct-mapped cache declarations take five arguments instead of six, just because the fourth argument (replacement strategy) does not make sense in this case. Finally, any of the arguments can be given in both upper or lower case.




In Figure 5, we illustrate the use of separate caches for instructions and data. The designer has declared a direct-mapped instruction cache (IC) and a 2-way set-associative data cache (DC). Both are connected to the memory object (MEM). This forms a two-level memory hierarchy, with the two caches placed at the same (first) level. Notice that, in this situation, the designer must indicate to ArchC the appropriate device for fetching instructions and reading/writing data. This is easily accomplished by using the keywords ac_icache and ac_dcache for cache object declarations.

More Information

Readers should refer to the ArchC Language Reference Manual for more detailed information on ArchC descriptions, keywords, syntax, behaviors and tools.