CONTENTS1 INTRODUCTION (1)STATEMENT (2)2 PROBLEMPROCESS (3)3 DESIGN4 ARCHITECTURE (4)4.1 I NTRODUCTION (4)4.2 D ATAPATH,C ONTROLLER, AND I NSTRUCTION P IPELINE (5)4.3 I NSTRUCTION S UBSET (7)4.4 C ODING E FFORT (8)4.5 G ROUP O RGANIZATION (8)4.6 C ONCLUSION (8)4.7 A CKNOWLEDGEMENTS (8)4.8 M IXED ASM (8)4.9 D ATAPATH (8)55 REGISTER FILE / BARREL SHIFTER (8)5.1 REGISTER FILE (8)5.1.1 INTERFACE (8)DESCRIPTION (8)5.1.2 FUNCTIONAL5.2 ADDRESS REGISTER (8)5.2.1 INTERFACE (8)DESCRIPTION (8)5.2.2 FUNCTIONAL5.3 WRITE DATA REGISTER (8)5.3.1 INTERFACE (8)5.3.2 FUNCTIONALDESCRIPTION (8)5.4 BARREL SHIFTER (8)5.4.1 INTERFACE (8)BEHAVIOR (8)5.4.2 FUNCTIONAL6 ARITHMETIC LOGIC UNIT/BOOTH MULTIPLIER (8)6.1 D ESCRIPTION OF B OOTH’S MULTIPLIER (8)6.2 D ESCRIPTION OF ALU (8)6.3 D ESIGN P ROCESS OF THE B OOTH’S M ULTIPLIER (8)6.4 D ESIGN P ROCESS OF THE A RITHMETIC L OGIC U NIT (ALU) (8)DATA (8)7 ERROR8 CONCLUSION (8)9 SUGGESTIONS (8)10 BIBLIOGRAPHY (8)11 CREDITS (8)1INTRODUCTIONThe ARM7 processor is part of the Advanced RISC Machines (ARM) family of general-purpose 32-bit microprocessors for use in application or customer-specific integrated circuits. The ARM family of microprocessors targets the low power, price sensitive market, and is currently used in palmtop computers, smart cards, and GSM terminal controllers. The advantages of the ARM7 stem from its simple design and efficient instruction set.The ARM7 is a three stage single pipelined microprocessor. All the decoding, execution, and write back happens in the same stage. Because of this, the designers of the ARM7 did not need to implement such space hogging methods as data forwarding and branch prediction. The ARM7 is also designed such that all execution happens in one cycle. They accomplish this by stretching the system clock as long as they need essentially stalling the processor until the instruction has completed execution.The ARM instruction set, being a RISC microprocessor, is much more efficient than CISC based systems. The instruction set is comprised of eleven basic instruction types. Two make use of the on-chip arithmetic logic unit, barrel shifter and multiplier. Three classes control data transfer between memory and registers. Another three classes control the flow and privilege level or execution. The last three instruction types are dedicated to the control of external coprocessors, which allow the functionality of the instruction set to be extended off-chip. The ARM instruction set is ideal for compilers of many high-level languages, and assembly code programming is also very straightforward. Another interesting feature of the ARM instruction set is that all of the instructions support conditional execution.This combination of an efficient instruction set and simple design resulted in a microprocessor with very low power consumption, small die size (approximately thirty thousand transistors), low price, and comparatively high performance.2PROBLEM STATEMENTThe goal of the project was to design and synthesize an ARM7 microprocessor with a unified cache and IEEE754 compliant floating-point unit within a ten-week time frame. The design was broken up and given to several project groups.An Architecture group focused on the microprocessor controller and datapath. A Memory group focused on the cache and memory unit. Separate groups focused on theALU/Multiplier and the Register File/Barrel Shifter units within the ARM7. A fifth group was dedicated to the design of the floating-point unit.The specification for the microprocessor came in the form of the ARM7 data sheet, document number ARM DDI 0020C. The vector floating point specification came from the ARM10 Thumb Family data sheet, document number DVI 0014A-04. Groups were to conform to their respective specifications but given the amount of time, changes to the specifications were made when appropriate.Initial changes were made to the specification. Support for older generations of the ARM processor were removed. Support for half-word memory transfers were removed. The two-phase clock was replaced with a normal one-phase clock, and also the processor was only to support little endian notation.3DESIGN PROCESSThe design of the processor was broken up into several stages, beginning with interface design. Interfaces were done first because they define the link between the ARM controller and the other modules. The Architecture group defined these interfaces for the other groups. This provided the added benefit of supplying a point of contact between the other groups and the Architecture group.Behavioral Algorithmic State Machines (ASMs) were designed next. ASMs were extremely important in the design process as they helped the groups flesh through the details of the specifications. ASMs were also a useful tool in rechecking the proper implementation of the interfaces between the modules. A significant portion of the time was spent in this stage of the design.From the ASMs, behavioral verilog code was then written. For the most part the translation of the ASM to verilog code was very straightforward. The verilog code was then tested to the point that each group could ensure that their module had basic functionality. For example, this meant that the ALU was tested to the point that given the correct inputs to the module, it was able to add, subtract, logical and, logical or, etc, correctly.The next stage in the design was to then integrate all the group’s modules and test the full chip with actual ARM assembly programs. This required that the Architecture group create a mixed verilog version of the controller and to also design a datapath. Also it was required that the designers create directed test programs targeting specific sets of instructions. At this point the main goal was to work out any timing errors and syntactic errors in the modules. A significant portion of time was also allocated to this stage in the design.As behavioral modules proved to function correctly in the full chip, groups were allowed to proceed to the mixed and structural verilog stage of the design. In this stage, groups were to convert their behavioral verilog code to mixed verilog code and replace their behavioral module in the full chip with the new mixed module. Testing of the mixed module would then continue, and once it proved to function correctly the group would move to the structural module.Once structural verilog was working, groups could then synthesize their module. The overall goal of the synthesized chip was to have performance similar to that of the ARM7, and a limit of sixty thousand transistors. We put a larger cap on the size of the processor since we are using a place and route tool to do our layout while ARM does custom layout.4ARCHITECTURE4.1IntroductionOrganization Nearly 3 months ago, the ARM7 Architecture group was giventhe following list of tasks: create a behavioral ASM of the ARM7instruction set and transform that into behavioral Verilog code,define the datapath and controller for this processor andimplement those in Verilog, and ensure proper interaction withthe main datapath modules. Furthermore, the Instruction Pipelinegroup was asked to implement the instruction pipeline, read dataregister, and the instructions dealing with read and write for theARM7 processor. Very early on, it became evident that each ofthese groups’ tasks were intimately related. Thus, the two groupsmerged into one Architecture group made up of ten eager designengineersProcedure It also became evident early on that completing the collective setof tasks before us would be no trivial effort. Even with acomplete ARM7 datasheet and several reference books in hand,we were faced with many design decisions and challenges. Thegiven documentation served merely as the starting point for theroad to a concrete implementation that was ours to pave. As thefollowing pages will show, we had a journey that was bothsuccessful and educational, and at the end of the road we reachedour goal of a completed ARM7 datapath and controller.4.2Datapath, Controller, and Instruction PipelineArchitecture Overview The main function of the ARM7 computer architecture is to fetch and execute ARM7 instructions. This happens in a 3 stage pipeline consisting of fetch, decode, and execute. The architecture fetches instructions one at a time, decodes each, and executes each instruction by asserting the appropriate datapath control signals.The two basic entities at the heart of this architecture are the datapath and controller. The datapath integrates an ALU, a multiplier, a register file, a barrel shifter and many other modules into a structure capable of supporting the execution of each ARM7 instruction that comes through the pipeline. The controller governs this datapath to ensure proper execution. Part of the controller’s responsibilities is communicating with the memory interface for both instruction and data transfers and talking to the FPU coprocessor to ensure that floating point instructions are executed properly. The controller is also concerned with handling exceptions, including resets, aborts, interrupt requests, fast interrupt requests, undefined instructions, and software interrupts.Functionality The basic movement of an instruction through the pipeline is asfollows. An instruction is fetched from the memory locationpointed to by the program counter (PC), which is maintained andincremented by the controller. The process of obtaining aninstruction involves handshaking with the memory interface usinga request/acknowledge wait loop. Once the instruction is fetchedinto instruction register one (ir1), it is passed to instructionregister two (ir2) on the next clock cycle, which is called thedecode stage. In our implementation, no actual decoding is doneon ir1, which follows the scheme found in the Arnold text used inthis class. Instead, decoding happens in the execute stage basedon the instruction in ir2. The decode stage essentially only passesthe instruction through the pipeline without parsing it. This wasone of the first major design issues about which we debated.Our reasons for finally choosing to do the decoding on ir2 wastwo-fold. First, because our textbook served as a good startingmodel for our Verilog implementation, we wanted to follow it asclosely as possible. Second, decoding on ir1 raised some difficulthurdles in terms of the proper timing for setting up datapathcontrol signals between the decode and execute pipeline stages.Implementation in Verilog seemed most straightforward if wewere able to set the appropriate control signals immediately afterdecoding an instruction, as opposed to scheduling those signals tobe asserted on the next clock cycle through the use of a complicated set of pipeline control registers between the decode and execute stages. This would have been especially troublesome in the face of multicycle instructions that stall the pipeline. Even with our method, ir1 still serves a purpose in that it holds the next instruction to be executed so that it will be ready to go in the next cycle without having to access the memory to get it.In the execute stage, the instruction in ir2 is checked against the condition flags found in the CPSR to determine if it will be executed. If so, and if the instruction is neither a branch nor a data processing instruction that modifies register 15 (the PC), the pipeline is scheduled to move ir1 to ir2 and fetch a new instruction from memory to ir1. Otherwise, the pipeline is flushed with NOPs because the current instructions will be skipped after the branch or data processing instruction that changes the PC executes.If the instruction gets past the condition check, it passes through a long set of conditional statements that check the opcode bits for each instruction until either a recognized ARM7 instruction is found or it is determined that the instruction belongs to the coprocessor. If such is the case, the architecture performs handshaking with the FPU coprocessor. If it is determined that the instruction belongs neither to the ARM7 core nor to the FPU, it is simply ignored and the pipeline advances.Within each subtree of this series of conditional decoding statements, every bit of ir2 is decoded and appropriate datapath control signals are set to execute the instruction. For multicycle instructions like loads, stores, and multiplies, handshaking wait loops are used to communicate with the appropriate module until the instruction is finished executing. Meanwhile, the pipeline is allowed to advance one cycle, and the current multicycle instruction in ir2 is moved to a temporary register called ir2_mult, where it can still be referenced until its execution completes.4.3Instruction SubsetInstruction Subset Overview Given the time constraints for completion of this project, we were forced to implement only a subset of the overall ARM7 instruction set. Even so, we have implemented enough instructions to make a very useful microprocessor.Our architecture recognizes all data processing instructions (with the exception of some forms of multiplication) as found in the ARM 7 instruction set. These instructions, which involve only registers and possibly immediate operands, execute in 1 clock cycle (with the exception of multiply instructions).As for multiplication, our architecture recognizes both standard multiply (MUL) and multiply with accumulate (MLA). These, however, take multiple cycles and thus stall the pipeline through the use of a wait loop with the multiplier module and with the assistance of a temporary ir2_mult register (which allows the pipeline to advance in parallel with a multicycle instruction’s second clock cycle).The architecture also recognizes branch and branch and link instructions. These instructions cause the pipeline to be flushed (using NOPs) because they cause a new value to be scheduled for the PC (register 15).Loads and stores each have only two types, as opposed to the many types available in the standard ARM7 instruction set. These are load word and load byte and store word and store byte. These instructions execute in multiple cycles via a handshaking wait loop that communicates with the memory interface. Also, the temporary ir2_mult register is used here.The instructions to transfer the status register to a general register and vice-versa, MRS and MSR, respectively, are also implemented in our controller. Swap and software interrupt instructions are implemented as well.Finally, floating point coprocessor instructions as specified by the FPU group are able to execute on this system. The design details of our ARM7 instruction subset are discussed in the following sections.Data Processing Instructions The Data Processing Instructions in the ARM processor are instructions that perform a logical or arithmetic operation on one or two operands. The first operand must always come from a register, and the second operand may be a register or an immediate value supplied in the instruction word. Several shifting options may be performed on the second operand by the barrel shifter. The two operands are routed to the ALU, the first directly, and the second through the barrel shifter. The ALU willperform the function specified within the instruction word andgenerate the correct value on the output bus and set flags(Carry,Zero, Overflow) if necessary. To complete the data processinginstruction, the ALU result and flags are routed to the register fileand are written to the appropriate registers if a write is indicatedby the instruction word.Algorithm The same general algorithm is followed for all dataprocessing(DP) instructions. We assume upon starting thisalgorithm that we have a properly fetched instruction stored inInstruction Register 2(IR2).First, we must determine that we actually have a DP instruction.If IR2[27:26]="00", then we can proceed with the DP algorithm.All DP instructions take a register as their first operand, and thisregister always comes from the same spot in IR2. Therefore, assoon as we determine that we have a DP instruction, we send theRegister File IR2[19:16] as an address for the register value thatwe wish to appear on the A bus. This signal must then be routedto bypass the multiplier and enter directly into Input A of theALU by supplying the correct control signal to the ALU_A_Selmultiplexor.The selection and routing of operand 2 begins at this point. First,we must determine whether operand 2 is an immediate value or aregister value. This can be determined by checking if IR2[25]=1.If it is, then we are using an immediate operand. In this case,IR2[7:0] is zero extended by the Sign/Zero Extend Unit, and sentinto the barrel shifter. The shift amount for the immediateoperand is supplied in IR2[11:8]. If this value is 0, it is a specialcase, and the barrel shifter is disabled, so that it will simply passthe value through. Otherwise, the amount in IR2[11:8] ismultiplied by two, and a shift type of Rotate Right is applied tothe immediate operand. The control signals for the Barrel Shifter,shift type and amount, are determined within the Shift AmountMaker Unit.If operand 2 is not an immediate, we know that it is a register.The address for the second register is specified in IR2[3:0] andmust be routed into the register file address port B. The value ofthis register will appear on the B bus and will be routed to theinput of the barrel shifter. The Shift Amount maker againdecodes IR2 to determine what type of shift is occurring. It willdetermine the shift type, where the shift amount comes from, andwhat the shift amount is. The output from the barrel shifter isconnected directly to Input B of the ALU.The signals are now waiting at the inputs of the ALU for anoperation to be applied to them. The ALU control signal is obtained by adding a zero to the front of IR2[24:21]. The ALU will perform the correct operation and place the result on the ALU result bus and update the status signals as needed.The final part of the data processing instructions involves writing the results back. First, to determine if the flags must be updated in the CPSR, we will look to see if IR2[20]=1. If this is the case, or if we have one of the non-destructive test commands, we will update the CPSR flags with the values from the ALU. To determine whether or not we will write the result of an operation to the register file, we again look at the ALU opcode. If it is NOT one of the nondestructive test commands, we will write the result into the register file, at the register address indicated inIR2[15:12].Multiply Instructions (MUL, MLA) Multiply instructions come in two types – the regular multiply instruction, MUL, and the multiply and accumulate, MLA. The MUL instruction computes the product of two register values and stores the result into another register. The MLA instruction stores the result obtained by adding the product to a third operand register.Algorithm The multiply instruction relies on a booth multiplier in thedatapath for its implementation. In the datapath, the multiplierinputs are connected to the A and C outputs of the register file, sothe first part of the multiply instruction sets up the two operandsgoing into the multiplier. After the operands are set up, thecontroller asserts the Multiplier_Enable signal to tell themultiplier to start the multiply process. It then waits for two clockcycles for the multiplier to respond to the request. The multiplierresponds to the controller's request by outputting a low on theMultiplier_Ready signal. This causes the pipeline to be stalledand the datapath cycles repeatedly until the Multiplier_Readysignal is back to high. As soon as the Multiplier_Ready signal ishigh, the multiplier outputs the result onto its output bus which isthen passed onto the A bus of the ALU.At the same time, a third operand specified in the instruction ispassed onto the B bus of the ALU. This operand is only valid forthe MLA instructions. At this time, bit 21 of the instruction op-code is checked to determine whether the instruction is a MUL ora MLA. If the instruction is a MUL, then the A input of the ALUis passed through without modification, whereas if the instructionis a MLA, the ALU is instructed to add the two inputs. ThenSTALL signal is then deasserted to let the pipeline functionnormally. Finally, the result of the ALU is written to the registerfile at the proper location specified by the destination registerfield in the instruction. The full functionality as specified in theARM data sheet for the multiply instruction was implemented.The simulation results conformed to the expected output. Branch/Branch and Link The instruction only executes if the condition is true. Theinstruction format contains a condition field, link field, and asigned 2’s complement 24-bit offset. To calculate the branchaddress, the offset is shifted left twice, sign extended to 32 bits,and added to the PC. The “L” bit determines if the branch is aregular branch or a branch and link. A regular branch occurswhen L=0 and a branch and link occurs when L=1. When abranch and link occurs, the old PC value is written into R14 andthen the appropriate branch is taken.The appropriate steps the controller goes through are as follows.First, the controller checks whether the instruction is a branch andlink or just a branch. If it is a link, then the incremented PC iswritten into R14. Next, the branch address is calculated andwritten into the PC. Finally, the pipeline is cleared by insertingzeroes into our instruction registers.Single data transfer instructions(LDR, STR) The load (LDR) instruction transfers either byte or word sized data from the main memory to the ARM7 register. Similarly, the store (STR) instruction transfers byte or word sized data from the ARM7 register to the main memory.Algorithm The implementations of both LDR and STR instructions are verysimilar. The instruction encoding of these two instructions isexactly the same except for bit 20, which differentiates between aload (LDR) instruction (bit 20 is 1), and a store (STR) instruction(bit 20 is 0).In the first cycle, the effective address for the instruction iscalculated based on the offset type specified in the instruction.The offset can be specified in two different ways as indicated bybit 25 of the instruction. The first type of offset is an immediatevalue which is encoded in bits 12 down to 0 of the instruction op-code. If the offset is an immediate, then this 12-bit value ispassed through the sign extender and the barrel shifter where it issign-extended and shifted by two, respectively. On the otherhand, if the offset is specified by a register value possibly shiftedby a certain amount, there still exist two possible choices fordoing so. The shift applied to this register value can either be animmediate value (bit 4 is 0) or it could be a value stored inanother register (bit 4 is 1).After decoding the proper type, the controller applies the correct shift amount to the barrel shifter which outputs the result into the ALU. Next, the calculated offset and the base register values are asserted at the inputs of the ALU and either added or subtracted depending on bit 23 of the instruction. The ALU output bus will then have the newly calculated memory address for the load or the store.After calculating the address for the load/store, the pre/post indexing and the write back bits are checked. When the pre-indexing is selected (bit 24 is 1), it indicates that the newly calculated address will be used to load from the memory. Therefore, in the case of pre-indexing, the ALU result is latched into the Address Register. Next, the write back bit is checked to see if write back is needed. If write-back is needed (bit 21 is 1), then the ALU result is written back to the base register. All this happens during the same cycle in which the ALU result is computed. In the case of post-indexing, the address register is directly loaded with the value from the base register. For post-indexed load or store, the write back is done by default so it does not have to check the write-back bit at all.In the cycle following the address calculation, a memory request is done by asserting the nMREQ line. The nRW signal is 0 for a load and 1 for a store. At the same time the memory request is made, the signal nSTALL is asserted to stall the pipeline. Also, the instruction currently in register ir2 is loaded into ir2_mult as the pipeline is about to enter a multi-cycle instruction. This is done because in the next cycle, ir2 is going to be loaded with a new value from ir1.Next, the pipeline continues to stall for multiple cycles until the nWAIT signal from the memory goes high indicating that the request is complete. In the case of a load, at the same time that nWAIT goes high, the memory puts the requested data on the D bus. The next step for a load instruction is to write this data into the register file. This is done by passing the data through the B bus and through the ALU into the register file. In the case of a store, the signaling of nWAIT high indicates the completion of a store.Since the memory interface requires the address to be stable throughout the period of load or store, an additional register was added to the datapath to store the ALU result or the value from the base register. This register is called the ALU Hold Register. The address is latched into this register just before the multi-cycle execution begins.The implementation of single data transfer instruction directlycorresponds to the ARM7 specification. All the featuresindicated in the data sheet were implemented exactly. The testingof loads and stores under various conditions outputted the correctresult in each case.MSR and MRS The MRS instruction moves the CPSR or SPSR_mode into ageneral register. The instruction format specifies a conditionfield, a source field (CPSR or SPSR_mode), and a destinationregister field. The necessary steps for the controller to performthis operation are as follows. The first step is to let the registerfile know the address, that the data to be written is from the PSR,and what the source PSR is. Second, the register write signal isenabled and the register is written to.The MSR instruction moves a general register into the CPSR orSPSR_mode. The instruction format specifies a condition field, adestination PSR, and a source register. The controller selects theregister to read from, passes that data through the ALU, and iswritten back into the PSR.Coprocessor Instructions Three general instructions were covered: Coprocessor RegisterTransfer (transferring register values from the register file to thecoprocessor and vice versa), Coprocessor Data Operations(general coprocessor ops), and Coprocessor Data Transfer(moving data from memory to the Coprocessor and back).The main interface is through the use of the CPA, CPB, nCPI, andthe nSTALL signals. These signals dictate the communicationbetween the control and the coprocessors. There are other partsof the datapath used as well, such as the memory signals for usein communication with the MMU.The main algorithm used in communication with the FPU isdocumented in the ARM7 manual. The main communicationbetween the Control and the FPU is through the use of the CPA,CPB, nCPI, and nSTAll signals. When a Coprocessor instructionis to be executed, the Control brings down nCPI. This tells theFPU that the instruction currently in the pipeline is a coprocessorinstruction. If the coprocessor recognizes it as an instructionintended for it, (such as a FPU instruction) then it brings CPAdown to 0. If the coprocessor does not bring down CPA, then atrap occurs. Otherwise, the Control busy waits on CPB. Whenthe coprocessor brings down CPB, then the Control finishes theexecution of the instruction. This is the basic algorithm for all thecoprocessor instructions.。
