I recently had the opportunity to help a college student on his end of term project. The student’s project sounded like a lot of fun to me, but in the typical end of term, typical college fashion, I’m not sure it was nearly as much fun for him or his teammate.

When the term was over, I shared with him my blog post, describing the difference between the student’s design process, the expert’s design process, and the actual expert’s design process, and then offered him a chance to respond now that his term is over.

What follows is that he had to say, and then my own thoughts on his comments.

A College Student’s Perspective

I really liked your blog post, and I’d like to respond to it with my own experience.

I’ve now finally finished the project, and handed in my final report.

It is not as professionally done as I might like, and it is likely that it may be missing some desired info. However, the main key point I want to bring out is that we should have spent more time testbenching via simulation on Vivado and creating accurate testbenches, with wait times and hold times similar to realistic button presses as well as accounting for delay times between components in the FPGA, the keypad, and the LCD. All of our testbenches were made very simply with a few hundred nanosecond wait times at most and hold times of 25-50 ns. This is obviously not very realistic in terms of how long a button stays pressed or how long it might take for our double dabble algorithm to work. In simulation, a double dabble will occur virtually instantly, but realistically has a much higher latency when implemented into the board.

This was not accounted for in our testbenching nor during the design process, which is something that I feel wasn’t pushed hard enough by the curriculum, but also might have just been common sense and didn’t hit me until now. However, judging by what you wrote in your blog post, it seems that creating proper testbenches for each and every module doesn’t happen often amongst students, and I feel that we are a good example of that, unfortunately. This just goes to show that if I had spent more time creating testbenches for the interfaces and tried to figure out ways for the FPGA to tell me what’s going on in all that hardware, we might have had more success by the end of the project period.

It is interesting how you mention getting diagnostics from the FPGA because no one ever provided details or instructions on how we should do so or what are good methods on communicating with the FPGA and how to know what parts of the FPGA we could use to figure out if intermediate steps are working as we want.

I do feel a little scammed knowing that there were techniques out there that, with just a couple minutes of explanation, might have saved me hours of debugging. This makes me somewhat sad because I feel like I didn’t get the experience and fulfillment from the class that I wanted/needed just because someone was too tired or didn’t care to explain something to me. This is what made me relate to your blog post post where you mention in the beginning that the design process for a student and a professional are almost two different worlds.

Of course, my instructor would emphasize making a block diagram, then going into a state machine and datapath drawing, then designing the VHDL code, testbenching, etc. However, I feel like during homeworks, lectures, labs, and the project period, the aid was almost a bit too lax and every time I asked for help on why this warning is popping up or why the output wouldn’t be showing on the LCD, I would get: “hmmm … I’m not too sure. I haven’t really dived into how the LCD works” or “have you tried testbenching it” or “try telling the FPGA to give you some info back so you know what’s happening inside.” There was never any in-depth discussion or a fulfilling moment where I felt “wow! Now, I know how to prevent/fix this warning or error” or perhaps “Okay, I understand that I may have to adjust my design in this way and keep this in mind for the future”. Honestly, I felt that I was winging it the whole time. It was frustrating. Still, for some reason, I feel like I still had fun with it. I had fun because it was challenging, it was not easy, and every time I made a little bit of noticeable progress I felt like I conquered the world. I just wish I didn’t have to conquer the world by myself.

Enough of the slightly depressing monologue, the key lessons I learned were these:

  1. Make accurate testbenches for everything even the really simple and intuitive modules like BCD to binary converters.

  2. Account for timing delays in the board that pretty much never happen in the simulation

    [Editor’s note: You should test bench your entire design as well, not just the components. This also would’ve helped find out what was going as the various components within the design interacted with each other.]

  3. The main issue I think we had was that we were sending the outputs from the keypad to each module simultaneously, and it is likely that the later modules were trying to perform calculations or send outputs to the LCD before data values were even finished converting from BCD to binary in the very first module. Of course, it seems like this problem would fix itself after a few cycles, but it was probably not smart to literally not account for timing in the physical board.

  4. Always ask for help from a close professional, professor, instructor, or even the friendly Digilent community. It is so hard to do complex projects on your own, especially when you have no or extremely minimal programming/coding experience (that’s me). Even if the instructor didn’t seem interested, I feel like I should’ve sucked it up and just asked for help more often. My instructor was smart as hell and I still had tons of things I definitely did not know how to do without some help.

  5. A big thing in the blog post is getting diagnostics and always retracing steps. Sometimes the testbench isn’t the problem, it’s the design. For example, latches, time loops, etc. can all be affected my design in ways that I don’t understand but are still making it not work the way I want. Pay attention to warnings and don’t dismiss anything until you get confirmation or find online that the warning doesn’t mean much.

My Own Thoughts

Perhaps I might pull out of his response some key points worth taking away from it.

… it also might’ve been just common sense and didn’t hit me until now.

This is half of the point of any education: to get the student to learn how to think about a task in such a way as to make the task simple. I’m not talking about the mechanics of the task necessarily, but rather how to wrap your mind around the task, so that your mind thinks in the language of the task. The means of achieving this enlightenment is usually to give the student one task after another until the student finally learn’s how to school his own mind.

This is also why an employer would be excited to see a large portfolio of complex projects you have designed. It means you understand how to think like a digital designer.

This makes me somewhat sad because I feel like I didn’t get the experience and fulfillment from the class that I wanted/needed just because …

I think you’ve now learned the lesson the class was trying to teach. Next time, let’s see if we can’t get that lesson across with a little less pain, and a better grade.

Every time I asked for help on why this warning is popping up or why the output wouldn’t be showing on the LCD, I would get: “hmmm … I’m not too sure. I haven’t really dived into how the LCD works” or “have you tried testbenching it” or “try telling the FPGA to give you some info back so you know what’s happening inside.”

If I were your instructor, these might be my responses as well. If you write into the Xilinx forums, you are also likely to get similar responses.

To understand why, think about it from the other side: I’ve now been a mentor for many students. I’ve looked over many pieces of code trying to find their bugs. While I find it a fun challenge, it’s not easy.

Indeed, finding bugs in my own code is hard enough, finding bugs in someone else’s code is a lot harder. It can take me between minutes and hours to find the mistake in someone else’s code, depending upon the complexity of the code. (Debouncing keypad’s is usually quick, debugging FFT’s is hard.)

To make getting help easier, you must first find out what the issue is. The instructor is right in this case, you need to tell “the FPGA to give you some info back so you know what’s happening inside.”

That in itself is one of the ongoing topics of this blog.

Although it’s a touch off topic: when I studied for my Ph.D., my advisor had no background in my field (Digital signal processing as applied to digital communications). He couldn’t help me with any of the details of how to do the mechanics of my problem. Originally, I would’ve thought that this would’ve disqualified him from advising me. In hindsight, I think it worked out to everyone’s advantage–because it forced me to finally learn how to learn a topic for myself. At some point, there’s only so much an instructor can do.

There was never any in-depth discussion or a fulfilling moment where I felt “wow! Now, I know how to prevent/fix this warning or error” or perhaps “Okay, I understand that I may have to adjust my design in this way and keep this in mind for the future”.

I think our student has now just had his aha moment–only he may not realize it yet.

Stick around. This is what we are going to try to do here on this blog: explain what it takes to keep you from getting stuck in the future!

It was frustrating.

FPGA Hell is always frustrating. Let’s get you out of FPGA Hell, so that you can enjoy winging it like the rest of us.

I had fun because it was challenging, it was not easy, and every time I made a little bit of noticeable progress I felt like I conquered the world.

This is one of my own personal reasons for doing digital design.

Can I share a secret with you all? I keep a copy of the theme from Superman lying around, just to be able to share the excitement of success with the others in the office. I’ve even bought copies of the theme from Indiana Jones, from Star Wars, and … I’d better just stop there.