Page Outline

Student Organizations

Berkeley Formula Racing (Co-Lead: Su19-Sp20, Member: Fa18-Sp19)


Highlights:
  • B19: 16th out of 80 competitive teams
  • Design Projects: PCB Design, Telemetry, Solid Parts
  • Manufacturing: Efficient Workflow, Modularizing Harnesses, Easy Debug Mechanism

Intro: I spent 2 very exciting, fast-paced years with the Berkeley Formula Racing Team, most recently as Electrical Subsystem Co-Lead. In this organization, students design, build, and race a fully functional Formula-1 style racecar to complete in the annual Formula SAE competition. I worked with about 60 remarkably dedicated fellow students with a similar passion for fast cars. We all spent over 20 hours a week on the car! My first year, our team placed 16th place overall out of over 80 competitive college teams; our second year, we couldn't compete in person due to COVID-19 ๐Ÿ˜”.

Projects: Electrical's design season is spent on projects to further the performance of the car, such as PCB designing, live-telemetry for data acquisition in real-time, a board and casing to house the 6-axis accelerometer and gyroscope, and a dash PCB for shifting lights to indicate the ideal time to shift gears based on a torque-power mapping. For example, I significantly optimized the design and performance of a board called the Brake Plausibility Device (BPD). The board had to shut off the car in the event of a critical failure to protect the driver. For example, suppose that while running the car, a rock got lodged in the throttle, keeping it open at all times. Then, even if the driver pressed the brakes, they wouldn't be able to stop; the BPD had to contain the logic to detect that something must be wrong in such situations and shut off power to the car. This functionality was achieved with transistor-based logic.

Me sitting in our B19 competition car!

Manufacturing: Another primary responsiblity of Electrical is to ensure the mechanical robustness of the 3 primary wire harnesses; Power (ensure all components are powered), ECU (Engine Control Unit), and ADL (sensor data collection). By modularizing the harness bundle into 3 components, we made it much easier to debug and place on the car. As an example, a high-level design for our power harness can be found here. We also placed labels on each wire to avoid time-consuming multimeter continuity checks, easily saving several dozen man-hours over the years. A large amount of our production time is spent on these harnesses; ordering materials, manufacturing, placing the harnesses on the car, and debugging as issues come up in testing.

IEEE Professional Development (Director: Su19-Fa19, Officer: Fa18-Sp19)


Successful Event Examples:
  • Research Meet-and-Greets
  • Interview/Resume Workshops
  • Speed Mentoring
  • Website Design Workshop
  • Technical Writing Workshop

Contribution: Elected as Director of the Professional Development Committee for UC Berkeley's IEEE Student Branch, I helped organize over 20 events and originated many new event ideas. The events spanned from Research Meet-and-Greets to help undergraduates engage with research to Technical Writing and Personal Website Design Workshops to build communication skills and a professional brand. Each event required weeks of planning, especially to ensure that we had representatives from industry or research labs, as well as support from IEEE's members for staffing.

Why I Joined: IEEE introduced me to some of the brightest minds on campus, ensuring that I had a place to ask informed questions about classes and Berkeley life. It's been great to hear about the amazing research and activities people are engaged in, and I've been able to give some of this advice back as an IEEE mentor in recent semesters.

Class Projects

RISC-V Processor Design and Audio Synthesizer: FPGA Lab


Key Topics:
  • FPGA CPU Design
  • Memory-Mapped Peripherals
  • Fully Functional/Customizable Audio Synthesizer
  • Apple-Sponsored Project: FPGA Lab Outstanding Project Award

Project Description: In this project, my partner and I designed a pipelined RISC-V CPU that can carry out a fully-featured set of RISC-V instructions and has broad memory-mapped I/O functionality. The memory-mapped peripherals were part of the Pynq-Z1 FPGA board and allowed us to implement a functional audio synthesizer that the user could interact with. A block-level layout of the project can be seen in the report below. Since performance of the processor is key, our objective was initially to meet a processor CPI of 1.2, and we were ultimately tasked with minimizing the Iron Law. We were given an intensive reference workload to run (a defined, "untouchable" mmult.c matrix multiplication program), so we only had control over the CPI and the clock frequency.

Unique Feature - Branch Prediction: In pipelined processors, branch prediction is essential for increasing the cycles per instruction (CPI),and in turn the speed of the processor. After several iterations on our prediction scheme, we landed on the saturating counter. The counter utilizes the history of previous branch instructions to predict the outcome of future branch instructions. We tuned the bit width of the counter based on the reference workload. This prediction mechanism was an extra-credit feature.

Unique Feature - Verification Script: In order to make sure our processor worked for all instruction-ordering cases, we began by writing a comprehensive set of unit-tests for each instruction. Then, we wrote a fully-featured pseudo-randomized assembly code generator in Python. The goal was to emulate an industrial-strength verification tool (exercising maximum functional coverage and code coverage) with a narrowly defined scope for this particular project. The script incorporated all categories of instructions, where we could set the relative frequencies of each instruction to tune the workload and lean towards a particular set of edge cases in a given trial run. We could toggle the encouragement of data and control hazards, customize the number of instructions, and format expected register results. Each instruction was given a label for ease of specifying jumps, and the issue of infinite-looping was resolved by restricting jumps to a predefined, well-behaved range. In the end, the assembly program was written to a text file where the expected register values could be computed using the RISC-V compiler.

Results: By the end of this project, we completed our implementations of a three-stage pipelined RISC-V processor that successfully runs the mmult.c program with the correct checksum. We also fully memory-mapped and integrated all functional blocks into our core CPU design, with the ability to demonstrate all programs' functionality in hardware. Our audio synthesizer is fully integrated and functional, and all of our various programs and blocks run at the same clock frequency. Our design was selected one of two winning FPGA Lab undergraduate groups. To see our report, see below (or in a new tab).

Low-Power, High-Slew Operational Amplifier Design (Smartwatch LCD Driver)


Key Topics:
  • Cadence 6 Amplifier Design and Simulation
  • Matlab GM/ID Design Methodology
  • Apple-Sponsored Project: Design Finalist

Project Description: The goal for this final project was to design a driver circuit for a smartwatch LCD display, with a liquid crystal cell modeled as a 30 pF, 800 Ohm load. I used a two-stage amplifier (input stage was a high-gain telescopic-cascode differential pair, output stage was a high-swing class AB stage using a source-follower to act as the bias-voltage level-shifter). Outside the amplifier itself, we had a capacitive feedback network that sampled 1/3 of the output voltage to the inverting input, and this set our closed loop gain of the amplifier to be 2.

Results: The design constraints specified a power consumption less than 750 microwatts and a transient settling time under 180 nanoseconds. My final design had a power consumption of 160 microwatts while meeting the settling time (179 nanoseconds). My design was selected as a top 3 project finalist, where I presented to a panel of judges (analog designers from Apple). To see my presentation, see below (or in a new tab). Please email me for a copy of the full report, including my circuit schematic, detailed design approach, and final results.

NMOS Device Design


Key Topics:
  • TCAD (Sentaurus Workbench)
  • Device Physics
  • Theoretical / Experimental Device Optimization
  • Technical Writing

Background / Motivation: In my EE 130 device design class, I used TCAD (Sentaurus Workbench) to numerically simulate the behavior of a custom-designed NMOS device. The channel length was specified at 25 nm (based on the 20 nm CMOS generation). The goal for this project was to become familiar with how practical transistors are designed, keeping specifications and tradeoffs in mind. We want to maximize active (on) current and decrease leakage (off) current. As an example, decreasing channel doping causes drain-induced barrier lowering (DIBL), leading to greater leakage current, but increases on-current (higher mobility, less ion-scattering). I explored the effects of such parameters and extracted useful information from the software in order to optimize current consumption (Ion and Ioff), subthreshold swing, and transconductance. I furthermore used my knowledge of device physics to explain what implications a certain design decision would have, and the rationale behind my choices.

Software Details / Results: The software self-consistently solves the electrostatics equations for a given set of device parameters to numerically determine the current at different applied gate and drain voltages. It also constructs images of device layouts for visualization. The parameters experimented with include channel doping, source/drain extension depths, various dopant concentrations, the gate-dielectric spacer length, and others. By optimizing the parameters, I achieved an Ion to Ioff ratio of 1.04 * 1018, 21 times better than the default value. Please email me for a copy of the full report, including tables and figures outlining my findings such as the sample ones below.

Data from Experiments Run with Varying Dielectric Spacer Length Lsp. Default Shown in Red.

Graph of Current Consuption at Varying Dielectic Spacer Lengths (note Ion and Ioff tradeoff).

BJT/MOS Amplifier Designs


Key Topics:
  • Hardware Data Collection
  • Transistor Biasing
  • Experimental Capacitance Measurements

Equipment / Project: For my EE 105 class, our final labs consisted of single-stage BJT and MOS amplifier designs. In the preliminary labs, we characterized device behavior for a diode and BJT using a Semiconductor Parameter Analyzer (Agilent 4155C), connecting our experimentally observed curves to the physics behind them. We used SpaZilla, a Labview program, for instrument control and data acquisition. One of the important tasks was characterizing the parasitic capacitance (from the breadboard and equipment) vs. the component capacitance. To do so, we measured the cutoff frequency for different bias voltages, constructed a graph, and linearly extrapolated the zero-bias capacitance.

Results: Once we learned about DC biasing, we constructed amplifier circuits and measured performance with varying component values, experimentally and in LTspice. Figuring out a way to bias the circuits to maintain a temperature-independent bias point was challenging, but with practice, analyzing transistor-based circuit configurations became much more intuitive.

Cooke Triplet Optical Device Optimization


Key Skills:
  • Zemax Optical Studio
  • Ray Fan / Vignetting / Spot Diagrams,
  • Optical Imaging Design
  • Optical Device Optimization

Background: A Cooke Triplet is a 3-lens configuration that, when designed well, can entirely remove second-order aberrations (monochromatic and chromatic both) and function as an effective imaging device. However, each lens has two surfaces which can have varying radii of curvature and can be made of different materials, and the lenses have distances between them, so there are many variables involved.

Process, Results: In my EE 118 Final Project, we used Zemax Optical Studio for our analysis of the Cooke Triplet, and observed ray fan plots, spot diagrams, vignetting diagrams, and more to optimize the system. We also analyzed the parameter tolerances to gauge the most important variables (that is, which variables were most sensitive, and had to be given highest fine-tuning priority). For more details about the tools used and the design process, please see our presentation below (or in a new tab) and our final report.

Avatar-Based Maze Game


Key Topics:
  • Advanced Java
  • BFS /DFS Algorithms
  • Game Design

Background: Our final CS 61B project was to create a game; the core constraints were that the tile-based environment must be (pseduo-)randomly generated, and for extra credit, there must be some kind of avatar that is user controlled, and there must be a way to "win" or complete the game. We took these concepts and built a remarkably intricate game that we and friends genuinely enjoyed playing, beyond just for the class. The gameplay was as follows (taken directly from our "folklore/background" section of the project):

Description: The goal of the game is as follows: you control an avatar, the white star. By using the WASD keys to move around, you can avoid the menacing exclamation marks (!) intelligently following you around. You ultimately want to get to the yellow locked door (multiple times!) to win the game and attain absolute glory. Be careful, there are rules to follow. Once you traverse a tile, it becomes more red, and eventually, it'll become a deadly lava tile. If you go over one, you lose a life (you have 5 to begin with). If the (!) hits you, you lose a life. Try and collect flowers! They're on your side; the less health you have, the more likely they are to grant a life. Each turn, you also have a chance to generate new flowers! Don't worry about running out ๐Ÿ˜„

Customizability: As a user, you can toggle the wall color scheme, see an interesting bit of background for the game, toggle a super-hard mode, and customize your gameplay. As a programmer, you can do so much more; alter the room-generation algorithm to make easer/harder maps, modify the enemy behavior, change the spawn frequency and helpfulness of flowers; the list is endless. Take a look below for an idea of how the game looks!

Home page

Starting world, with super-color mode toggled on.

A not-so-colorful starting world (color mode toggled off).

Creating a trail of lava tiles behind me in the top-right corner (not so smart!)

Unlocking a door makes the world darker, with a torchlight-effect around the avatar.

Sample video of start menu, folklore, music, and a successful win!


Voice-Controlled Robot Car


Key Topics:
  • Filtering Circuits
  • Classification (PCA, SVD)
  • Integration (Microphone Circuitry, Sound Processing, Stable Car Movement)

Background: The goal of this semester-long project was to use linear algebra and circuits principles to build a car that could respond to a constrained set of voice commands, and perform actions based on what was spoken. A microphone collected the audio, which was processed by the on-car low-power Launchpad microcontroller board. Once the audio was filtered, it was then classified as one of 4 words; the selected word determined the car's action. We applied close-loop feedback to ensure steady-state error correction; with open-loop feedback, the car did not move smoothly.

Design Details / Results: Our microphone circuitry consisted of a band-pass filter to isolate frequencies outside normal human speech. The signal was level-shifted and gained up by an amplifier, with noise and signal drift removed by a decoupling capacitor. It took over 40 voice recordings to find 4 viable words ("moose," "blob," "oscillate," "multiplicity") that the PCA classification could achieve high accuracy with. Yes, we're aware that in a practical setting, you perhaps wouldn't want to say "blob" to make a car go forward ๐Ÿ˜‰. For many other word combinations, two or more of the resulting k-means clusters would be too close together, and results were muddled. But in the end, our Integration checkoff went smoothly, as our car responded correctly to all of the given commands! Granted, there was some shouting and repetition but overall, definitely a success.

Other Projects

CalHacks 6.0: Sign-ify iOS app (Best Weights and Biases API Prize) (Nov. 2019)


Key Topics:
  • iOS App Design
  • Real-time Speech-to-ASL
  • Algorithm (Dynamic Video Adjustment + Self-Correction)

Background: I've always been interested in teaching, and I'm aware of the importance of creating an inclusive environment. Imposter syndrome runs rampant, and it's our job as a community to ensure everybody is comfortable exercising their opinion and doing what they need to learn best, be it asking questions during lecture, turning to a friend for help, or reviewing past course materials. In this 36-hour hackathon, we focused on the underserved community of deaf or hard-of-hearing students, who communicate, understand, and think primarily in ASL. The majority of deaf people do not have an โ€œinner voiceโ€; instead they often sign ASL in their heads to themselves. For this reason, deaf students are largely disadvantaged in academia, especially with regard to live attendance of lectures. Our app enables enhanced live-lecture for members of the ASL-speaking community by intelligently converting the professor's speech to a sequence of ASL videos for the user to watch. This style of real-time audio to ASL conversion has never been done before.

Process: We broke down the development of the app into 3 phases: converting voice to speech, converting speech to ASL videos, and connecting the two components together in an iOS application. We decided to combine speech recognition models including Pocketsphinx, Mozilla DeepSpeech, iOS Dictation, and more in an ensemble model. We ran tests against Google's Speech-to-Text and ensured that the software was dynamically editing previous words using context of neighboring words.

Reflection: As a team we were most proud of our ability to quickly learn new frameworks and use Machine Learning and Reinforcement Learning to develop an application that was scalable and modular. While we were subject to a time restriction, we ensured that our user interface was polished, and that our final app was a usable product. We pushed ourselves to learn unfamiliar skills so that our solution would be comprehensive and could benefit an entire community.

Ascend x Travonde Case Competition (1st Place) (Oct. 2019)


Key Topics:
  • Web Interface Mockup
  • Presentation + Q&A
  • Market Research, Business Strategy

Background: We went through 2 elimination rounds, each with a presentation and judge Q&A. At the end, once we were named as the first place winners, we met and talked with Steve Wozniak!

Here's a condensed summary of our final report: For the Ascend x Travonde Software Engineering challenge, our goal was to optimize the engagement that members of the older-adult community have. After extensive market analysis, we realized that there is a significant dearth of opportunities for older people to form deeper interpersonal connections. This is partly because of the rapid advent of new technological frameworks. So, we developed a multifunctional tool to facilitate this process. Our registration survey collects logistical and personality information from those interested in connecting to other locals. Then, we process the data using a performant matching algorithm and make an informal introduction through our chat interface suggesting some curated and personalized activities for an initial gathering.

What We Built: Our product is a sleek, elegant workflow modeled with a web interface. Once we match users, we would initiate a conversation between them, providing them with transportation and residency options for an activity of their choice. And finally, at the end of their meet-up, we will solicit feedback to further improve the workflow. This product has the potential to disrupt the current location-based social media market by targeting the portion of the population who have much more disposable income, ultimately bringing them an opportunity they may have lacked before.