CPR E 491

Senior Design

During my senior year, I am currently taking CPR E 491: Senior Design. This is a semester long group project that allows all seniors in the ECpE Department to gain experience working on a real world problem. This course is focused on the design of our solution and how we intend to solve our problem. All seniors use their technical writing skills to develop a Project Plan and Design Document, then implement the proposed plan in the next semester (CPR E 492).

I am working in a group with Collin McIntyre, Matthew Wall, and Benjamin Weno to provide Tool Support for the Model Based Verification of the Linux Kernel. This is a project working with the Knowledge-Centric Software Lab at ISU to create an automated pipeline for their Model Based Verification tool, L-SAP. L-SAP focuses on spin and mutex locks used in the many control paths of the Linux kernel. A difficult bug to find with locks is making sure that locked resources are always unlocked in all control paths. While this may seem like an easy problem, the complexities associated with when a resource should be unlocked translate to very complex paths that sometimes and sometimes do not hit the correct unlock function call. L-SAP aims to track lock instances by generating a graph of the control flow. By looking not only at a single function implementation, but also the implementations of further functions down the call stack, L-SAP is able to generate rich graphs that can visually show whether or not a lock will always be unlocked.

While L-SAP is being developed further, there are parts of it that require manual setup for each new version of the Linux kernel. Since development of the kernel is fast, L-SAP cannot analyze all versions of the kernel with its manual setup. Our groups aims to automate the process by creating a pipeline that can generated the necessary setup required for L-SAP to run on the kernel. We also are working toward creating a new algorithm that can detect differences between a lock in two or more versions. This is an important feature that will allow researchers to check if a lock that was marked safe has become unsafe. We also are working on a new design for their results website that will allow them search for specific lock instances and compare their results between multiple versions. Our stretch goal is to fully automated the system, allowing the event of a new Linux release to be the single starting point of the L-SAP verification process.

This is work-in-progress and we are setting up our own website to document progress here.

CPR E 381

MIPS Pipelined Processor

During my junior year, I took CPR E 381: Computer Organization and Assembly Level Programming. I worked in a group with two partners (Ashley Dvorsky and Zachary Wild) to create multiple processor designs that executed MIPS Assembly Instructions. MIPS is a RISC Instruction Set Architecture that is used in a number of embedded systems. While we worked on multiple designs, each design added on to the previous ones culminating in processor capable of executing the 45 most common MIPS instructions. These included basic arithmetic operations, shifting, branch and jump statements, and memory storage and retrieval.

Our final design was a pipelined processor design, which broke an instruction into a series a parts and distributed execution of an instruction between 5 clock cycles. Since the processor was pipelined, there could be a maximum of 5 instructions in progress during a single clock cycle (see the image below for the design). In addition to separating execution between multiple parts, we also had to deal with forwarding logic and hazard detection. Forwarding occurs when an instruction in the pipeline requires a result that is still being calculated. Special data lines are made to "forward" the result to the instruction before the result is stored in the register file. Hazards occur when writing and reading data from memory. If an instruction has to read from memory and there is another instruction that has not completed writing to that memory location, we have to detect this and stop the read instruction from pulling the wrong data.

This was one of my favorite projects because for the final test we had to write sorting programs in assembly and run them on a simulated version of our processor using ModelSim. It was amazing to see our design successfully decode the MIPS instructions and respond accordingly! Even with our reduced instruction set, we were able to create complex assembly programs since we supported jumping and branching.

This project taught me a lot about testing and persevering when a design did not work. Part of the grade with this project was to run an unknown program and make sure the correct result was stored. This meant that we had to put a lot of work into making sure our design was able to respond to all instructions and correctly handle data hazards and branching logic. One of the biggest roles I played within the group was making sure our branching and hazard detection logic were both correct. I created multiple test programs to really put our design through its paces in preparation for our final review.

EE 230

two-channel Headphone Amplifier

During my junior year, I took EE 230: Electronic Circuits and Systems. I worked with my lab partner Liam Briggs on a number of project, but one of my favorite projects was designing and building an audio amplifier circuit. We had to receive input from an audio player, amplify the left and right channels, and output the louder signal to a pair of speakers. Additionally, each channel needed to have a separate volume control so the signals could adjust from one to ten times the input level.

This was one of my favorite projects in the class for a number of reasons. This was one of the first "design" projects we had where a problem was given to us and we had to design the full circuit ourselves. Previous projects included building existing circuit designs and measuring various parts of the circuits. This project allowed us to apply what we had learned in the class and test our own design. I also liked this project because it was one of the first practical applications we had seen with building circuits. The class involved the basics of circuit design, but did not emphasis real-world applications. This was one of the first circuits we built that we could use in our daily life. I remember completing the circuit and plugging in my smartphone to the input and headphones to the output. It was amazing to hear the sound as I adjusted the volume one both channels

This project taught me a lot about basic design processes involved in taking a list of specifications and constraints and translating that into a final product. Our design went through several iterations as we found errors in our calculations and better ways to build certain components. Even though this seemed like a simple task, we put a lot of effort into making a clean design that functioned well.

Two-Channel Headphone Amplifier: Completed Circuit

COM S 327

Hexterminal Havoc

During my junior year, I took Com S 327: Advanced Programming Techniques. This class focused on programming in C and C++, and showed us advanced concepts with these languages. In order to accomplish this, we had the final goal of making our own game that would run in a computer terminal. The game is a rogue-like dungeon crawler, where you control a character that must traverse through different layers of a dungeon, picking up equipment and battling monsters along the way. This was an individual project, so I had to design and develop all the code for this game. Throughout the semester, we were assigned weekly projects to accomplish parts of the game (dungeon generation, player movement, enemy movement, etc.).

These assignments were structured so each week you built onto your current progress. In order to keep things fair, the professor would provide solution code to each week's assignment in case you didn't finish. I am proud to be one of the few students who completed the project using only my code.

This presented unique challenges as I had to not only implement code for the current assignment, but I also had to think of future design challenges. I tried to create a modular architecture that could adapt to changes and additions without changing the same code every week. This class was one of my favorite classes at Iowa State University because the students were give complete control over the design of their project. I had to write and test my own code and complete my changes with a weekly deadline.

Another skill I learned during this project was using version control software to track the progress of my source code. I used Git to manage my code and stored all of my source code on Github. A public release of my code is available online here. This shows the evolution of my code over time, but I also used the issue tracker on Github in my private repository to manage changes I wanted to make as well as find and resolve bugs during testing.

Cpre 394

Ethics Essay

One of the required assignments for Cpre 394: Career Explorations is an essay about Ethics and a case study discussed in a group meeting. My essay is available here. I talk about various topics including the purpose of a Code of Ethics, my personal ethical decision making, and an analysis of the case study we discussed in our group meeting.

Cpre 494

General Education Reflection

One of the required assignments for Cpre 494 is an essay about my general education electives. My essay is available here. I talk about various topics including how effective the general education electives were at ISU and how they impacted the solving engineering related problems and my understanding of the impact with respect to global/societal contexts.

Cpre 494

Cumulative Reflection

One of the required assignments for Cpre 494 is an essay about my cumulative experience at ISU. My essay is available here. I talk about various topics including how ISU has prepared me on a number of levels and experiences I had inside and outside of class at ISU.