Hello Everyone

Yesterday at 1, DigiPen held its graduation ceremony at Meydenbauer Center. Congratulations to all my fellow 2015 graduating classmates. I've seen the work your game teams have made and I am very proud of each and every one of you. Thank you for letting me distract you from your work to chat about what you were doing. 

As for those of you entering the industry after graduation, I expect beta keys, early access, and other perks. 

For those of you who entered in the 2011 cohort but not graduating with us. It pains me to not see you leave with us. I wish the best for those of you who have one or two more years left. I know you can finish and achieve your dreams in the game industry. Work hard and I hope to hear about the amazing games you guys will make.

As for me, I am done with undergraduate and in a couple years plan to get my Masters or PHD. On May 22nd, I am moving east to Pullman, WA to start my job at Schweitzer Engineering Labs as an Associate Hardware Engineer - Digital Design. 

Thanks again for giving me a wonderful experience these last four years.

In my MAT363 class I have to implement the 2D wave equation in MATLAB. I used a direct method implementation to simulate the wave equation. I could have used an FFT and integral functionality built in MATLAB to help with optimization. However my Professor would not allow me to use it. So there are nested for loops everywhere!!!! 

The dimensions was a 20x20 grid normalized from 0 to 1. Alot of pre-computation was done so the actual processing is rather low. Check out the video below!

Approximately three weeks ago Thursday I got offered a position at Schweitzer Engineering Laboratories as an Associated Hardware Engineer-Digital Design. I am so thankful and happy for this opportunity. I get to do something I love which is RTL design work. Super exciting and I can't wait to talk more about it in the future. 

Of course this does come with its own problems. I have to move to Pullman, WA in a couple of months. With the move, I have to deal with packing my stuff, working things out with my GF Julie on her belongings, and finding a place to live there. This has become a jumbled mess, I have to figure out what I need to do with this. 

The important things to do is pass all my classes, schedule the move and wait. All three are painstakingly slow and takes about 2 months to finish. Its going to be a slow semester. 

So many things have happened since I last wrote a blog post but I'm going to talk about Summer and the start of the Fall Semester. Its the end of Week 1 of school and I'm sitting at home watching the Week 1: Cowboys vs 49ers game while writing because its awesome background noise. So many flags this game. Moving onto what happened, I want to start with my internship.

Over the summer I interned at DigiPen's Research and Development Department as a hardware engineer intern. I learned so much from my hardware lead Nick Rivera. I could talk about the hardware techniques I learned like a hardware abstraction layer, PCB design, and some DSP tricks. If you want to see what I did for the internship just go to the internship page. But I learned something even more important. I learned that I have major personal flaws as a computer engineer. An example of this is getting stuck in a mental infinite loop. This is something I made up because I don't think its a real thing. But its the best way to describe it. When attempting to fix/solve a problem I try my best to come up with the BEST way to solve it. This is a problem because I'm my own worst enemy. I spend way to much trying to solve this problem the most optimal way possible that I either kill way to much time or my brain loops until I get mentally exhausted. This internship made me realize this was a problem. I haven't consciously thought about it as a student till now and I need to take steps to fixing it. My lead was a major help because he would tell me to do something a certain way and since he's the lead I got to do it that way. Now that I am aware of the problem I am actively trying to look out for it and stop it from happening. Right now its not a major problem because the semester just started. I'll update my progress later. 

Another problem was my inability to communicate with people. Even now its a problem I'm having. The Internship really showed this problem to me. I would explain a technical situation to my lead and he would get really confused at what I was saying. I guess I can't explain things very well. I haven't taken steps to alleviate this problem but its something I'm thinking about. 

Onto a different note, my project Mediated Perception with my partner Cody Harris is stopping. He wants to move onto a sound DSP project. I'm happy for him and I hope he gets what hes looking for in his new project. I have decided to join a junior team to work on a very ambitious project called Project GARI. Read more about it on my Projects tab. I'm really looking forward to this project because I need to work on a +2 person team. Partner projects for the last 2 years have made me forget about team cohesion and the importance of team dynamics. The projects I have done with Cody were primary split down the middle in terms of work. So I haven't had to deal with team issues very much because I have been primarily on my own. Also I have a very good feeling about this project if it takes off, no pun intended. 

-Johnny Sim

I learned, as an engineer, you have to cut corners to make things happen. But when does it become too much cutting, and not enough learning? Cody and I have worked really hard on getting something completed. However I feel as though we lost something in the progress. We stress on getting something completed, and as a result we have "average" results and barely know what we did. Cody wants to learn Linux inside and out. I want to become a "master" FPGA programmer. These things take years to accomplish. We spend realistically 5-10 hours a week on our project. We are not investing enough time on the project or our own goals. Everything is being put on the back burner. 

My roommate Craig Steyn is an engine developer for his game team. He made an excellent point while discussing parts of his project. "If I don't like what I'm doing, I'm not going to do it." Its a simple statement, but one that I really admire. He told me he had a 5 layer abstraction for his input system, and he has recursion in parts of his code. I asked him why he would do that. He said because its necessary and it's fun. Duh, it has to be fun. I was so worried about passing my classes that I missed the most important part of being an engineer. 
 
I told Cody, don't stress about getting your part of our communication protocol going. Write a simple driver that turns on an LED. Something simple and easy to build your way up. As for me, I need to learn more about the Verilog language and actually work on code more often. Its something that I personally need to do. I want to become great at Verilog but I don't practice it nearly enough. 

Goal for the next 5 weeks: Learn the fundamentals about Verilog and Driver writing.  Spend about two weeks working on that, then the last three weeks get our communication protocol working. Its going to be a tough ride, but I'm sure Cody and I can handle it. 

-Johnny Sim

I don't usually blog because I am a horrible speller and my grammar is absolute garbage. But I wanted to talk about my mysterious project people keep asking me about at my school. These updates are for me to look back on and see what I did for my project and to have public record of what I was doing. In actuality its more of a status update on my project. 

Around noon today I roll into school and wait for my project partner Cody Harris to come in. Skipping to the discussion about our project, we talked about what kind of communication protocol to use for our devices. For those of you who don't know what a communication protocol is, it's the physical line of communication between two hardware devices. In this case we have an FPGA (Field Programmable Gate Array) and a Beagle Bone Black communicating together with a communication protocol. We are sending camera data from the FPGA to the Beagle Bone Black, a one way communication.

We are sending 30 bits of RGB information over the lines which equates to one pixel. Originally we wanted to use SPI for our CP, however we quickly learned it was not optimal. We wanted to send 30 bits of information on a 16 bit bus going at 48mHZ. We wanted to use a compression algorithm of some kind to shrink the buffer size, but we quickly learned we would have to shrink the bits by 50%, which is a lot of error when we decompress. Also the compression would take a lot of time to do on the FPGA and BeagleBone. 

Doing the math, we want real time camera information sent to the Beagle Bone Black. That means we want 60 Fps, we realistically are aiming for 30. The resolution we want is 800x480, the same resolution as the LCD screen we are using. We have 2 Bytes of buffer space. 800x480x30x2 gives us about 23 mBytes/s needed for real time video. 

An SPI bus would require 8 bits for its buffer and we would clock it to about 48 mHZ. It takes one clock cycle to send a bit so we would be sending 48 mb/s. Note little b means bits. So we then divide that up by 8 to give us bytes. We then get 6 mB/s which in reality is way to slow still. 

Unfortunately, even with a dual SPI bus, we would realistically get around 12 mB/s with those lines and we would still need double the bandwidth to match our speeds.

Another solution was to try Ethernet but that came with its own set of problems. First, if we take up the Ethernet module of the Beagle Bone Black then we no longer get internet access with that device. Also we would have to write an Ethernet module for the FPGA (which is not fun). Second, its still not fast enough for our speeds. Ethernet runs at about 100mb/s which if you divide that by 8 get 12.5mB/s. This is still not enough for what we need. 

Cody didn't want to use the Beagle Bone Black's GPIO (General Purpose In/out) pins because he was afraid it take CPU cycles away from other things. At this point we have no choice. We cannot match the necessary speeds with the existing protocols. So we are copying the camera's 10 bit parallel communication. The TRDB-D5M camera we are using uses a 10 bit parallel protocol to communicate with the FPGA. Our solution is to simply pass that camera data straight to the Beagle Bone. You may be asking then, why use the FPGA at all? It's simple! Image processing is super slow and takes a lot of memory to use. We are using an FPGA to alleviate that time from the Beagle Bone's CPU. We are planning to do a power computer vision technique called Stereo Vision. 

I'll talk more about this later.

-Johnny Sim