With no class requiring it and no board experience going in, one engineering student designed a five-stage pipelined MIPS processor from scratch in VHDL and ran it on a Digilent Basys 3.
Most students spend the summer trying to forget about coursework. Ryan spent his building a processor.
Over about six weeks, Ryan, a Computer Engineering student at Rochester Institute of Technology, designed and implemented a five-stage pipelined MIPS processor from scratch in VHDL, running it on a Digilent Basys 3 FPGA. No class assigned it. No professor was grading it. He wanted to understand how a computer actually works at the level where software turns into hardware, so he sat down and built the thing that runs it.
That instinct, to learn something by constructing it rather than reading about it, is what makes his project worth sharing. And it’s worth noting he did it early. Ryan is a second-year student in RIT’s Accelerated BS/MS program and its Honors program, which makes tackling a full pipelined processor on his own, before the course that teaches it, all the more impressive. This is less a story about a processor and more a story about what a curious student can teach himself when he decides to take on something genuinely hard.
Why a Processor? Why Now?
His motivation was refreshingly practical. He had an assembly and embedded systems course coming up in the fall, and he wanted to see the other side of the instructions he’d soon be writing.
“I wanted to start learning about computer architecture. Building a processor gives me a look into how the instructions I’m using in my class are created in hardware.”
Ryan, Computer Engineering student, RIT
There’s a course in his major where students build a MIPS processor, but he hadn’t taken it yet when he started. He didn’t wait for the curriculum to catch up to his curiosity. He treated the summer as an open lab and set his own assignment.
What He Was Working with Going In
He wasn’t starting from zero, but he wasn’t far from it either. The spring before, he’d taken Digital System Design I, where he picked up the fundamentals: flip-flops, control units, state machines, and some VHDL. That class used a different board and a different toolchain, an Intel DE-10 Lite with Quartus Prime.
The Basys 3 and AMD’s Vivado Design Suite were both new to him. So was nearly everything about processor design. He was learning a new board, a new professional toolchain, and the entire concept of pipelining at the same time, on his own schedule, with online resources as his only teacher.
The Basys 3 turned out to be a good fit for that. It’s an entry-level board built around an AMD Artix-7 FPGA, with 16 switches, 16 LEDs, five pushbuttons, and a four-digit seven-segment display built right in, so he had everything he needed to get output on screen without any extra hardware. It’s the same board Digilent recommends for introductory FPGA work, and it’s a common sight in university computer architecture labs for exactly that reason.
The Real Work Was in the Debugging
He’s candid that the interesting engineering wasn’t stacking up five pipeline stages. It was making them cooperate.
A pipelined processor overlaps instructions, so while one is being executed, the next is being decoded and another is being fetched. That overlap is where the speed comes from, and it’s also where things break. He had to build data hazard detection with forwarding, a dedicated branch hazard unit, and control hazard flushing to throw out instructions fetched down the wrong path after a branch was taken. If any of that logic is slightly off, the processor doesn’t crash politely. It quietly computes the wrong answer.
The bug that cost him the most time was a mismatch between his behavioral simulation and the actual implementation on hardware.
“My logic worked perfectly fine in the behavioral sim, but fell apart in post-implementation timing simulations.”
He eventually traced it to his ALU output never being initialized with a default no-operation value. Without that default, the ALU was generating junk on cycles it should have been idle, and that garbage rippled through the rest of the pipeline. Anyone who has done hardware design knows this specific flavor of frustration. The design looks correct, the simulation agrees, and then real timing exposes an assumption you didn’t know you were making. His reflection on it is one every engineer eventually learns.
“Nothing teaches you how something really works better than figuring out how you built it wrong.”
The Moment It Clicked
For all the complexity, the breakthrough came from something almost laughably small.
“I was able to run an incredibly basic 1+2 with the MIPS and display it to my seven-segment display. This was soon followed by the Fibonacci sequence, then prime numbers. Everything came together very quickly after that seemingly trivial 1+2.”
That’s the rhythm of a lot of real engineering. Weeks of grinding on infrastructure that produces nothing visible, and then one tiny result that proves the whole chain works end to end. Once his processor could add two numbers and show the answer, the harder programs followed almost immediately. His public demo shows a brute-force prime number calculation running on the Basys 3 with the clock deliberately slowed down so you can watch it work.
A Long List of Things He Didn’t Know Before
Ask him what he learned and the list runs long: pipelining, instruction fetching and decoding, stack pointers, instruction memory, carry-save multiplication, branching, jumping and linking, timing constraints and constraint files, record-class-based testbenches, seven-segment display refresh rates, and clock division, among others.
What’s notable is that none of these were handed to him as lecture topics. Each one showed up as a problem he had to solve to make the next part work. That’s a fundamentally different way of learning than memorizing for an exam, and it tends to stick.
He didn’t stop at a working demo, either. After the first version ran, he spent another couple of weeks expanding the instruction set with more J-type instructions, redesigning his decode process to be more efficient, and reworking the ALU to use hardware more effectively. He also added more hazard detection, including a stall unit for a load-word followed by a store-word. This is the behavior of someone who finished the assignment he gave himself and then kept going because he wanted it to be better.
His Advice to Other Students
His advice is grounded and encouraging, which is exactly what a nervous beginner needs to hear.
“When you are starting out in FPGA it may feel overwhelming, but there are lots of tutorials, YouTube channels, and articles to learn from.”
For students who’ve never touched digital design at all, he points them toward HDLBits to practice building basic components in Verilog before taking on anything large. It’s a good reminder that the barrier to this kind of work is lower than it looks. The tools are free, the boards are affordable and student-friendly, and the learning material is everywhere. What’s actually required is the willingness to be confused for a while and keep going.
What’s Next
He isn’t done with this design. It’s now the basis of a faculty-mentored research project comparing FPGA development against open-source ASIC development, using LibreLane and OpenLane to convert his processor into an ASIC and measuring the tradeoffs in power, performance, area, and time to market. He’ll present that work this fall at RIT’s Honors Research and Creativity Symposium. He also has a project lined up for the ImagineRIT festival in the spring built around the computational advantages of FPGAs, and a finite impulse response filter on his personal build list after that.
His longer-term aim is clear. He’s looking for summer 2027 roles in FPGA, VHDL, Verilog, and hardware engineering, and after graduation he wants to work in ASIC design and high-performance computer architecture, the kind of processor and accelerator design that sits behind modern CPUs, GPUs, and AI chips. For a second-year student, he already has a strikingly clear sense of where he’s headed.
“This is one of the most rewarding projects I’ve taken on. It’s given me a much deeper appreciation for what’s actually happening under the hood of every processor I’ve ever used.”
That’s the quiet payoff of hands-on work. He set out to understand computer architecture, and he came away understanding it in a way that no lecture could have given him. He also came away with a finished processor, a public write-up, and a very clear sense of the field he wants to build a career in. Not a bad return on one summer.
About Ryan: Ryan is a second-year Computer Engineering student at Rochester Institute of Technology, enrolled in the Accelerated BS/MS and Honors programs. His faculty-mentored research compares FPGA and open-source ASIC development flows, and he’ll present it at RIT’s Honors Research and Creativity Symposium this fall. His interests are FPGA development, digital design, and ASIC and high-performance computer architecture.
