| EECS150 Components and Design Techniques for Digital Systems | |
|
EECS150 Spring 2009 Project |
|
Home | Old News | Calendar | Grades | Grading Status | Project Status | Documents | Staff | Syllabus | Schedule | Old Websites | Links | TA |
|
This page contains information regarding the project code, documents, and due dates. Its purpose is to track any and all revisions to each piece of material, as well as general changes to the project specification. Check back to this page regularly for updates.
When you initially open the ChipScope GUI, select "Xilinx Platform USB Cable" in the "JTAG Chain" section of the menu, instead of the Parallel IV item called "Xilinx Parallel Cable." After you make your selection, you should continue by running the default setup (the GUI should already have 3 MHz selected).
When working on lab 5, you might notice that you cannot access the Device Manager in Windows due to permissions related problems. To get the serial cable working, instead assume that your cable is connected to COM1 and running at 9600 baud. Important: Since the baud rate of the UART.v instantiation inside of FPGA_TOP_ML505 is 115200 baud (this might change in the future), you will have to manually change the 'UARTBaud' parameter on line 1064 of FPGA_TOP_ML505 to 9600. Again, this might change in the future. Stay alert for updates!
Specifically, the Ready bit should not be thought of as an indicator that there is 'ready' data in each data register. Instead, it should be thought of as a way of telling the CPU that the CPU can safely interact with the CPU/UART Adaptor. Note that this means different things based on the direction of the CPU/UART Adaptor that you are talking about. On the UART->CPU side, ''Ready==1'' means the CPU can safely read a byte of data. On the CPU->UART side, ''Ready==1'' means that the CPU can safely write a byte of data. See ChipScopeSerial Section 4.1.1 for details. NOTE: This clarification implies that the **current** copy of Echo.s is CORRECT.
Please see the *.s file for the assembly code that makes up the test and for instructions on how to use the test. See the *.hex file for a hex dump of the code contained in the *.s. Note: only 8 of the 9 tests, that will be used for checkoff, are currently in the test suite. Please see the *.s (line 293) for details. The last test will be added ahead of checkoff time, but make sure to build sufficient test cases for lw/sw that test lw/sw on your own (if you are wondering, the 9th test is responsible for testing lw/sw).
The boot monitor will now be released later in the week as a part of checkpoint 3 but not required as a part of the checkpoint 2 checkoff process. Checkoff for checkpoint 2 will consist of Echo.s only.
There will not be a written specification for checkpoint 2. All information regarding the checkpoint can be found in lab lecture 8 (linked below) and is summarized here for convenience.
Your deliverable for checkpoint 2 is to get your MIPS150 processor working on the XUPv5 boards. You can use any of the material we have given you so far this semester to best accomplish this task. To verify your implementation during checkoff, you will be required to run several programs on your processor for the TAs. One can be found below (Echo.s). Please read this program's description for details.
Please note that while partial credit was given for passing some but not all of the tests for checkpoint 1, such partial credit cannot easily be assigned for checkpoint 2. What you will find is that your processor either will or will not be able to implement the Echo and Boot Monitor programs that we provided. If you have a bug, you will either see nothing at the console, the console will get spammed by a character overflow, or something along those lines. As such, it is extremely important that you have a working processor implementation by checkpoint 2 checkoff. If you didn't pass all of the checkpoint 1 checkoff tests, make sure that you do before you try to push to hardware. Pushing to hardware with a broken processor is futile!
FastClocks.zip contains all of the code and prerequisite code that you need to drive the fast running (78.9473684 Mhz) clock that you will need to run at for final checkoff. Please follow these instructions:
You will not get checked off unless your design runs with the clock that is driven by DVIClockGenerator! Furthermore, your design will be incompatible with any code released for checkpoint 3 or 4 if it cannot meet the timing requirement stipulated by this clock.
Fixed a load delay slot bug in the outchar routine.
This version of Echo.s will perform the basic echo functionality that you saw in Lab 5. As a matter of fact, a working MIPS150 implementation on hardware, running this code, will look exactly like Lab 5 did, except that it will not print 'From dusk till dawn' if it sees 'CS150.' You can add this to the assembly code if you want (it is not required)!
See the revision log in Echo.s for details.
Fixed an obscure bug where file sent would send to the second address after the correct start address (this only manifested itself in some designs).
Initial release.
Changed 'I2CBB.edf' to 'iic_init.edf'
Initial release.
To make the DVI modules require password authentication, they have been placed on the Calendar page (week 13).
Initial release.
Initial release. To use this code, load the color map with a set of values (feel free to use the palette posted by the staff) and load this code to the start of instruction memory. Then, jump to instruction memory using the monitor.
Initial release.
Clarified how the line engine starts an operation (added information about the difference between writing to address 0x8040_0040 and address 0x8040_0044.
Initial release.
Initial release. See Lines.s for instructions on how to use the line program. To load the line program itself, send it to address 0x00400000 using the console GUI (as usual). You will notice that we have included two additional **.hex files (Campanile and LinesExampleData). These are two pictures that you can draw using Lines.s. We will release more pictures (in the **.hex) format as we render them. Feel free to come up with your own!
Fixed a bug where $t0 would get overwritten after the clear routine returns.
Initial release.
Initial release.
To sign up for check-off (early or regular):
Initial release.
| Last Updated: 05/12/2009 by | |
| Chris Fletcher |