Simple Asynchronous Microprocessor

Transcription

1 Caltech CS/EE 181b Winter 2014 Prof. Alain Martin Simple Asynchronous Microprocessor By Kangping Hu March

2 1. Architecture Overview 1 SAM (Simple Asynchronous Microprocessor) is a 32-bit RISC Architecture. A top-level flow diagram is shown in figure 1. A list of major building blocks and their functions are described below: PC (32-bit program counter): tracks which instruction to execute next. IMEM (Instruction memory): contains the instructions. Decoder: decomposes the instruction. RegFile: 8 32-bit general-purpose registers. YMode: performs certain operations to retrieve y-operand. Dispatch: forks x-operand and y-operand, and send them to execution units. Branch: performs comparison with x-operand. ALU: performs arithmetic operations. DMEM: reads from or writes to data memory. Shift: performs left or right shift operation. Opz Merge: controlled merge of z-operand.

3 2 Figure 1 top-level flow diagram of SAM The register number rx, ry, and rz index which general-purpose register to read from or write to. x- operand (Opx) is directly generated from general-purpose register as gpr[rx], and y-operand(opy) is generated by a certain operation between gpr[ry] and the immediate (Imm) determined by the YMode control signal. They then act as inputs for the execution part (Branch, ALU, DMEM, and Shift). The operation inside each execution block is determined by the function (Fxn). z-operand (Opz) is one of the outputs selected by the unit control signal (Unit). It is then written back to one of the generalpurpose registers indexed by rz. The Branch unit generates branch flag for PC, indicating if the next instruction address will be PC+4, or Opy. It also generates a halt flag, indicating the end of the execution.

4 2. Description of Each block PC Input: Output: Opy, Branch Flag, Halt Flag PC The PC process is composed of a 32-bit register and an adder. At the beginning of each cycle, it will output PC to the outside environment and the adder. It will then wait for the branch flag, and decide updating the new pc from either the branched pc (Opy), or the adder output. It will also receive a halt flag, which once set, will suspend all the remaining processes. But since SAM is a non-terminating microprocessor, it will never actually stop. The halt signal here is merely for indicating the end of the testing program. Figure 2-1 PC Process

5 2.2. IMEM Input: PC. Output: Instruction. 4 The Instruction Memory reads in a binary test program, which calculates the sum from 1 to 100. Based on the input PC, the instruction in the corresponding address will be sent out. The testing program is shown below:.=0x8 jmp Start ; comment.=0x100 Start: li r1=100 li r2=0u ; upper immediate jmp r3=detour ; comment Label: ; comment add r2=r1,r2 sw r2,(100) lw r2=(r1+0x3ff) lw r2=(100) sub r1=r1,1 bne r1,label hlt jmp zero ; shouldnt get executed nop.=0x200 ; test comment Detour: jmp r3

6 2.3 Decoder Input: Output: Instruction. rx, ry, rz, YMode, Imm, Fxn, Unit. 5 Figure 2-3 Decoder The decoder takes the instruction, decomposes it, and sends the smaller pieces to corresponding processes: Unit = instruction [31 30], to Opz Merge and Branch Fxn = instruction [29 27], to ALU, Branch, Shift and DMEM Ymode = instruction [26 25], to YMode rz = instruction [24 22], to RegFile rx = instruction [21 19], to RegFile ry = instruction [18 16], to RegFile imm = instruction [15 0], to YMode

7 2.4 RegFiles Input: Data In (Opz) rx, ry, rz Output: gpr[rx], gpr[ry] 6 The RegFiles block is probably the most complicated one in this design. Its diagram is shown in figure 2-4. Inside the block, there is a State process guarding the sequential input of rx, ry, rz, Data In, and sequential output of gpr[rx], and gpr[ry]. The State process has three states: State 0: Addr_Sel selects rx, Data In is skipped, Decoder set one enable signal to high, Controlled Merge receives data from the selected register, Controlled Split output Data in gpr[rx] State 1: Addr_Sel selects ry, Data In is skipped, Decoder set one enable signal to high, Controlled Merge receives data from the selected register, Controlled Split output Data in gpr[ry] State 2: Addr_Sel selects rz, Controlled Fork receives the data and send the data to all registers, Decoder set one enable signal to high, One register stores the data Controlled Merge skips receiving data The Decoder receives the address, and set one of the enable signals to high. Depending on the state and the enable signal, one of the registers will either read out data or write in data based on the input state. The Controlled merge also takes in the enable signals so that data from only one register is received to prevent deadlock. The State Update Process loops the state variable in 0->1->2->0 sequence.

8 7 Figure 2-4 RegFiles Diagram 2.5 Ymode Input: Output: Imm, gpr[ry], YMode Opy The YMode block shown in figure 2.5 is used to generate y-operand from gpr[ry] and Imm. There is a controlled merge that takes in all the possible Opy values, and outputs one of them based on Ymode value. For sign extended operation, I used 16 buffers that constantly outputting 1, while for the unsigned extended, I used 16 buffers that constantly outputting 0.

9 8 Figure 2.5 YMode diagram 2.6 Dispatch Input: Output: Opx, Opy. ALU_Opx, ALU_Opy Branch_Opx DMEM_Opx, DMEM_Opy Shift_Opy The function of this process is to fork Opx, and Opy, and send them to ALU, Branch, DMEM and Shift processes. Originally, I was planning to do a controlled fork and controlled merge at both sides of the execution blocks. But I was encountered with a lot of deadlock issues, as all of the processes conditioned by Fxn inside the execution blocked (DMEM, Branch) will also need to be conditioned by Unit. So I decide just let all the executions run, and collect the wanted opz at the very end based on the Unit control signal. In this way, the design is simplified, but the price I paid is that the longest path is always executed.

10 2.7 Execution Blocks ALU Input: Output: Opx, Opy, Fxn Opz The ALU Block is shown in fissure 2.7.1, I used controlled fork and controlled merge at both end for flow control. The x-operand and y-operand will only be sent to one process. For each small ALU Blocks, I started with AND, OR, and Inverse in the prs level, and use those three to construct NOR, and XOR. The ADD unit uses ripple carry. For the SUB, I used 2 s complement with the ADD unit. Figure ALU Blocks

11 2.7.2 DMEM Input: Opx, Opy, Fxn Output: Data Out (Opz) 10 The DMEM Block is shown in Figure below. It consists of an ex_dmem process and the Data Memory. Opy is the addressing for DMEM, and Opx is the input data. Depending on Fxn, ex_dmem will send out different Commands through Cmd to DMEM. Fxn = 0 -> Fxn = 4 -> Cmd = True; Data Out = dmem[opy]; Cmd = False; Dmem[Opy] = Opx; Data Out = Opy; Figure DMEM Block

12 2.7.3 Shift Input: Output: Opy, Fxn Opz 11 Shift is a relative simple block as shown in figure Since all the shift operations will take about the same time to finish, I didn t put guard in the input fork, and let all four shift processes run in parallel. I then collect all the outputs, and select one based on Fxn. Figure Shift Block For each shift process, I just offset the input and output, add some buffers that constantly outputting zero or one, and connect the unwanted bits to sinks that will just return acknowledge one the signal arrived. The diagram figure below shows the Shift Right By 1 process. Figure Shift Right By 1

13 2.7.4 Branch Input: Opx, PC Fxn, Unit 12 Output: Opz Branch Flag, Halt Flag Branch Block consists of two major sub-blocks ad shown in figure One is the branch portion that will output the branch and halt flag conditioned on Unit. If the Unit is not for branch operation, a default branch and halt flag will be sent out. The other sub-block is to increment PC and output it as Opz. Figure Branch Diagram Figure BEQ In the branch portion, I used both controlled fork and controlled merge for flow control. The comparators are composed of basic AND, OR, and Inverse Gates. Take BEQ (Branch IF Equal to Zero) as an example in figure , I just OR all input bits sequentially, and invert the final output as the branch flag. BNE can be implemented the same way except removing the inverse. For BLT, I just need to check the first bit, and BGE is the inverse of that. For BGT, I need to check the first bit, and OR the rest of the bits, and BLE is the inverse of it. This sequential comparison will inevitably increase the latency. A better way is to do the comparison in a tree topology.

14 3. Critical Path and Test Result 13 Show below is the result of the test program. It is adding up the sum from 1 to 100, and the result is saved in data memory location [100]. Some threads are permanently suspended, indicating the end of the simulation. /dmem> dmem.chp[16:2] dmem[100] = 5047 /dmem> dmem.chp[16:2] dmem[100] = 5047 /dmem> dmem.chp[16:2] dmem[100] = 5049 /dmem> dmem.chp[16:2] dmem[100] = 5049 /dmem> dmem.chp[16:2] dmem[100] = 5049 /dmem> dmem.chp[16:2] dmem[100] = 5049 /dmem> dmem.chp[16:2] dmem[100] = 5050 /dmem> dmem.chp[16:2] dmem[100] = 5050 /dmem> dmem.chp[16:2] dmem[100] = error Error: deadlock 32 threads are permanently suspended: (susp-perm) /pc/pc/pc2_bit2[4] at pc2.chp[86:27] I examined the number of total transitions between the wires at pc output going up and down. The result is shown below. Assuming each transition takes 100 time unit, the longest cycle takes = 116 cycles (pretty long). After some further testing, the critical path is caused by the ADD and SUB units. (watch) /pc/inc/add[5]/xor2/or1/en:o down at time (watch) /pc/inc/add[5]/xor2/or1/en:o up at time /dmem> dmem.chp[16:2] dmem[100] = 199 (watch) /pc/inc/add[5]/xor2/or1/en:o down at time (watch) /pc/inc/add[5]/xor2/or1/en:o up at time (watch) /pc/inc/add[5]/xor2/or1/en:o down at time (watch) /pc/inc/add[5]/xor2/or1/en:o up at time The SAM files are stored in the Home/181b/SAM29 directory. The file names beginning with capital letters are process that not fully decomposed, and the ones with lower case are the bottom level chp files. The top modul is SAM11.chp. There is a tool.chp file and a gates.chp that contain some common chp and prs used by several processes, and a type.chp file that defines all the variable types.

15 4. The Design Process 14 I started this design with a high level sequential description of the SAM Architecture based on its reference. It was pretty straightforward except that I was not familiar with the syntax. Then came the decompositions using the meta-process. It was fine at the beginning. But as I broke the SAM into smaller and smaller pieces, I didn t isolate the processes very well, and I encountered with a lot of deadlock issues. Also it became harder and harder to modify the architecture, adding and deleting ports, as the pieces became smaller. So I ended up with adding quite a lot redundant state signals to keep the sequential operations, and redundant buffers. At some point, I had to simplify the design. And I decided just letting some of the processes run in parallel, avoid some nested guards, and collect the result in a controlled merge. Finally to the prs level, the deadlocks appeared again, either because I didn t set the initial conditions for the gates correctly, or because the enables are not connected properly, or because of instability issues. Eventually I managed to decompose most of the chp processes to prs level. Thankfully the simulation still works. I have been struggling with chpsim throughout this semester, fighting with deadlocks and syntax errors. I really wish it could provide more information about where the deadlock happened! Anyway, it turned out to be a pretty powerful simulator, and can catch all kinds of errors I have made. At the very beginning, I was planning to finish all the decompositions ahead of time, and maybe start the layout. But it seems that I have underestimated the complexity of the microprocessor. As I started the vertical decomposition, I realized that I needed to copy that many control signals, and the completion tress are everywhere. The price to get rid of clock is not that cheap.