EECS150 Lab Lecture 5 Introduction to the Project

Transcription

1 EECS150 Lab Lecture 5 Introduction to the Project Ian Juch Electrical Engineering and Computer Sciences University of California, Berkeley 9/28/2012 1

2 Note on Lab4 You should augment the testbenches we gave you to send at least another character immediately after the first (33) Even if you got checked off already 9/28/2012 2

3 Lab Logistics This is the last lab lecture for the semester The Friday lab lecture will be converted to a one hour check off/lab time No partial check-offs for project checkpoints No slip days for project checkpoints No late credit for design document due next week 9/28/2012 3

4 Overview of the Project Schedule (subject to change) Checkpoint Requirements Due Date 0 Design Review Document and Schematic 8PM 1 Pipelined Processor Implementation and Stalling 2 Cache Integration and Memory Map Modification 3 Keyboard Interrupt Implementation and Timers 3PM 3PM 3PM 4 Graphics Frame Buffer 3PM 5 Line Engine Acceleration 3PM 6 Audio Implementation 11/23@ 3PM 7 Extra Credit and Optimization: TBA 5PM Final Report 11:59 PM 9/28/2012 4

5 Project Overview: MIPS150 CPU Implement a 3- stage pipelined MIPS CPU The ISA we will be working with is a subset of the full MIPS 9/28/2012 5

6 Project Overview: Cache Integration and Memory Map Modification To load interesting programs and handle cool things like graphics, we need more space than the on-chip block ram affords us We will integrate a cache and modify the memory map accordingly to give us this extra space 9/28/2012 6

7 Project Overview: Interrupt Implementation Interrupts provide a mechanism for external devices to steal processor cycles without disturbing the normal software We will be implementing interrupts to handle keyboard input more efficiently 9/28/2012 7

8 Project Overview: Graphics Frame Buffer We will be accessing a frame buffer via memory map Each pixel corresponds to a memory address Write different RGB color values into those addresses to produce images Draw lines via software solution 9/28/2012 8

9 Project Overview: Line Drawing Engine Primitive hardware accelerated graphics You will see a significant decrease in the time it takes to draw lines 9/28/2012 9

10 Project Overview: Audio Still in the works Implementation 9/28/

11 Project Overview: Extra Credit If you have time at the end Very open ended, do whatever the heck you want to make your CPU/FPGA do really cool things We ll give you some ideas too 9/28/

12 Checkpoint 0: Design Review All teams will be required to have a design review next week during lab section with a TA TAs will give feedback and point out things you might have missed Start parsing the specification early (REALLY early) A design document will be due showing that you understand critical aspects of the design Design review requirements: CPU design schematic + brain Design document due during your design review with a TA, no later than Thurday 8PM DO NOT WAIT UNTIL THURSDAY AT 8PM TO BEGIN IMPLEMENTING YOUR DESIGN 9/28/

13 CPU Design Schematic 9/28/

14 Computer Architecture How hardware in the computer systems are specified to interconnect and function Decisions affect power, area, and performance Architecture decisions also affect what hazards you have to deal with 9/28/

15 Checkpoint 1: MIPS CPU Specification For simplicity, we are keeping it to a 3 stage pipeline Architected branch and load delay slots have been integrated into the compiler that we have provided All block RAM memory is synchronous read and write Register file is asynchronous read and synchronous write You are only allowed to use positive edge triggered logic Reset capability must be integrated into your design Stalling capability must be integrated into your design 9/28/

16 Skeletal Files You should already have this after you complete Lab 4 You will use git to pull in staff updates for each new checkpoint git pull staff master 9/28/

17 File Structure /hardware Contains everything that isn t software Run make here to synthesize /src All of your verilog goes here, including testbenches Try to keep this relatively clean MIPS150.v is the top level of your CPU; instantiate your submodules in here Do NOT modify ml505top.v; you will break things /sim Simulations are run from here with make Put.do files in /tests /results holds the simulation results./viewwave results/*.do to view waveforms 9/28/

18 File Structure /software Contains all the software tools Allows you to generate MIPS binaries by writing C or MIPS; just run make Will be useful for writing your tests Check out /example and /asmtest and use them as templates for writing your own tests Use mips-objdump D *.elf > *.mips to view the generated mips binaries in a nice readable format 9/28/

19 Memory Mapped I/O We will access I/O (and other peripherals in later checkpoints) by doing load/store instructions and setting the correct address bits to indicate which device is being accessed 9/28/

20 Block RAM Access Memory addresses are BYTE ADDRESSED Block RAM addresses are WORD ADDRESSED Block RAM stores 32 bit (4 byte) entries Low 2 bits correspond to byte offset Next 12 bits index into the block RAM Bit masking The we signal into the block RAM s is 4 bits wide, allows you to specify which bytes should be written You will have to figure out how to use the 4 bit we along with other logic to ensure that the correct bits are written The block RAM only spits out 32 bits You ll need to mask them appropriately based on the operation you are performing Read Appendix A.2 carefully 9/28/

21 Block RAM Endianness Bit addressing is BIG ENDIAN Byte addressing is LITTLE ENDIAN Pay particular attention to how you manipulate your data for lb, lhu, sb, shu 9/28/

22 Pipelining Hazards Structural hazards Not really an issue for us; no resource conflicts Separate instruction and data memories Multiple ports to our RegFile Control hazards Branch or jump determines the next instruction Solved by architected branch delay slot Data hazards For loads, solved by architected load delay slot For others instructions, you must solve with forwarding 9/28/

23 Architected Delay Slots Load delay slot The instruction directly following a load cannot depend on the value that was just loaded The compiler will reorder instructions to make this happen If not possible to reorder, there will just be a noop Branch delay slot The instruction directly following a branch or jump is always executed regardless of whether the branch/jump is taken or not Compiler reorders instructions, else noop 9/28/

24 Architected Delay Slots 9/28/

25 Notes on Testing The person who knows your design best is you Don t expect us to have a panacea for a bug in your design everyone s will be different There is no substitute for writing test cases and spending the time to do so Testing infrastructure allows us to assign more partial credit for non-working designs at the end We will be checking your repositories when assessing the final project grade for test cases 9/28/

26 Hardware Unit Testing Strategy First, test any relatively complex submodules in isolation with testbenches Use a combination of random and hard-coded tests, as in Lab 2, to flesh out small bugs Small mistakes are easy to catch in isolation, but will cost you hours or days while trying to find them as part of your whole CPU 9/28/

27 Integration Testing Strategy Have tests for each instruction To indicate success, write something like DEADBEEF into a register that you can access in simulation Write some simple programs that do sensible things, and check that they work as expected 9/28/

28 Simulation Simulation will be crucial to the success of your project When one of your assembly tests fails, you should trace through the waveform in modelsim to see where things went wrong Use the signal search function to search for specific opcode or funct values you may be interested in Drag in other signals to check that all your logic is working properly 9/28/

29 Basic Input Output System (BIOS) Provided for you in the software directory implemented in C Is basically a giant for loop that processes basic commands For this checkpoint, BIOS calls UART to get input characters Extra details will be released in a separate BIOS document. Understanding the BIOS is not critical to completing the project, but it may make you more comfortable knowing what s going on. 9/28/

30 BIOS Commands jal <address> sw, sh, sb <data> <address> lw, lhu, lb <address> more will be added later coe_to_serial <program.coe> <address> 9/28/

31 Checkoff Requirements Passing the EchoTestbench.v simulation and the BIOS simulation Be able to load and run the BIOS you should see a glorious carrot > prompt Be able to load (coe_to_serial) and jump to the Echo.c program Your reset works correctly You can toggle stalling and your stuff still works 9/28/

32 Common Sources for Bugs Control Logic your control signals aren t completely correct Forwarding Logic didn t forward correct value or to correct stage Endianness read the documentation carefully and make sure you understand it UART Protocol faulty UART from lab 4 that doesn t handle back to back transmissions or edge cases correctly Mismatched bus widths these mistakes are syntactically ok and will synthesize, but probably will not work properly. Check the synthesis warnings Not reading the lab document carefully often little bugs are the result of a small misunderstanding of the spec 9/28/

33 FAQ Q: How long should this checkpoint take? A: It depends on how many bugs you have, and how efficient you are at finding them. You will definitely need to put in significant time each day. Q: How do we run simulation? A: Run make in the sim directory and use./viewwave as per the instructions in lab 2. Follow the instructions in section 6 of the spec for setting up new simulations or adding more signals to the waveform. 9/28/

34 FAQ Q: It doesn t work what the hell do I do now? A: Simulation is a good place to start. You should test all submodules that are reasonably complex with testbenches and be sure that they work. Then you should write assembly programs to test ALL of your instructions. Tracking through waveforms is probably the most effective method of finding bugs. 9/28/

35 FAQ Q: Is this checkpoint possible? A: Yes. People have been able to complete it without all nighters. It s also unlikely that three back-to-back all nighters will get the job done. Budget your time and don t underestimate the check point. Q: Will the TAs be on Piazza at 2AM the day before the project is due to answer questions? A: Absolutely not. 9/28/

36 Things to Remember Start early Don t forget to eat and sleep Read the lab document carefully If you ve spent 12 straight hours in the lab debugging, its time to leave. Don t get discouraged if you can t find a bug; persistence will pay off You also have other classes LaBurrita, LaVal s, and Bongo Burger close at 10pm 9/28/

37 Questions, comments, or concerns? 9/28/