Vikram Anand's Lab Notebook

Week 01

August 22, 2007 (3 hours):
We met as a team after class to discuss our preliminary project proposal. We initially planned to implement our version of the popular Guitar Hero game using a real electric guitar rather than the simple push button device used in the actual Guitar Hero game. However, after reading through some of the online research regarding the detection, filtering, and manipulation of real electric guitar signals, we determined that this idea was no longer feasible. Either we would have had to purchase a very expensive conversion device to transform the guitar signals into digital output, or we would have to perform the signal conversion ourselves, which would be much too challenging of a task to accomplish in one semester.

August 23, 2007 (5 hours):
We met as a group to complete our preliminary project proposal (Homework 1) and to discuss other project ideas, since our initial guitar signal processing idea was deemed unfeasible. We tried to brainstorm different ideas regarding how to interpret the notes being played on the guitar without needing to process the actual signal output. One idea we considered briefly was to use a camera to determine the position of the hands on the guitar, which could then be used to identify which string and fret were being played; however, the image processing required for this would be much too tedious to be considered practical. Another thought was to use a microphone to record the guitar sound and then determine the note from the recorded frequency. The problem with this method is that the microphone would also pick up all of the other harmonic frequencies, lingering notes, and noise present in the guitar output, which would then be very difficult to filter and interpret. Although these previous ideas were very quickly disregarded, there was one particular idea which we discussed at length. This idea took advantage of the fact that the guitar frets and string themselves were made of conductive metal, and could thus support current flow through them. We conjectured that by making various wired connections from a microcontroller to the guitar frets and strings, we could detect which fret was being held down by measuring the current through that connection. Unfortunately, this method would not allow us to determine whether the string was actually strummed in addition to the fret simply being held down.

Realizing that the guitar idea has a whole may not be possible, we considered completely different project proposals. One project idea closely related to our initial plans was to use a MIDI keyboard as our input device rather than an electric guitar, and hence the game would teach the user how to play a keyboard rather than a guitar. The advantage of using a MIDI keyboard would be that the data format of the output signal is much easier to interpret.

An unrelated project idea we considered was to use a cellular phone to control a household appliance, such as an oven. The concept was that a person could remotely send a text message to his oven at home, instructing it to begin cooking a meal at a specific temperature and over a given duration. As a result, when the person arrived at home, their meal would already be cooked and ready to eat.

Our final project proposal was an intelligent Poker table. Using several cameras in conjunction with image processing, our table would be able to determine which cards a player had in his hand, which would then allow our game algorithm to calculate the odds of each player winning the round. We also planned to keep track of the number of chips each player had using force transducers to detect the weight of each stack of chips. Each player would be provided with an LCD screen displaying the given bets, chip counts, and possibly the odds of each player winning depending on whether the user wanted to utilize this feature for learning purposes. Finally, we considered keeping track of the winnings and, to some extent, the playing strategies of the players, thus providing play statistics if the user wished to see them.

After discussing all of these ideas, we ultimately decided to include the three new aforementioned ideas in our preliminary project proposal document.

WEEK 01 SUMMARY
Accomplishments: Determined that the initial guitar idea was not feasible. Brainstormed several new project ideas, and submitted them in the preliminary project proposal.
Weekly Work Total: 8 hours
Project Work Total: 8 hours

Week 02

August 28, 2007 (4 hours):
Our group met in order to finalize our project idea and to specify our PSSCs for our project. The feedback we received from Professor Meyer and Karl on our preliminary project proposal was useful in helping us determine which of the three project ideas would be most feasible. The comments regarding our initial proposal suggested that the oven and poker table ideas would be the most difficult to implement for several reasons. Regarding the text message controlled oven, we would need to determine how to prevent other cellphone users from messaging our oven. Also, we would require some method to provide feedback from the oven to the user, confirming that the meal was prepared correctly. In regards to the Poker table idea, feedback suggested that the image processing of the card values would be substantially more challenging than we would expect. Although there were also some concerns raised by Karl and Professor Meyer about our MIDI keyboard idea, the difficulties seemed easier to overcome than those in the other project ideas.

Ultimately, we had to weigh in the preliminary proposal feedback along with our own personal desires in order to decide which project idea we would pick. After much deliberation, we decided to implement the MIDI keyboard project, and created our PSSCs accordingly.

August 30, 2007 (4 hours):
We met as a team to write our final project proposal (Homework 2) as well as to modify our PSSCs based on previous discussion with Karl and Professor Meyer. In addition, we delegated various future project reports to each team member. Our final PSSCs, project description, initial block diagram, and report delegations are all provided in the Final Project Proposal.

WEEK 02 SUMMARY
Accomplishments: Finally decided to implement the MIDI keyboard project. Developed PSSCs and wrote Final Project Proposal.
Weekly Work Total: 8 hours
Project Work Total: 16 hours

Week 03

September 4, 2007 (2 hours):
We met as a team to determine our microprocessor requirements, in terms of memory capacity, modules, number of pins, etc. In addition, we wanted to clarify how exactly we would achieve the graphics output we desired. First, we agreed that we would need PWM capability in order to drive speakers, and would require ATD modules in order to control speaker volume or song tempo via knobs. We also tried to estimate how much processor memory was necessary in order to provide the sound and graphics capability needed. We found that although the MIDI songs themselves could possibly be stored directly on the processor (smaller MIDI songs only occupy 3-10kB of memory), the graphics output would require data on the size order of Mb. As a result, we considered several different options. First, we could simply interface the microcontroller with additional Flash or SRAM blocks as needed in order to increase the effective memory bank size. Another thought was to use a separate VGA controller in addition to the main processor core, which would allow the processor to allocate its memory solely towards data calculations and sound output, while the VGA controller would assume responsiblity for buffering the graphics display. We also hoped that the user could input their own MIDI songs into our device via a USB Flash drive interface, and so we required a microprocessor with either enough I/O pins to interface with a USB connector, or with onboard USB functionality available.

WEEK 03 SUMMARY
Accomplishments: Determined some of the basic criteria governing our microprocessor selection.
Weekly Work Total: 2 hours
Project Work Total: 18 hours

Week 04

September 9, 2007 (1.5 hours):
We all met to discuss the Design Constraint Analysis (Homework 3) document due on Friday this week. Several days ago, Curtis had spoken with Chuck regarding an Altera development boardwe could use to test our software on. The board not only had the rightmodules and connectors available to test VGA graphics output, but it also contained a special Altera Cyclone II FPGA chip with integrated Nios processor. Essentially, we had found a single chip which could combine the computational power of a microprocessor with the graphics processing capabilities of a VGA controller. Not surprisingly, we readily agreed to use this FPGA chip as our main processing unit.

In addition, because the Design Contraint Analysis required a detailed listing of parts and an explanation of why those parts were chosen, we divided the various components of our device among the four of us. Curtis was responsible for determining the exact microprocessor, possible external memory, and development board specifications, Tom was responsible for developing some preliminary pseudocode and software flowchart, Brian was responsible for the report itself as well as a hardware block diagram, and I was designated to find a suitable VGA monitor and power supply regulators.

September 12, 2007 (2 hours):
I searched online independently for a display as well as voltage regulators. I was looking for a monitor with a minimum size of 19" widescreen, built in speakers, VGA compatibility, and low cost. With all of these criteria in mind, I ultimately chose the I-Inc iF191DPB.

When searching for voltage regulators, I first located a datasheet describing the exact voltage requirements of the Cyclone II FPGA. In addition to finding the required voltages for the FPGA, a table was also given in the same document listing the recommended voltage regulators for the chip, ranging from 5.0 V output to 1.2 V output.

The only problem I faced regarding the voltage regulator selection was that I was unsure whether we needed a linear regulator or a switch-mode regulator.

September 13, 2007 (1 hour):
We all went to the senior design lab in order to discuss component selection issues with the T.A.s. First, I inquired about the advantages of using linear versus switch mode regulators. The linear regulator has the benefit of being very simple to implement and having a low output voltage ripple; however, this regulator also is the least efficient and therefore generates the most heat. The switch mode regulator is much more efficient in its use of power and runs much cooler; unfortunately, there is substantially more external circuitry needed in addition to the regulator IC itself, and controlling the output voltage requires pulse width modulation. After discussing these factors with the T.A.s, we all agreed that the improved efficiency of the switch mode regulator was likely not worth the added difficulty in implementing and controlling the circuit. Furthermore, even though the linear regulators produce more heat, the fact that none of our components would be drawing an excessive amount of current indicates that the heat dissipation of these regulators would be fairly low; also, we could easily remove excess heat by using one or more heatsinks if necessary.

Another concern we discussed with the T.A.s is how the USB functionality could be implemented. We hoped that the user could insert a small flash drive into a USB connector and download the MIDI songs stored from the drive to our device. However, we learned that unless we developed some type of file transfer system, there would be no simple way of selecting what data to retrieve from the drive. Furthermore, it would be difficult to arrange the downloaded data in order to determine how many songs were loaded from the drive. As a result, we decided to simply restrict the flash drive to only having one MIDI song at a given time, thus allowing us to simply retrieve all of the data from the drive (no selection algorithms required) and store it as an individual song.

We also tried to get a better estimate of the memory and calculation speed requirements for our microprocessor, which we agreed would be the Altera FPGA found earlier by Curtis. We found that the largest variant of the Cyclone II we could use (the EP2C20) would have 18,752 logic elements and 52 4 kbit RAM blocks (Reference). Although we were unsure if these amounts would be sufficient for the graphics rendering we wanted to achieve, the T.A.s assured us that we could implement external SRAM blocks if necessary to increase the effective memory capabilities of our processor.

Finally, we determined the various power requirements for our other project components in addition to the microprocessor. We found that the USB receiver would need a 5V supply, and thus it would be advisable to use a 9V wall adapter input, and then step this voltage down using a 5V regulator. In addition, the processor core itself requires a 1.2V source, while the I/O pins require voltages ranging from 1.5V to 3.3V depending on which blocks are used and what output modes are desired.

September 13, 2007 (2 hours):
After our meeting with the T.A.s earlier today, I searched online for the power components discussed earlier: 1.2 V/3.3 V Regulator, 9 V Power Supply, 5 V Regulator, and Power Supply Jack.

WEEK 04 SUMMARY
Accomplishments: Discussed specifications for and selected various components of our project. Individually, I found power regulator components as well as a VGA display. Bryan wrote the Design Constraint Analysis for our team.
Weekly Work Total: 6.5 hours
Project Work Total: 24.5 hours

Week 05

September 18, 2007 (6 hours):
I met with Tom before our senior design class in order to test the running/compiling capabilities of the board, which we had acquired through Chuck. We read through some of the online documentation describing how to write, compile, and run programs on this board. Although we attempted to run a small program, we were faced with a software error when we attempted to do so. Finally, we discovered that we needed to download a particular driver for our board, which would then allow it to function properly. We took a break for an hour to attend our senior design class, but afterwards our whole team met in the lab to continue working. Curtis did some research regarding the manipulation and interpretation of MIDI files, Tom continued to work on programming graphics output on our FPGA board, and Bryan and I focused primarily on finding OrCad objects to represent the various components we would need to complete our schematic. Although we were able to find some of the objects online, Bryan and I had to physically create a number of components in OrCad Capture. Also, I found that our evaluation board used a 1.8 V regulator in addition to the other voltage levels specified previously. Even though we may not need this particular voltage level for our application, it is still good for us to have this part available if need be. Thus, I suggested that we also add a 1.8 V regulator to our parts list. Finally, I noticed that the regulator components used on the evaluation board were different than the ones suggested by Altera's own Cyclone II document. Although I was now unsure whether to use the evaluation board regulators or the recommended regulators, I hoped to find an answer in the next few days.

September 19, 2007 (2 hours):
We all met in the senior design lab to do more work on our project. Bryan and I continued to search for schematic components and draw the ones which we couldn't find online. We also discussed some MIDI file information Curtis found. We finally began to understand how all of the hexadecimal sequences in the MIDI file would be interpreted by a processor. Tom still worked on programming the VGA output. Finally, I attempted to estimate the number of I/O pins we would need for our application. Using the Altera FPGA Reference mentioned previously, I discovered that the EP2C35 used on our evaluation board had 475 I/O pins, whereas the EP2C20 we intended to use would only have 142 I/O pins. Using the Evaluation Board Schematic, I counted that 438 I/O pins were being utilized by the EP2C35 FPGA. From that number, I subtracted the pins being used by the EP2C35 that we would not need to use on the EP2C20, such as pin connections to 7 segment displays, toggle switches, ethernet, etc. After subtracting the extra pins, I found that we would need 144 I/O pins to achieve the desired functionality. However, because the onboard components we plan to use for the final project differ slightly from the evaluation board components in terms of wiring and available pins, this figure is merely an estimate of our I/O pin consumption. We are still trying to determine how we can control our input and output using the fewest number of FPGA pins, but if we find that the 142 pins available on the EP2C20 are insufficient, we could simply use multiplexers to increase our effective number of pins.

September 20, 2007 (1.5 hours):
We all met as a team in order to update our parts list. Once all of the dimensions for our parts were found, Bryan would make a component layout diagram and then send this to Curtis. Curtis would then use these dimensions to determine an overall size for our project container. I searched specifically for the dimensions of the power supply regulators. While searching for the dimensions, I realized that although the 5V regulator I had chosen previously had the advantage of very low current output, because all of the other regulators were from the LD1117D series, there may be some mismatch between the current and voltage specifications. Although the chance of any incompatibility was quite low, I decided to be safe and simply have all of the voltage regulators (5V, 3.3V, 1.8V, and 1.2V) come from the same LD1117D family. Finally, I found the physical dimensions of the regulators, and redrew the OrCad regulator objects so that they would all be from the LD1117D series. Provided here is the most recent Parts List.

WEEK 05 SUMMARY
Accomplishments: Began development of schematic components. Determined approximate I/O pin requirement. Updated the types and dimensions of voltage regulators. Curtis wrote the Packaging Specifications and Design report.
Weekly Work Total: 9.5 hours
Project Work Total: 34 hours

Week 06

September 24, 2007 (3 hours):
We met in the senior design lab to work on ordering parts and developing the schematic. Because our FPGA consisted of 240 pins, it was impossible to show all of the FPGA pinouts on a single schematic page. Thus, the FPGA needed to be split between two schematic pages, one showing only the FPGA power and ground connections, and the other showing the I/O pinouts. Although we found the FPGA (EP2C20) power and ground schematic symbol online, I had to create the I/O pinout schematic part for the FPGA in Capture.

September 25, 2007 (2 hours):
We all met in the senior design lab to discuss project tasks to be completed over the next week. Curtis would focus on determining how to read and manipulate MIDI files, Tom would learn how to implement the graphica processing and VGA output, and Bryan and I were focused on the schematic and PCB design. We looked briefly at the external DAC components (resistor, capacitors, and diodes) and determined that we would need three 1K ohm resistors. I also completed the Hardware Narrative powerpoint to be presented in class tommorrow.

September 26, 2007 (5 hours):
I wrote a large portion of the Theory of Operation and Hardware Narrative report. While writing the report, I investigated the hardware features of our processor. Traditionally, many processors have specific modules (such as SPI, PWM, ATD, etc.) intended for different functions, and the pins corresponding to these modules are used accordingly. However, our Nios processor did not have any of these traditional modules, but simply utilized the FPGA circuitry and the PLL (Phase-Locked Loop) blocks for all necessary operations. We determined that the PLL block would be unnecessary for our application because we did not need to manipulate the 80 MHz FPGA clock in order to produce an appropriate DAC or MIDI synthesizer clock; rather, we intended to toggle a general-purpose I/O pin to produce adequate clock signals. Thus, the only actual hardware module used by the processor was the FPGA itself. Furthermore, I found that the FPGA pins themselves had a large variety of declaration types, ranging from differential to single ended standards, 1.8V to 3.3V voltage levels, or CMOS versus TTL compatibility. Based on the datasheets of the components we were using, the majority of which operated at 3.3V, I determined that the I/O pin standard should be set as 3.3V LVTTL (single ended).

September 27, 2007 (11 hours):
I finished the Hardware Narrative report and partially helped Tom and Bryan finish the preliminary schematic. For example, I made the voltage regulator and oscillator schematic symbols and determined their pinouts/connectivity. Most of the time was spent constructing the OrCad symbols for various components. In particular, the FPGA schematic component (which consisted of separate power/ground and I/O blocks totalling to 240 pins) required a great deal of time to complete. Not only did we have to determine which pins performed which functions, but we had to carefully select exactly which of the I/O pins we wanted to use based on how we would layout the other components around the FPGA. For example, we wanted to place the DAC to the right of the FPGA (the right face of the FPGA corresponds to pins 61-120), and thus it was important that we only use availbale pins between 61 and 120 for our DAC inputs. Here is the final Hardware Narrative (HW 5) report and the most recent schematic .

WEEK 06 SUMMARY
Accomplishments: Wrote the Theory of Operation and Hardware Narrative (HW 5) report. Helped construct some of the schematic symbols and researched the internal architecture of the FPGA.
Weekly Work Total: 21 hours
Project Work Total: 55 hours

Week 07

October 1, 2007 (2 hours):
We all met in the lab to continue working on the project. I looked briefly into how to convert the OrCad Capture schematic to an OrCad Layout PCB drawing. By reading some help documentation in the OrCad software suite, I found that we would have to generate a netlist from our schematic drawing once any errors were corrected. Furthermore, we would need to somehow link the schematic parts to footprints, which we had not yet created, in order for it to render in Layout. We still need to research this process more in order to fully understand how to achieve this conversion. We planned out the remainder of the week in terms of finishing the schematic and constructing the PCB layout.

October 2, 2007 (5 hours):
We continued to examine how to properly import the schematic into OrCad Layout to contruct the PCB drawing. I also researched our RS-232 translator and how we planned to program our processor. Although we felt initially that programming the processor could be achieved using the RS-232 interface, we gradually became more and more hesitant to use this approach. This hesitation arose primarily because the USB Blaster hardware (which was used to program the processor on the development board we obtained) utilized many more pins on the FPGA than the RS-232 interface, including several dedicated configuration pins that we later discovered when examining the FPGA pinouts in detail. We felt then that the two RS-232 connections to the FPGA may not be sufficient to configure it, and we began to explore other options as a result.

Fortunately, I discovered that Altera sells a USB Blaster or ByteBlaster cable, which consists of a 10 pin ribbon cable attached to a box containing all of the programming hardware within it. This cable was directly compatible with a serial configuration device (also sold by Altera), which we could easily purchase an implement on our board. The serial configuration device would be connected directly to the FPGA while also connected to a 10-pin header. This header would serve as the attachment point for the USB/ByteBlaster cable, which would obviously be connected to our computer at the other end while programming the processor. Furthermore, the serial configuration device could also be used as a serial flash memory storage device. Thus, our entire RS-232 interface and Flash module could be replaced by a single serial configuration device and 10 pin header. Another significant advantage of this implementation is that because our pin usage would decrease significantly (the original parallel Flash module we had used around 30 pins), we would now be able to add an additional SRAM module to store more graphics data. We all enthusiastically agreed to pursue this option, hoping that Altera would provide us with a sample USB/ByteBlaster cable.

Finally, we also examined some of the discrete components (resistors, capacitors, etc.) on our board. We decided that rather than using a fixed resistor for the reference voltage input to the DAC, we would use a potentiometer; because the reference voltage affects the intensity of the DAC video output, using a potentiometer would allow us to tweak the video output strength in a convenient manner. Also, we found that we would need to ask one of the course T.A.s about how to properly attach bypass capacitors on a PCB and how close they need to be placed to various components.

October 3, 2007 (8 hours):
I looked more into how we would implement the DAC and MIDI clocks. Although we had originally planned to toggle a GPIO pin to produce our clock signals, Phil was slightly hesitant about not having a more robust DAC clock in our system. As a result, I decided to research how we could implement the PLL blocks in the FPGA in order to produce a very clean, rigid 40 MHz clock signal for the DAC. I found some documentation describing the operation of the PLL and global clock network inside the FPGA. My preliminary assessment of this information was that it may not be worth the effort and complexity to decipher the PLL operation. As a result, I investigated purchasing a separate 40 MHz oscillator and tying it directly to the DAC clock input.

I also spent some time researching the use of capacitors for various devices. I found an Altera Power Supply Integrity document which provided several important recommendations for capacitor usage. For example, it stated that bypass capacitors needed to be placed right at the power and ground pins for the FPGA, and larger decoupling capacitors (genreally tantalum or electrolytic) would need to be placed further away from the FPGA. Also, it provided an equation for approximating the net capacitance we would need to provide on the board based on voltage levels, the number of pins, and clock frequency. We were however unsure of how exactly we needed to place the capacitors on the actual PCB. Because the capacitors would be soldered on the bottom layer of the board, would it be necessary for us to place vias all the way up to the power and ground pins of the ICs, or could we simply via the capacitors to the power and ground planes near the ICs? We hoped to address some of these PCB layout concerns with the course T.A.s.

October 4, 2007 (20.5 hours):
The day was spent making final corrections to the schematic and routing the PCB ratsnest. All of us took part in correcting small errors in our schematic, modifying part footprints in Layout, and routing all of the PCB traces. The most significant change we made to our schematic was to reassign pin numbers to our FPGA based on a new component layout we had agreed upon. We finally completed the PCB Layout Narrative (HW 6) report.

WEEK 07 SUMMARY
Accomplishments: Discovered Serial Configuration Device/ByteBlaster combination to replace RS-232 interface and Flash module. Researched clock implementation options as well as capacitor layout information. Helped adjust the schematic, create/modify PCB footprints, and route PCB traces.
Weekly Work Total: 35.5 hours
Project Work Total: 90.5 hours

Week 08

October 9, 2007 (0.5 hours):
Tom, Curtis, and I met in lab to print copies of our schematic and PCB layout. These documents will be given to the course staff tommorrow when we have our Progress Briefing tommorrow.

October 10, 2007 (3 hours):
We had our Progress Briefing this morning with the course staff, who gave us several suggestions for improving our project. Professor Meyer and Karl felt that although using a separate oscillator for our DAC would provide a very stable, robust clock, toggling an FPGA I/O pin would provide enough accuracy to serve as a DAC clock; thus, we decided to remove the 40 MHz oscialltor from our board. We were also instructed to run headers to the data and address buses of both SRAM modules, thus allowing us to verify the SRAM signals. Finally, we were told to place bypass capacitors on the power and ground connections for the SRAM modules. The remaining suggestions were fairly minor in comparison, relating only to typographical errors in our schematic or PCB drawings.

We later delegated tasks to be completed for our Design Review Presentation tommorrow. My job was to present the PSSCs, the block diagram, and a portion of our schematic/theory of operation. Later tonight, I created the powerpoint slides corresponding to these sections of the presentation. Here is out final Design Review.

October 14, 2007 (2 hours):
I began calculating the current requirements for various devices on our board. Although we originally thought that the current ratings for our voltage regulators (800 mA) would be sufficient, as we made changes to some of our components, we did not recalculate the total current consumption. I reviewed all of the component datasheets to acquire a reasonable estimate of what the total current consumption would be. I did not however complete the calculations today.

WEEK 08 SUMMARY
Accomplishments: We gave our Design Review presentation and received some feedback regarding our project. I began to examine more carefully the current requirements of our components
Weekly Work Total: 7.5 hours
Project Work Total: 97.5 hours

Week 9

October 15, 2007 (3 hours):
I completed the power calculations , and determined that in order to have a reasonable safety margin for current, our 3.3V regulator should be able to supply a current of at least 1 A. After some searching, I finally ordered three 1.5A/3.3V voltage regulators, as well as two 80 MHz oscillators which we had not yet purchased. I also asked Phil briefly about how to update our PCB layout file with the changes we made in the schematic, while still preserving the traces we constructed. Unfortunately, we were unable to determine why the software was not allowing us to update our PCB layout.

October 16, 2007 (2.5 hours):
I made some significant alterations to our schematic because Professor Meyer recommended we put headers on the address and data buses for both SRAM modules. After trying to fit the new headers on our already crowded schematic page, I determined that the simplest way to add these new headers would be to place the SRAM modules on a separate schematic page (page 3 in our final schematic ).

October 17, 2007 (3 hours):
We were ultimately unable to determine why the OrCad software would not allow us to update our PCB with the changes we made in the schematic. Thus, we decided to completely redo our PCB layout. This time however, we felt that we could alter the pin selection to make PCB routing more convenient and space efficient. Initially, our DAC was located on the pin 61-120 side of our FPGA, which consisted of about 11 power pins with their corresponding bypass capacitors. However, the face containing pins 1-60 had roughly half the number of power pins and thus allowed more room for connecting the DAC. As a result, I rearranged the pinouts such that the DAC could be connected to pins 1-60, and the remaining components could be moved around as necessary. Although I wrote these new pinouts on the FPGA, I did not remove the original pinouts in case we decided not to use this new component layout.

October 18, 2007 (2 hours):
I researched the physical dimensions of our new 1.5A 3.3V regulator and made a new PCB footprint corresponding to those dimensions. In addition, I updated the parts list based on the orders I had made recently. Finally, I modified the SRAM footprint to better fit the actual SRAM chip we had received. Regarding the modifications I made to the schematic yesterday, my teammates felt that while this change would be useful, it may not be worthwhile to change our component layout this late in the design process. Thus, we decided to use the original FPGA pinout in our final PCB layout.

October 19, 2007 (5 hours):
Tom and I read through some existing VHDL code as well as some of the code he had written for VGA monitor output. I had no prior experience with VHDL, but I was able to quickly grasp some of the major features of VHDL programming and was able to help Tom in writing the VGA code. Finally, we succeeded in outputting colors to a VGA monitor.

October 21, 2007 (1.5 hour):
I looked briefly into VHDL coding needed to interface with SRAM. This code would involve the activation of SRAM enable signals and the reading/writing of various SRAM data. We found that the data access times (read/write operations) for the SRAM modules were around 10-12 ns.

WEEK 09 SUMMARY
Accomplishments: Determined that our 3.3V regulator would need to supply 1A as a worst scenario, and ordered a new regulator in turn. Modified PCB footprints to better fit the components. Assisted Tom in programming color output to a VGA monitor.
Weekly Work Total: 16.5 hours
Project Work Total: 114 hours

Week 10

October 24, 2007 (3 hours):
I worked on generating an accurate 80 MHz clock signal for our development board. The DE2 board uses an onboard 50 MHz oscillator as its main FPGA clock, which provides a sufficient duration (20 ns) over which the various SRAM enable signals and address/data signals can be transmitted without interfering with their respective setup/hold times. For our final project however, we wanted to use an 80 MHz clock, which only has a period of 12.5 ns. This duration leaves very little margin for the setup and hold times of various signals, and thus even if the SRAM implemenation functioned properly with the onboard 50 MHz clock, there was no guarantee it would work for 80 MHz. As a result, we wanted to execute our SRAM program using an external 80 MHz clock fed to the board rather than using the onboard 50 MHz signal. Although we had a 80 MHz oscillator available, it was a tiny surface-mount package, and thus it would have been tedious to solder wires to the oscillator and connect them to their respective signals. Instead, we chose to connect a readily available 100 MHz through-hole oscillator to a breadboard, and use this signal as our external clock input to the board. We would then use the PLL blocks to produce a 80 MHz clock from this base signal.

After wiring the oscillator circuit and confirming that a clean 100 MHz signal was entering the board, I researched how to implement PLL functionality in the Quartus software. After reading the Quartus help files as well as some Altera documentation , I discovered that the Quartus software package contained an SOPC builder that could be used to specify PLL clock parameters. Although it appeared that I had entered all of the correct PLL settings in this builder, there was an unrelated error that would not allow the software to run properly. After struggling with this software for some time, we decided that we to simply purchase an 80 MHz through-hole oscillator from Mouser.

October 25, 2007 (2.5 hours):
Now that we were able to display colors and even basic letters on our VGA monitor, we wanted to create a starting screen for our game with the 'Hooked on Harmonix' title on it. I spend some time in lab creating a good portion of the text for our starting screen.

WEEK 10 SUMMARY
Accomplishments: Helped with programming starting screen text. Ordered 80 MHz through-hole oscillator after PLL programming was unsuccessful.
Weekly Work Total: 5.5 hours
Project Work Total: 118.5 hours

Week 11

October 29, 2007 (7 hours):
I completed the preliminary Patent Liability Analysis report and created the corresponding powerpoint file to be presented on wednesday of this week. References to the patents and commercial products researched are provided in the Patent Analysis document.

October 30, 2007 (3 hours):
We all met in lab work on various project goals, including learning how to properly solder components, understanding the MIDI data signals, and addressing power consumption concerns. I asked Phil if our 5 V regulator would provide sufficient current for our project, since it must supply the total power needed by the 3.3v and 1.2V regulators. In my previous calculation, I had not taken into account the large inefficiency (linear regulators are generally only about 70% efficient) in our regulators, and thus the 5V regulator would need to supply even more current than initially expected. As a result, I began searching for 5V regulators with at least a 1.5A output. I also examined the MIDI keyboard signals on an oscilloscope and tried to determine which signals corresponded to particular MIDI sequences. The following webpage contains tables of MIDI messages that correlate a MIDI byte to a particular command. Thus, by reading the '1' and '0' pulses of the MIDI signal on the oscilloscope, we hoped to decipher what messages the MIDI keyboard was sending. Unfortunately, we were not able to determine fully what signals were being sent because the binary sequences were inconsistent and did not make sense.

November 1, 2007 (6 hours):
After my lab presentation yesterday, I realized that I had made a significant mistake in my Patent Liability Analysis document. I referred to products that were similar to our Hooked on Harmonix system, but did not actually list the patents the manufacturer held relating to those products. Because I was not easily able to find these product patent, I decided to search for alternative patents I could use instead. After a great deal of patent searching and document revision, I completed the final HW 10 Patent Liability Analysis.

November 2, 2007 (5.5 hours):
I spent today soldering components. I first practiced soldering SMT capacitors on a test board. Once I became comfortable with test board soldering, I began soldering capacitors and resistors to our PCB.

WEEK 11 SUMMARY
Accomplishments: Completed Patent Liability Analysis homework. Soldered some discrete components to PCB. Examined MIDI signals on oscilloscope, but could not corectly interpret them yet.
Weekly Work Total: 21.5 hours
Project Work Total: 140 hours

Week 12

November 5, 2007 (6.5 hours):
The first issue our team encountered today was that Bryan discovered that some of our capacitor values for the voltage regulators were wrong. Some values were off in fact by a magnitude of 100 or 1000! Because of this alarming error, we rechecked all of the capacitor values for all of the components on our board and discovered that many of them were completely wrong. We then looked through some of our old schematics in order to determine at what point these capacitors values were changed, and we determined that the change must have occurred after our Design Review since our capacitor values were all correct at that point. Unfortunately, since none of our team members modified the capacitor values, we still have no idea how those values were changed. Regardless, we used our old schematic in conjunction with component datasheets to determine what the required capacitor values were, and we fixed them on our printed copy of the schematic. Furthermore, because we had already soldered some of these wrong capacitors on to our board, Bryan had to desolder a few of them and resolder the correct capacitors.

While examining these capacitor values, we also determined that we did not have enough of all of the capacitors that we needed. As a result, we went through all of the capacitors on the entire schematic and compared them to the capacitors we had in stock. After determining which capacitors we were missing, I was able to order them online. I also ordered more two more oscillators just so we would have additional backups should something go wrong.

The final major task of the day was to find and order a 5V regulator with a 1.5-2 A output current. Although I had done some searching previously, I did not find a satisfactory regulator for several reasons, including high cost, improper pin dimensions, lack of availability, etc. Today however, I finally found and ordered a 5V 1.5A regulator that seemed to meet our cost and dimensional criteria. Unfortunately, we discovered afterwards that although the pin dimensions were correct, the pin LAYOUT was different, meaning that the order of the input, output, and ground connections on our PCB footprint was different than the order on the new 5V regulator. As a result, I tried searching again to find a 5V regulator that would also match our pin alignment. After much effort, we decided to simply use the 5V regulator I ordered, but to flywire it to our PCB. We intend to solder the regulator to a small piece of test board and then solder the test board to the PCB using header pins.

November 6, 2007 (3 hours):
I spent several hours soldering capacitors and resistors for various components.

November 7, 2007 (3.5 hours):
I soldered more discrete components today, focussing primarily on the numerous capacitors for the FPGA.

November 8, 2007 (1.5 hours):
I continued to solder discrete components and replace the incorrect ones we determined on November 5th. I also discovered today that although we had 1000uf surface mount capacitors, they were too large to fit on the existing 1206 capacitor footprints. I intended to discuss the issue with Brian tommorrow and decide what the next step should be.

November 9, 2007 (1.5 hours):
I searched for stores nearby which might carry 1000uF through-hole capacitors, and discovered that Radio Shack had them in stock. After considering the difficulty of soldering a through-hole capacitor to the existing footprint versus the large surface mount component, Brian and I decided to purchase the Radio Shack capacitors.

WEEK 12 SUMMARY
Accomplishments: Soldered many discrete components onto FPGA. Purchased a 1000 uF through-hole electrolytic capacitor.
Weekly Work Total: 16 hours
Project Work Total: 156 hours

Week 13

November 12, 2007 (8 hours):
It appeared that 1.2V and ground were shorted. We all tried to examine the FPGA and fix anything resembling a solder bridge, but nothing worked. Tried to help Tom with recognizing MIDI signals and displaying them on the Dev board LEDs.

November 13, 2007 (3.25 hours):
Discovered that it was ok to have approximately 60 ohm resistance between 1.2V and ground. Changed schematic to have correct component values. Looked briefly into PLL documents. Looked into SPI documents with Curtis.

November 14, 2007 (3.5 hours):
Tested DAC pins and reviewed wiring. Confirmed that all signals were correct. As a result, Brian's suspicion that the Power Save pin is preventing DAC output is likely correct. We had previously soldered a MIDI LSI chip on a small test board, and Curtis wanted to use this to test his MIDI output code. We carefully examined the board and made a list clarifying which pins on the MIDI LSI corresponded to header pins on the test board. We then used this list to connect leads to headers pins which could then be controlled by the DE2 board. Unfortunately, Curtis's SPI code was not yet working.

November 15, 2007 (3 hours):
Curtis and I soldered the MIDI LSI on to the board, after much difficulty. We then powered up the board with Curtis's code, and found that the 9V power supply was supplying just over 400mA of current to the board. Even though the 5V regulator is capable of supporting a 1.5A output, this 400mA (3.6 W) input to the regulator was enough to make the regulator so hot that one could get burned if they touch it. As a result, I looked briefly into heatsinks that we could potentially use to cool the board.

WEEK 13 SUMMARY
Accomplishments: Resolved Power/Ground shorting issue. Soldered MIDI LSI onto PCB. Wired up MIDI LSI test board, but could not determine if functionality was correct since SPI was not yet working.
Weekly Work Total: 17.75 hours
Project Work Total: 173.75hours

November 16, 2007 (4.5 hours):
I examined the 5V regulator datasheet in order to determine if there were any figures suggesting why the regulator would become so hot. I discovered that for this particular regulator, the temperature increase per watt dissipated was 19 degrees Celsius (roughly 34.2 degrees Fahrenheit). Although the datasheet did not provide an efficiency figure for the regulator (power out/power in), Phil told us that most linear regulators are roughly 70% efficient. Given this value, a power supply input of 3.6 W would result in a power dissipation of roughly 1 W, which would equate to a temperature increase of about 35 degrees Fahrenheit. However, the linear regulator felt significantly hotter than this upon touching it. I then contacted the manufacturer of our 5V regulator, Texas Instruments, to inquire why the voltage regulator would become so hot. Unfortunately, there were no engineers available to assist me with this question. Afterwards, I looked into alternative voltage regulators that could deliver our current requirement while improving the thermal efficiency. After much searching, the best option in terms of thermal efficiency and cost was the NTE1934X. However, the pin spacing would not fit even out test boards correctly, which would necessitate even more flywiring than the current regulator. Ultimately, we decided that because the PCB would be encased and the 5V regulator does not cause any other board components to become excessively hot, we would simply leave the regulator as is and warn the user not to open the unit unless it has been powered down and allowed to cool. Later that evening, I helped Tom with software for a couple of hours in lab. After correcting some timing warnings, Tom and I tried to run his code in conjunction with the SOPC builder file Curtis had assembled; however, for some reason it was not working. Tom attempted to make several tweaks to the SOPC file, but could not get his code running by the time I left.

November 18, 2007 (2.25 hours):
My teammates had connected the MIDI LSI test board to the DE2 board through a variety of connectors, but they were never able to run the code properly on the device. I examined the wiring of the circuit, but much of it seemed to be correct. Finally, I tested the probes themselves and determined that the connectors we were using had a 100 ohm impedance. This impedance was large enough that it could be affecting our signal voltages and thus causing the LSI not to function properly. We considered using new cables with a female-male end or female-female end, but discovered that the design lab only had a few in stock. Tom then went to Radio Shack to determine if the store had any of those types of cables, but found that they were not available. In order to reduce the number of header connections we would need to make, we decided that the pins which were connected together on the schematic should just be joined on the board directly. Then, we would only need to connect a signal to one of the pins in order to achieve the same signal at all of the other connected pins. I soldered the necessary pins together on the LSI test board.

November 19, 2007 (5 hours):
We discovered that we would need to run the C code through JTAG while the remaining program could be stored in our serial configuration device via active serial programming. Thus, we needed to flywire a JTAG header and its corresponding connections to the FPGA. My teammates drew the connections to the JTAG header, and I then soldered all of the connections. Furthermore, I looked through some code with Curtis and Tom in order to help them with any logical errors as well as to better understand the programs myself.

November 20, 2007 (13 hours):
Met Professor Johnson with Tom to discuss the timing errors in our VHDL code. We discovered that a likely source of error was that the 40 MHz clock we were using was being generated by a software counter rather than the PLL. As a result, this clock was not as robust as the 80 MHz clock in terms of avoiding phase shifts throughout the FPGA. Ultimately, Tom decided that we would be able to run all of the VHDL code using only the 40 MHz clock, and thus we generated this clock using the PLL and replaced the 80 MHz clock with it. Fortunately, this modification resolved many of the timing errors. Tom and I later discussed how to change the color of the black keyboard keys using an array to track the pixel location corresponding to a particular black key.

I also helped Curtis with the audio output C code. The main issue was that the time consumed for loading the FIFO (163.6 us as determined by Curtis and Bryan) was large enough that if we attempted to load notes into the buffer while simultaneously displaying bars on the screen, there would be significant error between the bar display and corresponding audio output. As a result, we needed to ensure that we not only kept the FIFO buffer reasonably full at all times, but also that we only loaded the buffer inbetween bar display executions so that the gate delays would not substantially affect our timing. Fortunately, I discovered a timestamp function in the NIOS II processor that can be used to track the number of clock cycles between any number of events; this functionality is exactly what we desired. Using the timestamp function, we could accurately determine how much time elapsed between bar display executions and could thus ensure that the buffer was only checked and loaded during this period of time. Although this seemed to be correct in theory, we found that the scrolling bar display would become unsynchronized with the audio output after some time during the song playback. However, Curtis eventually realized that while the MIDI LSI only accepts single-byte note time delay values, some MIDI songs can contain note delays that are mutliple bytes long. As a result, the MIDI LSI was simply truncating time delay values for several notes and thus cause the audio and display to become unsynchronized. To account for this, we attempted to add 'nops' (no-operation statements which simply force the processor to wait for some number of cycles) to the note array so that the LSI would wait longer before outputting the next note. However, the bar display would still not match up with the audio output after a certain point in the song.

WEEK 14 SUMMARY
Accomplishments: Soldered JTAG header to PCB. Looked for new 5V regulator with better thermal efficiency, but later decided not to implement it. Discovered that connections to MIDI LSI test board had too large of an impedance, and therefore soldered certain pins on the test board together so that the number of cables needed would be minimized. Worked with Curtis on MIDI LSI buffering code.
Weekly Work Total: 24.75 hours
Project Work Total: 198.50 hours

November 26, 2007 (3.5 hours):
I helped Curtis and Brian briefly with the audio/display mismatch issue we were suffering last week. I pointed out to Curtis that the nop statements we implemented did not provide a long enough wait time to ensure that the bar matches the audio output. As a result, we modified the code such that by implementing a series of mathematical operations, we could determine how many nops (as well as any time delay remainder) would be required to produce a time delay specified by an arbitrary multi-byte note time delay value. We then tested the code and discovered that the audio output was now synchronized very well with the bar display.

I looked briefly into the 9V power supply adapter we would need for our project and found that Radio Shack carries a 9VDC, 800mA adapter . Although our power consumption could theoretically be larger than what this adapter could supply, this theoretical consumption is merely a worst-case scenario and would likely never occur. Thus, this power supply may be sufficient for our needs.

I also started writing the User Manual document (HW 13) to be submitted later this Friday.

November 27, 2007 (4.5 hours):
I filled in some more information in our User Manual document. I also tried to help Curtis decipher why our program would not boot correctly from flash. For some reason, the C code would run only once after a system reset. For any successive resets, only the VHDL code would be programmed into the FPGA while the C code would not be executed at all. We tried to resolve the issue by implementing a solution emailed to us by an Altera engineer. We were instructed to manually convert the programming flash (.flash) files to an absolute hex (.hex) format and then program the EPCS64. However, several attempts to do this yielded no success.

November 29, 2007 (3.5 hours):
I continued to investigate why we were unable to program our board correctly either through JTAG or Active Serial. Fortunately, I discovered a forum thread in which users had stated that the FPGA would not reset correctly if the USB Blaster cable was left on the header after the program had been downloaded to the board. We then unplugged the USB Blaster cable and power cycled our board, and finally the C code executed. Now, we could finally test the MIDI LSI audio output on our actual PCB. Unfortunately, we discovered that there was no audio signal being output from our board. As I searched through our documentation and PCB layout to discover what the issue might be, I found that our audio jack was connected incorrectly on our PCB. Thus, we had to desolder the jack, and then fly-wire the appropriate connections. We tested the audio output after the jack had been correctly wired, but sadly there was still no audio signal. The jack pins did have a DC voltage of approximately 1.6V, but without an AC signal with varying frequencies, the audio jack could not produce any audible sound. We believe that the MIDI LSI on our board may possibly be defective or that certain pads/traces around the LSI may have been damaged by the soldering process.

November 30, 2007 (1.5 hours):
Curtis programmed the FPGA on our PCB such that the signals going to the MIDI LSI would now be sent to header pins also. Curtis and Tom then wired the MIDI LSI test board (which worked flawlessly when connected to the DE2 board) to this PCB header hoping we would acquire an audio signal. Still, no audio signal was produced. I then double-checked all of the wiring connecting the test board to the PCB header. I also ensured that the pin assignments in software corresponded to the correct pins on the PCB header.

WEEK 15 SUMMARY
Accomplishments: Determined that leaving the USB Blaster cable plugged in caused programming errors. Found that audio jack was soldered to the board incorrectly. Double-checked MIDI LSI test board wiring to ensure that the connections were correct. Finished User Manual.
Weekly Work Total: 13 hours
Project Work Total: 211.50 hours

December 2, 2007 (2.5 hours):
I finally purchased a 9V 1000mA wall power supply from Radio Shack. In addition, Curtis and I continued to examine why the MIDI LSI audio would not work. At the end of the day, our monitor output was very distorted for some reason which we could not ascertain.

December 3, 2007 (5.5 hours):
We all continued to examine why the MIDI audio output would not work. We pulled the MIDI LSI inputs to header pins on our PCB and compared the signals on the PCB header to the signals on the DE2 header, with which the LSI test board would correctly produce audio output. We discovered that although the signals looked very similar, the frequencies of the SCLK signal input to the MIDI LSI was lower on the PCB. We realized that this frequency reduction was due to the fact that we were using a 40 MHz SPI clock on our PCB, while the DE2 code woul utilize an 80 MHz SPI clock. Although we felt that a 40 MHz clock should theoretically still work, we changed the PCB SPI clock to 80 MHz just to see if any change would occur. Fortunately, this clock change allowed the audio output to function properly on our PCB for the first time.

Tom and I also bored out a hole in our casing, allowing us to secure the power switch in our case.

December 4, 2007 (11 hours):
We demonstrated our PSSCs to karl and Phil, and confirmed that all five were satisfied. Then, while Curtis and Tom made corrections to their software, I worked on making our MIDI LSI test board interface permanently with our PCB, since our onboard LSI would not work. Originally, we simply connected the LSI test board to our PCB using several wires which would simply connect into the female PCB header; now however, we wanted to solder a male header directly onto the LSI test board so it could simply be plugged into the PCB header. In addition, all of the header connections needed 47 ohm resistors on the signal lines. Using a new section of PCB with numerous vias and several 47 ohm resistors, I was able to solder a neat, compact unit containing the LSI test board which could simply be plugged into our PCB.

I also tried to help Tom and Curtis a bit with any software issues. I made sprites for 'Bells' and 'Simpsons' so Tom could put these names in the song list.

December 6, 2007 (15.5 hours):
We first made a final decision regarding which songs we wanted in our song list. We decided upon Existentialism, Tetris, Carol of the Bells, Simpsons theme, and 100 years. Afterwards, the PCB enclosure was finally constructed. We roughly measured out where all the ports needed to be and bored out holes to allow these ports to be exposed. I glued small metal support stubs to the bottom of the PCB so it would sit elevated inside the casing. We drilled holes to allow these threaded stubs to be screwed into the bottom of the casing, allowing the board to be stabilized within the case. Tom also finished spraypainting the outer part of the case. Once the case was completely finished, we took our equipment to Hillenbrand to film the video for the bonus presentation on Friday. After filming the video, I spent a little time helping edit the video and providing general suggestions. However, I left early due to having an early class Friday morning, and my other teammates finished the video editing.

December 9, 2007 (6 hours):
We spent today updating our old homeworks to be inserted in the final report. Curtis and I also wrote the senior design report. We also worked on finishing a team poster.

WEEK 16 SUMMARY
Accomplishments: Created new MIDI LSI board which could be directly plugged into PCB. Helped finish enclosure for PCB. Helped film the video for the bonus presentations. Worked on reports/posters/CD due for next week.
Weekly Work Total: 40.5 hours
Project Work Total: 252 hours