Weekly+Meetings

= = toc =April 27, 2011 - DUE DATE=

We are hard at work determining the correctness of our solution. We ran into several bugs yesterday involving our stalling and forwarding logic that were not apparent with our earlier tests of the assembly and processor logic. After fixing those bugs, we were able to guarantee correct output, and can now focus on the final touches of our cache implementations. Our caches had been developed concurrently with our bug-bashing, but on a different system, so the combination of the two was an arduous process. Below is a picture of one of our correct outputs as of earlier this evening (it also includes statistics regarding our static branch predictor). =April 26, 2011=

The team met earlier today with Dongyuan about questions involving the implementation of the serial out port. Via his help and the help of another team, we were able to successfully create a "write buffer" for our output that fills and then empties through the serial port as time allows. This will help greatly with any last minute testing we will need to do of our processor in the hours before it is finally due.

At the beginning of our meeting today, we created a list of all aspects of the project left to complete. That way we can maintain a mutual understanding of any work left to be done. = = =April 25, 2011=

The team met to finalize processor design and ensure a bug free final product. Efficiency of our design was analyzed. We began writing the processor paper as a group and agreed to split up remaining sections should they not be done by the end of this meeting.

=April 17, 2011=

The team began working on the implementation of caches (of instruction and data type). Simultaneously, we also began research of the serial out port of the Altera DE2 board, in order to better display the output of our processor. From a serial port stance, we decided to base our implementation on the sample project that was given to the class at the beginning of the semester. The only changes necessary for this unit to function with our current design were to remove any dependencies with key input and replace them with programmatic triggers. A test program was also written in an attempt to gain further familiarity with the serial port interface.

The final project report was also started at this meeting, given that several parts of the report can be finished without the entire project being completed. This will also allow for more editing and review time come the end of the project.

=March 29, 2011=

The team met for the first time after Spring Break. After discussing the requirements for the branch prediction checkpoint, we realized that we had already designed a fair amount of branch prediction logic to our processor design during the pipelining and forwarding development process. The only requirements left for us to finish were to implement the stall and flush capabilities of branch prediction.

=March 14, 2011=

The team worked on forwarding and general testing of the now pipelined processor architecture.

=March 13, 2011=

Two team members have been getting Quartus errors upon compiling our new processor design. It appears, at this point, to be a bug within the Quartus application itself. The error statement from the bug is posted below. code Internal Error: Sub-system: AMERGE, File: /quartus/atm/amerge/amerge_kpt_op.cpp, Line: 220 cmp_merge_kpt_db Stack Trace: 0x3DD57  : amerge_mini_merge + 0x3A977 (atm_amerge) 0x30D5   : cfg_force_qexe_mode_off + 0x1E15 (ccl_cfg_ini) 0x3D4F2  : amerge_mini_merge + 0x3A112 (atm_amerge) 0x444DD  : amerge_mini_merge + 0x410FD (atm_amerge) . ..

End-trace

Quartus II Version 9.0 Build 235 06/17/2009 SJ Web Edition Service Pack Installed: 2 code This error was handled by installing the Quartus II 9.1 Service Pack, a 2 hour 1.9GB download.

The rest of this meeting was spent pair programming register modules needed for the pipelining of the processor. The team agreed to meet Monday or Tuesday night to implement forwarding. =March 6, 2011=

The team has decided to scrap all code from the first task written in VHDL in favor of rewriting the code in Verilog, a language that the entire team is more familiar with (due to its use in the Computer Systems course we took with Dr. Goddard). We believe this change will allow us to pipeline the processor more easily.

We have also all installed Quartus 9, in order to use its helpful waveform view as a debugger for the state of the processor at any given time. The switch to verilog, on top of the switch to Quartus 9, also allows us to see visual representations of processor compononents via pin diagrams, thus giving us a much more visual form in which to design the pipeline. =February 22, 2011=

Continued work on Task 1 objectives; namely, formalizing processor architecture changes and ensuring that the bubble sort algorithm was indeed functioning correctly on the processor. Difficulties were encountered when trying to create visual representations of the processor and specific module architecture. A waveform editor was also discovered to be missing from the team's install of Quartus. Discussion occurred to determine the best practice of PC address incrementation with regards to our currently implemented algorithm and ISA. Due to compatibility issues with Quartus 10, the team has decided to downgrade to Quartus 9. =February 21, 2011=

We met to discuss our approach to the project. All team members have designed a sequential processor with Quartus in CSE 230. We have decided to keep with a very similar instruction set. We defined Java as the language to use for the assembler. =February 18, 2011=

Our team met to discuss potential risks of the project. We set a later time to meet as everyone was busy. =January, 2011=

Our team has decided to sit together in class everyday for team bonding.