Behavioral ARM Processor Model Using System C. Dallas Webster IEEE Student Member No Texas Tech University 12/05/05

Size: px

Start display at page:

Download "Behavioral ARM Processor Model Using System C. Dallas Webster IEEE Student Member No Texas Tech University 12/05/05"

Chastity Johnston
5 years ago
Views:

1 Behavioral ARM Processor Model Using System C Dallas Webster IEEE Student Member No Texas Tech University 12/05/05

2 Table of Contents Abstract... 2 Introduction... 3 System C... 3 ARM Processors... 4 Load and Store Functions... 5 Digital Filter... 6 Bus Structure 7 Results..7 Conclusions... 9 Originality Acknowledgments.. 11 References Appendices

3 Abstract Advanced RISC Machines (ARM) are an example of a simple processor used to accomplish simple processing tasks in many of today s electronics. These processors have small instruction sets and basic processor architecture. SystemC is one of many high level programming languages used to write hardware descriptive code. This paper discusses the continuation of a project started by J.D. Chaparro and Jacob Day to model the behavior of an ARM processor using System C. It discusses the architecture of a basic ARM processor, SystemC as a language, and the implementation and testing of the processor model. 2

4 Introduction In today s world, technology is constantly striving to become faster, lighter, and smarter. Along with this comes the need for processors to become more powerful while becoming physically smaller in size. Design of these complex processors can become difficult at the transistor level, which introduces the need for hardware descriptive languages. Hardware descriptive languages (HDL) allow an engineer to describe the behavior desired in a processor with a high level language much faster than they would be able to design at the transistor level. These systems can then be tested for functionality before they are ever sent to fabrication. Verilog and VHDL are two types of hardware descriptive languages that are commonly used for this purpose, where hardware can be directly synthesized from the hardware description language. However, these languages are still fairly limited in their options, focusing on a register transfer level (RTL) type of design, and a higher level language is sometimes desired. System C is one such higher level language. System C attempts to bridge the gap between a software and hardware descriptive language. This allows a designer to design at a level higher than RTL, allowing more complex systems to be easily designed. After design, these systems can be reduced to lower levels of abstraction and eventually synthesized all the way down to hardware. System C is a useful aid to designing the complex processors that new technology requires. Advanced RISC Machine (ARM) processors are a type of processor that can be modeled using System C. ARM processors are very low level processors by today s standards, but still have many applications. ARM processors can be found in PDA s, mp3 players, and other portable electronic devices. The overall goal of this project was to behaviorally model an ARM processor using System C. The specific portion reported here was to complete the basic instruction set of the ARM processor, convert the behavioral model into a more realistic model, and then implement a program in the model similar to one found on a real ARM processor. System C System C is used to model the functionality, software, and hardware components of real systems. Four System C commands of particular importance are SC_MODULE, SC_THREAD, SC_METHOD, and SC_CTOR. SC_MODULE creates a module, such as an ARM processor, that can represent hardware. SC_CTOR is the constructor for that module can be made sensitive to a certain event. SC_METHOD and SC_THREAD behave similarly and are imbedded in the SC_CTOR. The event to trigger the module is created in the SC_METHOD or SC_THREAD (Day). When this event occurs it will trigger the module to react and go through the behavioral process, in this case the Instruction Fetch module will be sensitive to a clock. Figure 1. System C Module The above figure demonstrates the Instruction Fetch processor module. Clk is defined as a Boolean variable as a System C input, meaning it is an input to the module that can only have a true or false value. I_FETCH_FUNC() is similar to a function call in C++ and will be the function that is called when the module is activated by the input. This function will contain all the behavioral description of the Instruction Fetch stage in the ARM Processor. The next part of the module is the constructor. Inside this constructor the module is made sensitive to a positive 3

edge of the clock and upon this event the I_FETCH_FUNC() function is called. This is how the Instruction Fetch module of an ARM processor is represented in System C.

5 edge of the clock and upon this event the I_FETCH_FUNC() function is called. This is how the Instruction Fetch module of an ARM processor is represented in System C. From the example described above, it is obvious that System C has several differences from standard C++ code. One is the idea of inputs, outputs, and input/outputs. System C allows the designer to make a module sensitive to an input, similar to the way hardware would react. A table of SC variables is shown in the appendices. System C also introduces the idea of having unknown bits and high impedance bits in logic variables. These values are found in hardware all the time, but are not represented in software, where values must be either a 1 or a 0. All these additional functions of the System C libraries make it very convenient for modeling hardware behaviorally. Relatively complex processors can be described with ease using this high level language. ARM Processors As of the year 2000, there were 5 different versions of the ARM processor in the market, varying in complexity from the simplest (1) to the most complex (5). The ARM processor architecture is relatively simple. The basic processor consists of bit registers, a block of program memory, a block of user memory, a decoder, a preprocessor/shifter, and an ALU for execution. The block diagram for a behavioral ARM processor model is shown below. Figure 2. Behavioral ARM Block Diagram In the ARM processor, each instruction consists of a 32 bit word. Each instruction has a 4 bit CPSR (Current Program Status Register) that tells the processor which mode it is operating in, such as user, supervisor, interrupt, etc The remaining 28 bits vary depending on the instruction, but have an 8 bit opcode followed any combination of register addresses, shift operations, operands, and offsets. In most cases, the speed of a RISC processor is increased by pipelining its operation. Pipelining refers to a structure where an instruction is processed in stages. In a pipelined processor, an instruction can be decoded while the next instruction is fetched and the previous 4

6 instruction is shifted. This allows several instructions to be processed at the same time with an instruction being completed with every clock cycle. The ARM processor is a pipelined processor and in this model the pipeline has five stages. The first stage in the pipeline is the Instruction Fetch. In the Instruction Fetch stage the processor goes to the address in the program memory that is pointed to by the program counter. This instruction is passed on to the next stage in the pipeline, the decode stage. The program memory is where all the instruction to be executed by the processor are stored, or in other words, the program. The Instruction Fetch stage is called once per clock cycle. The second stage in the pipeline is the Decode stage. In Decode the instruction is broken up into separate types of information and is interpreted to represent a particular instruction from the instruction set. The particular instruction is determined by an 8 bit opcode contained between bits 20 and 27. Once this information is sorted to into one of the 40 instructions, the rest of the instruction can be divided into register addresses and shift commands to be used in later stages of the processor. A sample instruction is shown below. Figure 3. Load Instruction (ARM Reference) The next stage in the pipeline is the preprocessor. The preprocessor performs shifts for functions that require them and calculates addresses for the load and store modes. This includes arithmetic, logical, and wrap around shifts. These addresses and shifted versions of operands are then passed on to the execute function in the block diagram for execution. Execute is the block where the function is actually performed. Arithmetic and logical functions are performed here. The execute block is basically the equivalent of the arithmetic logic unit or ALU in the processor. In order to read and write from memory the final stage in the process is called, the write back stage. The write back stage is the only stage where memory can be accessed. By modifying the write enable bit for memory, memory can be read or written in this final stage. Each of the above steps is implemented within its own module in SystemC. With each positive edge of the clock the modules are called to process an instruction. This allows the processor behavior to mimic the behavior of an actual pipelined processor. Load and Store Functions The first goal of this project was to complete the instructions in the instruction set. The specific instructions were LDR, STR, and their derivatives: LDRB, LDRBT, STRB, STRBT, LDRT, STRT, LDC, and STC. The B in the listed functions means that the operation is a byte operation and only the least significant 8 bits are used. The T means that the operation is translated and shifted in some way or another. The C bit means that the operation loads/stores to/from a bus. Each of these has up to 9 modes in which it can be executed as well. The chart for this is shown below. 5

Figure 4. Load and Store Types The first step in executing a Load or a Store function is recognizing the instruction as a call to Load or Store. This takes place in the decoder.

7 Figure 4. Load and Store Types The first step in executing a Load or a Store function is recognizing the instruction as a call to Load or Store. This takes place in the decoder. The decode function is a simple if-else if structure, meaning that the ranges of the 8 bit opcode are compared to known values for each function. Once there is a match the rest of the instruction is divided and stored in variables to be passed on to other functions, in this case they are called *op. This is done for each different version of Load and Store. After the instruction is decoded and sorted into useful variables, the information is passed onto the preprocessor stage. In the Preprocessor stage the instruction is sorted between the nine different versions of Load, Store or their derivatives. If a shift, offset, or index is requested then this is also performed in the preprocessor so that only the address to actually be used is passed on to execute. The code to accomplish this is shown in the attached C++ files. After the preprocessing, the address has been calculated and is ready to be passed to the execute block. Relatively little is done in the Execute block for load and store functions because only the write back block has access to memory. In the case of a load nothing at all is done and in the case of a store the register and address information are placed on the bus and write enable bit for memory is made high. The rest of load and store take place in the write back block. In the write back block the actual transfer of information occurs between registers and memory or between a bus and memory. For a Load, the value of a register is replaced by the data in a memory location, and the opposite happens for a store. If a store is called then the write enable bit is also changed back to a low value before exiting the write back stage. For the byte versions of both, the value to be loaded or stored is bitwise AND ed with the hex value x000000ff to pass just the least significant 8 bits. Digital Filter After achieving a realistic model of an ARM processor in SystemC the goal of this project was to use the model to perform a task similar to one that could be done by a real ARM processor, like a digital filter. A digital filter takes noisy digital information and smoothes out the information to get rid of spikes. In this case, data is stored in memory similar to data that would come from an analog to digital converter recording the information from a noisy sine wave. The processor model gathers the data in groups of four points, takes an average, and then stores the new data point to memory. As the program increments through the data in memory, it averages the current point with the point after and two points before and then increments the address it is looking at. This effectively averages out the information stored in memory and performs a smoothing operation on the data, before branching back to load new points. 6

8 Bus Structure In addition to using the processor as a digital filter, a bus structure was implemented in the model so that it could be interfaced with various slave devices using a WISHBONE structure. In a wishbone structure there are several interrupt devices that are used to signal that a data transfer is requested. In this case a strobe input goes high when a peripheral requests a transfer. The strobe causes an interrupt in the ARM processor model that tells the processor to interact with the bus. The ARM processor leaves its main program and enters an interrupt vector where, depending on the read/write enable input, the processor will either take information from the bus or write to the bus. When the transaction is complete the model will send its own acknowledge signal that tells the external device that the transfer is complete and then the model will re-enter the program and continue as before. A very basic bus structure that accomplishes this is implemented in this processor model. Figure 5. Wishbone Interface Signals (WISHBONE) Results In order to test the Load and Store functions, instructions to call them were placed in the program memory. The data in the registers and in the memory were monitored and compared to the expected values to determine whether the functions would pass or fail. For this purpose, an output file is created when the code is run that describes what is happening in the processor, outputting the values stored in the registers and in memory, where appropriate. These values are compared to the expected values based on the instruction that are stored in a file called memorykey.txt. The functions were tested extensively and are fairly complicated, so only a single test is described in this paper. Load was tested in several ways, the first test was just to ensure that a value could be loaded from memory into a register with no offset. The instruction format for load was shown earlier in this paper and using this format the instructions below were selected. The output on top 7

9 with the first instruction represents a load with no offset as the last 12 bits are zeroes. The second instruction adds an offset of one resulting in a different memory location being loaded. Figure 6. Load/Store Results In the output shown in Figure 6, Load is shown as taking the value in register 11 (B) and using it as a memory address. The value 4 in that location points to memory address [0][2] in the two dimensional array. The data stored in this memory location is shown in the bottom right corner of the screenshot and is actually an instruction from program memory representing an BBL call, a branch. This value of xfa is then stored in register 12, (C) from the instruction, as the decimal number For the second instruction the only thing that changes is the address to load from. After the negative offset, the address to load changes from the 32 bit representation of 4 to 3. This means that the instruction before BBL, an AND, should be loaded into register 12 and on the result file it is obvious that register 12 now contains the decimal equivalent of that instruction. This test was repeated for each type of load and store and each passed successfully. After all the instructions were successfully tested, a program was written to perform the digital filter task. Thirty two bit representations of a sine wave were input into memory with several points modified to make the data noisy, so that it contained several spikes. The program was run on the data and the memory was checked to see the processors effect on the information. After graphing the two waves side by side it is obvious that information was filtered and smoothed. 8

10 Figure 7. Digital Filter Results The bus structure was also thoroughly tested in the processor model. Using the same program that was run for the digital filter, a testbench module was created to act as a peripheral device interfacing with the bus and the processor. In this case, the peripheral device requested a store from the bus at the 30 th clock cycle and a load to the bus at the 60 th clock cycle. The processor was able to read and write from the bus and then return to the program as expected and proved the bus functionality to be successful. The complete results and output of the overall program are available from the author. Conclusions System C is a very powerful developmental tool. It allows great modeling of behavioral systems and hardware way beyond that allowed by C++. The freedom allowed by the new data types and the modules with event sensitivity allow for convenient ways to simulate how hardware would react. Using SystemC a realistic behavioral model of an ARM processor was accomplished. ARM processors are known for executing a command in a single clock cycle or at least giving an answer every clock cycle. Originally in this model, instructions were executed unrealistically as fetch, decode, preprocess, and execute stages were done in the same clock cycle. In the second half of this project, the processor was fixed to be a pipelined RISC architecture, making the model more realistic. Now each of the above stages are executed independently with each clock cycle on different instructions. In addition, a memory module was added to behave more realistically like memory with a write enable bit and data and address busses. Finally a write back stage was added to the pipeline to allow the processor to interact with memory more realistically. The processor model is also now capable of running an actual program, such as the digital filter discussed above, and behaving like an ARM processor. The model is also capable of simulating an interface with a peripheral device through a bus structure. This model is very powerful in its representation of an actual processor and only scratches the surface of ideas that 9

11 could be implemented using SystemC to model hardware. More complex processors than a basic ARM can be implemented with this software with relative ease and can be tested before being brought down the register transfer level of a hardware description and eventually actual hardware. 10

12 Originality A System C model for an ARM processor has, to the author and advisor s knowledge, never been done. This is highly desirable for system level design. The specific tasks completed are described in the Conclusions of the paper. Acknowledgments The goal of this project was to behaviorally model an ARM processor using System C. The project was started by J.D. Chaparro and Jacob Day in the summer of Their goal was to complete basic level 3 implementation of an ARM processor, which included a processor with 40 instructions. At the point where Dallas Webster took over the project, all of the instructions had been completed except for the load and store functions and their derivatives. The goal part of the project as pertaining to Webster was to complete the basic instruction set of the ARM processor, convert the behavioral model into a more realistic model, and then implement a program in the model similar to one found on a real ARM processor. References 1. Day, Jacob, AESE System C ARM Processor, August 4, Chaparro, John, SystemC Behavior Description of an ARM processor, August 4, ARM Architecture Reference Manual, 4. SystemC Version 2.01, 5. Wishbone Interconnection Architecture, 2004, 6. Mano and Kime, Logic and Computer Design, 2004, Prentice Hall 11

13 Appendices Figure 8. Budget Figure 9. Gantt Chart 12

14 Figure 2. System C Installation (Chaparro) Figure 3. System C Variables Figure 4. Memory Management Module 13

15 Figure 5. Data In vs. Data Out Figure 6. Bus Activity 14

16 Figure 7. Program Model Figure 8. Sample Output 15

Job Posting (Aug. 19) ECE 425. ARM7 Block Diagram. ARM Programming. Assembly Language Programming. ARM Architecture 9/7/2017. Microprocessor Systems

Job Posting (Aug. 19) ECE 425. ARM7 Block Diagram. ARM Programming. Assembly Language Programming. ARM Architecture 9/7/2017. Microprocessor Systems Job Posting (Aug. 19) ECE 425 Microprocessor Systems TECHNICAL SKILLS: Use software development tools for microcontrollers. Must have experience with verification test languages such as Vera, Specman,