Personal reflections on my hobby projects. Each project page states its current validation status; browser demonstrations illustrate the ideas.
Why I build outside work
I am a Senior FPGA & Embedded Systems Engineer with more than 10 years of professional engineering experience. My hobby projects give me another way to explore ideas, connect hardware and software, and explain the choices behind a design.
My collection includes video filters, an audio spectrum visualizer, Pong, a logic analyzer, and a hardware IP profiling instrument. They solve different problems, but they share the same questions: What should the system do? What resources does it need? How will I check that it behaves correctly?
Start with a clear, manageable goal
A useful first version needs a clear purpose. My logic analyzer starts with internally generated UART traffic. That gives the capture and decoder a known signal to inspect before adding the complexity of external probes.
This is an approach I value in engineering: build a small, understandable system, make its behavior visible, and extend it with evidence. A focused first version makes problems easier to isolate and progress easier to explain.
Choose the architecture before adding features
Image processing makes the cost of a design easy to see. A Sobel filter needs nearby pixels, so two stored lines can provide its working neighborhood. Motion detection needs information from a previous frame, which creates a different memory problem.
These projects reinforce a practical lesson: memory, timing, and data movement deserve attention early. A feature is useful when it fits the system’s needs and the board’s limits. Understanding those limits helps me explain a tradeoff rather than hide it.
A correct calculation is only part of a working system
In a video pipeline, the processed pixel and its timing signals must stay together. In Pong, game state must change at the right point in the frame. In an audio visualizer, samples and display updates move at different rates.
The important work is often at the connections between blocks. I need to think about when data is valid, how reset affects it, and what happens at a boundary. That system view matters as much as the individual algorithm.
Make behavior visible and test the awkward cases
IPScope turns FIFO behavior into a dashboard: accepted transfers, stalls, occupancy, latency, and data errors. Changing the producer and consumer rates makes different conditions visible. Deliberate data inversion provides a way to exercise the error checker.
A useful test asks more than whether normal data passes. What happens when a buffer fills? When it empties? After reset? When data is wrong? These questions help turn a design from a promising idea into something that can be reviewed and improved.
Use the tool that fits the task
My VHDL and HLS Sobel work gives me two ways to describe an image-processing block. VHDL offers direct control over registers, timing, and interfaces. HLS can make algorithm changes and C-level comparisons easier to express.
I do not see tool choice as a competition. I want to understand the requirements, inspect the resulting hardware, and choose an approach that the team can build, verify, and maintain. A target clock or pipeline setting is a design goal; it becomes a result only when the checks support it.
Be clear about what has been verified
Simulation, implementation, and hardware testing answer different questions. A passing test does not prove every case. A generated bitstream does not prove a complete board demonstration.
My portfolio separates recorded checks, conceptual illustrations, browser demos, and pending hardware tests. Clear reporting helps another engineer understand the evidence and decide what still needs attention. I see that clarity as part of responsible engineering.
What I would bring to your team
These projects show the way I approach engineering: define the problem, understand the constraints, divide the system into clear blocks, and test the connections. I value readable designs, useful documentation, and explanations that help colleagues work together.
My background connects FPGA architecture, VHDL, embedded systems, video processing, and hardware/software design. I would welcome a conversation with a team that needs careful technical work, practical problem-solving, and an engineer who can explain the reasoning behind a design.
If that matches a role in your company, I would be happy to discuss your requirements and the relevant parts of my experience.