Built. Researched. Shipped.
A portfolio of technical work — from silicon to software.
SRAM (Static Random-Access Memory) is one of the most fundamental building blocks in modern processors and SoCs — every CPU cache, every register file, and every on-chip memory array is built from SRAM bitcells. Despite its ubiquity, SRAM design involves a set of competing constraints that are non-obvious: the same transistors that must hold data reliably must also allow it to be read and overwritten — and those requirements pull in opposite directions at the circuit level. I chose this project to understand that tension at the transistor level by building and simulating a real SRAM cell from scratch rather than just reading about it.
I designed the full 6T SRAM bitcell in LTspice using 180nm MOSFET Level-1 models. The cell consists of two cross-coupled CMOS inverters forming the storage latch (M1–M4), and two NMOS access transistors (M5–M6) controlled by the Wordline (WL). I wrote both SPICE netlists entirely from first principles — defining every transistor's width, length, threshold voltage, transconductance parameter, and channel-length modulation manually, without using any template or pre-built cell.
I then built separate testbenches for three operating modes. For hold mode, I kept WL deasserted and verified that Q and QB stayed stable indefinitely. For read mode, I precharged both bitlines to VDD, then pulsed WL high and observed the differential voltage develop across BL and BLB. For write mode, I drove BL to 0V and BLB to VDD simultaneously with WL assertion, forcing the latch to flip its stored state.
The most important result came unexpectedly. During the read simulation, the stored value flipped — Q inverted when WL went high, even though no write operation was being performed. This is a real and well-known failure mode called read disturb. It occurs because when the access transistors (M5–M6) are equally sized as the pull-down transistors (M2, M4), the current path through access → pull-down is strong enough to pull Q below the switching threshold of the opposite inverter, flipping the latch.
Real SRAM designers prevent this by using a cell ratio (CR) — typically CR ≥ 2 — where the pull-down transistors are made significantly wider than the access transistors, ensuring the storage node stays stable during reads. This is a classic design margin trade-off: a higher cell ratio improves read stability, but a higher pull-up ratio (PR) is needed to maintain write ability. I discovered this tension through simulation rather than a textbook, which gave me genuine intuition for why transistor sizing decisions in memory design are so consequential.
Writing SPICE netlists from scratch, interpreting transient simulation waveforms, understanding MOSFET operating regions in context, reasoning about device sizing tradeoffs, and grasping design margins — the gap between nominal operation and a failure mode. These are exactly the skills used in the analog IC design work I do at GT ICE Lab with the SKY130 process, making this project directly relevant to my ongoing research.
* 6T SRAM - Hold & Read Sim .param VDD=1.8 VVDD VDD 0 {VDD} * Cross-Coupled Inverters M1 Q QB VDD VDD PMOS W=500n L=180n M2 Q QB 0 0 NMOS W=500n L=180n M3 QB Q VDD VDD PMOS W=500n L=180n M4 QB Q 0 0 NMOS W=500n L=180n * Access Transistors M5 BL WL Q 0 NMOS W=500n L=180n M6 BLB WL QB 0 NMOS W=500n L=180n * Bitline Precharge (weak) RBL BL VDD 1k RBLB BLB VDD 1k * WL pulse → triggers read VWL WL 0 PULSE(0 1.8 5n 0.1n 0.1n 10n 40n) * IC: Q=1 (storing logic 1) .ic V(Q)=1.8 V(QB)=0 V(BL)=1.8 V(BLB)=1.8 .tran 0.01n 60n .model NMOS NMOS(Level=1 VTO=0.5 + KP=270u LAMBDA=0.01 TOX=5n) .model PMOS PMOS(Level=1 VTO=-0.5 + KP=90u LAMBDA=0.01 TOX=5n) .end
* 6T SRAM - Write Simulation .param VDD=1.8 VVDD VDD 0 {VDD} * Cross-Coupled Inverters M1 Q QB VDD VDD PMOS W=500n L=180n M2 Q QB 0 0 NMOS W=500n L=180n M3 QB Q VDD VDD PMOS W=500n L=180n M4 QB Q 0 0 NMOS W=500n L=180n * Access Transistors M5 BL WL Q 0 NMOS W=500n L=180n M6 BLB WL QB 0 NMOS W=500n L=180n * WL + BL driven for write VWL WL 0 PULSE(0 1.8 5n 0.1n 0.1n 20n 60n) * BL=0 forces Q → 0 (write 0) VBL BL 0 PULSE(1.8 0 5n 0.1n 0.1n + 20n 60n) VBLB BLB 0 1.8 * IC: Q=1 → will flip to 0 .ic V(Q)=1.8 V(QB)=0 .tran 0.01n 60n .model NMOS NMOS(Level=1 VTO=0.5 + KP=270u LAMBDA=0.01 TOX=5n) .model PMOS PMOS(Level=1 VTO=-0.5 + KP=90u LAMBDA=0.01 TOX=5n) .end
All 6 transistors use identical W/L = 500n/180n. This equal sizing causes read disturb — the access path can overpower the latch during reads. A real SRAM would use Cell Ratio ≥ 2 (wider pull-downs) to prevent this.
At Georgia Tech's Integrated Computational Electronics (ICE) Lab, I contribute to the design and synthesis of analog standard cells and Field-Programmable Analog Arrays (FPAAs) using the open-source SKY130 CMOS process — a 130nm process node made freely available through Google and SkyWater Technology's open-source PDK initiative.
My work spans the full analog IC design stack. At the device level, I study and apply MOSFET physics in the SKY130 process node. At the circuit level, I design standard analog cells: differential pairs, current mirrors, transconductance amplifiers (OTAs), comparators, and reference circuits. At the physical level, I work on IC layout in KLayout — translating schematic designs into geometric layers on silicon. All layouts undergo DRC and LVS verification to ensure they are fabrication-ready.
FPAAs are uniquely suited for applications at the physical-digital boundary — sensor interfaces, edge AI inference, biomedical monitoring, and energy-harvesting systems where every microwatt matters. As a freshman contributing to this research, I am building the foundational expertise — device physics, circuit design, IC layout, simulation methodology — that will define my engineering career in chip design.
Tastecast AI is a real-time intelligence platform for local restaurants — giving independent operators the data-driven insights that large chains have had for years. Restaurants generate enormous amounts of data about what sells, when, and to whom — but most independent owners lack the tools to act on any of it. Tastecast changes that.
As Co-Founder and CEO, I led every dimension of the product: vision, UI/UX design, and full frontend development in React with Firebase. Before writing a single line of code, I conducted over 30 customer interviews with restaurant owners across Atlanta. Those interviews revealed that the highest-value pain points were waste and stock-outs. The product was designed entirely around solving those two problems first.
Tastecast was submitted to Y Combinator and ranked in the top 10% of all applicants globally — a meaningful signal from one of the world's most selective startup accelerators. We ran live pilot tests with local Atlanta restaurants, collecting feedback that is now driving the next iteration of the product.
For my CS1301 Discovery Project, I designed and programmed a fully autonomous maze-solving robot using an iRobot Create3 platform. The robot navigated a physical maze it had never encountered before — no pre-loaded map, no external guidance. It built its spatial understanding in real time and found the optimal path entirely on its own.
The navigation engine is built on a flood-fill pathfinding algorithm. The algorithm assigns each cell a distance value from the goal. As the robot explores and discovers walls, it updates these values dynamically. At each decision point, the robot moves to the adjacent cell with the lowest value — converging on the globally optimal path over time.
Debugging a moving physical system is fundamentally different from debugging software. I built a real-time visual and audio debugging system: LED color codes indicated the robot's current state, while distinct beep sequences confirmed wall detections and movement completions. This project was my first experience bridging software and physical hardware.
Modern computing faces a fundamental bottleneck: processor speeds have increased exponentially, but the bandwidth and latency of moving data between memory and compute units has not kept pace. In AI and data-intensive workloads, this data movement now consumes more energy than the actual computation itself.
At NYU Abu Dhabi, I worked on pLUTo — Processing-in-Memory using Lookup Tables — a framework from CMU's SAFARI Research Group that moves computation to the data: look-up table operations are performed directly inside DRAM arrays, eliminating costly memory bus transfers. My role was to develop and validate hardware models of pLUTo-enabled systems, simulating how real-world workloads behave when computation is pushed into the memory subsystem.
The simulation infrastructure was built on Ramulator 2.0 — a cycle-accurate DRAM simulator for academic computer architecture research. I extended it with C++ modules modeling pLUTo's compute-in-memory operations, scripted workload injection pipelines, and wrote analysis scripts to extract performance, latency, and energy trade-off data from simulation outputs.
Internfinity was a two-sided marketplace I co-founded at age 15, designed to solve a structural problem in Dubai's high school ecosystem: students with genuine ambition had no structured pathway to access real internship opportunities, and companies had no efficient way to find and vet high school candidates.
Over two years, Internfinity partnered with more than 15 companies across Dubai — including a formal partnership with Microsoft for Startups and the Indian Consulate in Dubai. We listed over 100 curated courses alongside internship listings, creating a pre-internship development pipeline. By the end of operations, we had successfully placed 10 students in real internship positions.
Running a two-sided marketplace as a high school student taught me more about sales, operations, and stakeholder management than any course could. It also gave me the confidence to start Tastecast AI the moment I arrived at Georgia Tech.