Contact
Want to go in contact? You can find ways to do so below. I mostly respond through email though. Currently open to any offers.
The goal of this project was to implement an image decompressor using hardware. Specifically, a custom McMaster image compression revision 11 (.mic11) image compression specification in hardware. Compressed data for a 320 x 240 pixel image will be delivered to the Altera DE2 board via UART interface from a PC and stored in the an external SRAM. The image is then decoded stored back into the SRAM and output via VGA. The program used were Quartus II and ModelSim. This was ran using only the lab room computer on Linux RedHat distro. This project was completed for Digital Systems Design course at McMaster university with Graham Todd.
The entire project was to implement the chart in Figure 1. The 3 milestones were created for marking sake as typically this project was not completed. Each milestone also had built modules to help test. The reasoning for this is that the milestones are reversed, as in we start development in the last stages and work towards the start. The milestones do progressively get more difficult as progress is made. For that reasoning, the project will also be described from milestone 1 to the work done on milestone 3.
Figure 1 : The high level overview of the entire process
Figure 2 : Milestone 1
Figure 3 : Milestone 2
Figure 4 : Milestone 3
Verilog in terms of syntax is very similar to C, which is good. I would consider Verilog difficult at least in the instance of this project. This is primarily because my approach is very ‘programming’ like which is not what it is. It’s a hardware description language which was large emphasis in the course in general: relating source code to hardware. Looking back now, the hard part was the project itself coupled with other course work and responsibilities.
A new skill I developed in this class that was heavily used in this project. A new concept and a very odd one at first. Once I understood what it meant, it made the work much easier and less frustrating. Programming an FPGA isn't quite like writing code on a computer, which seems kind of obvious at first. However, it's easy to forget since you're still writing syntax that's very similar to a programming language. One of my favourite examples to remember is that an "if" statement is a MUX which I will usually picutre in my head.
A first time for myself at least in terms of coding. It was nice to have a partner and he was primary the reason we got as far as we did. However, there was creative clashing where multiple solutions were proposed to problems. Usually, the solutions that were accepted were the ones that would be satisfy the requirement and involve the least amount of coding. Since only one solution could be used, there was a lot of time spent discussing and explaining what each other ideas were.
This was the largest scale project I have ever worked on in terms of lines of code and time spent. I did find it rather difficult, but I believe it was a good learning experience for myself as I eventually hope to work on even larger projects. I wasn’t too happy with my performance with this project, as I believe I wasted too much time overcomplicating ideas that were typically simple. In the end I can’t say I enjoyed it, but I don’t regret doing this project. Rather, I feel like in the future, I have better experience in how I should be spending my time on a project so that I can be more effective with my time.