Computer EngineeringDesign, Verification & Embedded
Computer engineering student working across RTL design, UVM verification, and embedded firmware — from a store-and-forward packet FIFO with exact drop prediction, to FreeRTOS telemetry nodes, to a robot that maps rooms on its own.
I'm a computer engineering student who likes the part of the stack where software stops being an abstraction — RTL, firmware, and the boards they run on. Most of what I build starts as a question about how something actually behaves under load, then turns into a testbench or a scope trace that answers it.
Lately that's meant writing a store-and-forward packet FIFO and a UVM environment that predicts every dropped frame exactly, tuning FreeRTOS task priorities on an STM32 telemetry node, and teaching a robot car to map a room with a spinning LiDAR. I care about designs that are provably correct, not just ones that pass a smoke test.
Passionate about solving problems efficiently and building intelligent systems.
University of Florida
Coursework in operating systems, SystemVerilog verification, computer architecture, and analog circuits.
Every public repository, one tile each. Click through to the full write-up below, or head straight out to the repo on GitHub.
Ordered by what I'd want you to read first. Each one links straight to the repository — the commit history is part of the argument.
Design & Verification2026
Store-and-forward RTL with a UVM environment that predicts every drop exactly
A store-and-forward packet FIFO that sits upstream of a network MAC and buffers whole frames so the MAC never underruns when the source stalls mid-packet. The design is built around a three-pointer commit/rewind scheme, and the UVM environment verifies it against a timing-independent contract rather than a cycle-by-cycle occupancy mirror.
wr_ptr advances speculatively on every accepted beat, wr_ptr_commit marks the end of the last whole packet and doubles as the rewind target, and rd_ptr only ever sees committed packets. A dropped frame costs one pointer assignment.
A packet is dropped only when the entire buffer holds a single in-progress packet, so anything that fits is never dropped. Once dropping starts the FIFO holds tready high and sinks the rest of the doomed frame to tlast, so the AXI4-Stream master never locks up.
Because the drop rule collapses to length > DEPTH always drops and length <= DEPTH never drops, the scoreboard predicts drops deterministically instead of racing the DUT's internal occupancy. That removes the false-failure problem that plagues cycle-accurate monitors.
A new axi4_stream_slave_driver generates tready under four policies — always ready, random, stall, and blocked — layered onto Greg Stitt's parameterized AXI4-Stream agent, which is reused unchanged.
Five bugs were deliberately injected — overeager drop, commit pointer off-by-one, missing rewind, stall-during-drop, and plain FIFO instead of store-and-forward. All five were caught by the assertions and scoreboard, proving the checkers actually check.
Embedded / RTOS2026
Five-task FreeRTOS firmware on STM32F103 streaming telemetry to an MQTT gateway
FreeRTOS firmware for an STM32 NUCLEO-F103RB that samples a BME680 over I²C, filters and scores the readings, and streams formatted telemetry over UART to an ESP32 that republishes it as MQTT. Built around explicit priority assignment, priority-inheritance locking, and a command interface that reconfigures the sampling period at runtime.
Sensor at priority 3, processing and comm at 2, logging and health at 1. The health task uses absolute wake times rather than relative delays so its 5-second cadence holds even when execution time varies.
Circular DMA with IDLE-line framing means a burst of incoming bytes costs no interrupts at all — the line goes idle, one event fires, and the whole message is already in memory.
The BME680 bus is guarded by a priority-inheritance mutex, and the button ISR uses direct task notifications instead of a semaphore, keeping the interrupt path short and the sensor task unblocked.
STATUS, SAMPLE_NOW, SET_PERIOD, GET_PERIOD and PING are accepted on either UART link, with responses returned on the originating link. The sampling period retunes from 100 ms to 60 s without stopping the application.
processing.c, telemetry.c and cmd_parser.c contain no HAL or kernel calls, so they compile for the host and run 93+ tests under pytest via ctypes. Hardware tests then check round-trip latency and telemetry jitter separately.
Robotics / ROS 22026
A self-mapping robot car — ROS 2, RPLIDAR, and live floor plans over Wi-Fi
A robot car that drives itself around a room and builds a floor plan while it goes. An ESP32 handles motors and encoder counting, a Raspberry Pi 5 runs the LiDAR, odometry and SLAM stack under ROS 2 Jazzy, and a laptop watches the map build in real time through Foxglove Studio over Wi-Fi.
The ESP32 does only what needs hard real-time — PWM and encoder ticks — and bridges into ROS 2 through micro-ROS. Everything with a compute budget lives on the Pi 5, so the motor loop never competes with scan matching.
Wheel position is integrated from 20-slot encoder ticks calibrated at 10.2 mm per tick, then fused with RPLIDAR A1 scans at 10 Hz to close loops and correct drift.
Map, scan point cloud and odometry stream to Foxglove Studio on a client machine over Wi-Fi, so you watch the floor plan assemble as the car drives rather than after the fact.
WASD keyboard teleop with tunable speed for careful mapping runs, plus an autonomous obstacle-avoidance mode. Finished maps persist as PGM images with YAML metadata.
Motor deadband near 20% duty, single-channel encoders that infer direction rather than measure it, and a battery that sags when motors and LiDAR draw together — all characterized in HARDWARE.md rather than hidden.
FPGA / Acceleration2026
Standing up an ARM-to-FPGA OpenCL platform from BSP to running kernels
An end-to-end OpenCL acceleration platform on the Terasic DE10-Nano, where a host application on the ARM Cortex-A9 dispatches compute kernels into the Cyclone V fabric. The work spans the whole stack — Quartus hardware, the MMD layer and device driver, the board support package, and the host code — kept in clean separation.
Quartus hardware and Qsys system integration, the MMD implementation and ARM device driver, the OpenCL board support package, and the host application — each in its own layer with an explicit boundary between them.
The ARM host enumerates the FPGA as an OpenCL device through the BSP and MMD library, then queues kernels onto the Cyclone V fabric like any other accelerator.
Vector addition establishes the dispatch path end to end, then a 3×3 image convolution exercises a real signal-processing workload with memory access patterns that matter.
Host code builds with the ARM hard-float toolchain under GNU Make, and prebuilt .aocx device binaries and FPGA artifacts ship with the repo so the platform can be validated without a full toolchain install.
Design & Verification2026
A two-agent UVM environment closing 100% functional coverage on a 16550-compatible core
Verification environment built on a forked RTL core
A UVM environment that verifies an APB-based UART master core by instantiating two cores and wiring them to talk to each other, so transmit and receive are checked against real traffic rather than a model. Two APB agents drive the pair, a central scoreboard validates end to end, and assertions police APB protocol compliance throughout.
Rather than verify a transmitter against a predicted bitstream, two UART cores face each other. Whatever one sends the other must receive, which turns serialization, framing and timing into an end-to-end check.
Each APB agent carries its own driver, monitor and sequencer, feeding a shared scoreboard so traffic from either side is checked against the same reference.
Parity errors, break conditions, buffer overrun, framing errors, transmit register states and timeouts — each with a dedicated test rather than being folded into a random soak.
SystemVerilog assertions check APB transaction legality continuously, so a protocol violation fails at the moment it happens rather than as a downstream data mismatch.
Hackathon hardware, driver ports, browser tooling, and coursework simulation.
Embedded / IoT2026
A wearable fall detector with a four-state confirmation machine
A chest-worn ESP32 watches motion and impact and reports over ESP-NOW to a base station that logs telemetry and serves a dashboard. The detector only confirms a fall after four conditions line up in sequence, which is what separates a real fall from sitting down hard.
Embedded / Drivers2026
An Arduino-free port of the VL53L1X driver to the bare Pico SDK
Distance sensing on the RP2350 from two different physical principles at once — a VL53L1X time-of-flight sensor and an ultrasonic rangefinder — with the Adafruit VL53L1X driver ported off Arduino and onto the raw Pico C/C++ SDK.
Web / Tools2026
A Chrome extension that watches one element and tells you the moment it changes
Pick any element on any page and WatchMark tells you when its text changes — seat availability, appointment slots, stock, ticket drops. Built on MutationObserver with auto-reload for pages that only update on refresh, and selections that survive the reload.
Graphics / WebGL2026
A parametric heart, drawn from 2,500 particles of whatever you type
A closed-form heart curve turned into a 3D particle cloud in Three.js, where every particle is a glyph of the message you type. Drag to spin it, scroll to zoom, and the whole cloud breathes on a slow sine. It is the one project here whose correctness criterion is whether it looks right.
Tools2026
A Python harness for running simulation regressions
A small Python tool for driving repeated simulation runs and collecting their results. Placeholder copy — send me a line about what this one actually does and I'll rewrite it properly.
Analog / Simulation2026
Analog simulation work — bias points, transient response, frequency sweeps
LTspice schematics and simulation runs from analog circuits coursework. Placeholder copy — tell me which circuits these are and what you were characterizing, and I'll write this up properly.
Languages, simulators and boards I reach for by default — the ones I've taped a project out with, not the ones I've only read about.
