Brahin UddinClick a button below to jump to that section. Hover over one for a preview.Tap a button to jump to that section

Brahin Uddin

I design digital hardware in SystemVerilog, verify it against reference models, and run it on FPGAs.

Headshot of Brahin Uddin
  • Rutgers University–New Brunswick · B.S. Electrical Engineering, minor in Computer Science · Class of 2028
  • Honors College · Engineering Honors Academy · Dean's List
  • New Brunswick, NJ

Open to Summer and Fall 2027 internships in FPGA, RTL, ASIC and verification.

Plus industry experience: a summer at Crusoe working with reliability, controls and commissioning teams on AI data center infrastructure, from the rack up to site power.

Open resume (PDF) Email me GitHubLinkedIn
Y1U4TP1-4 J1 ITCH decoder73.5 ns median RV32IM core2.857 CoreMark/MHz NanoGuardpre-trade risk U1 U2 U3 D1 B. UDDIN REV A 2026
U1

Low-latency Ethernet market-data decoder

SystemVerilog on a Xilinx Zynq-7020, July 2026 to now

In shortCustom digital hardware on an FPGA (a reprogrammable chip) that reads stock-exchange messages straight off an Ethernet cable and decodes each one in about 73 nanoseconds in simulation.

A Nasdaq TotalView-ITCH 5.0 parser that takes raw Ethernet off the wire and hands out decoded order-book messages, entirely in FPGA fabric.

  • I wrote the Ethernet MAC, IPv4/UDP and MoldUDP64 parsers to work cut-through: fields are decoded while the frame is still arriving, and a bad checksum at the end rolls the work back.
  • I designed a Gray-coded async FIFO to carry data from the 125 MHz PHY clock to the 200 MHz core clock, and sized it from the clock ratio and frame length.
  • I built a 10-test cocotb regression that compares the RTL against a Python golden model, with fault injection: 7,430 records, zero mismatches.
  • I scripted the Vivado build in Tcl, captured RGMII with IDELAYE2/IDDR and BUFIO/BUFR clocking, and closed timing at 200 MHz (WNS +0.185 ns).
See the code on GitHub
Puzhi PZ7020-StarLite FPGA board with the AMD Zynq-7000 chip, powered over USB-C, DONE LED lit.
The PZ7020-StarLite (Zynq XC7Z020) configured with the decoder bitstream; the DONE LED shows the FPGA is programmed.
12 nsIDDR + GMII capture
16 nsMAC hold
24.8 nsclock crossing
20 ns4 core stages
Where the nanoseconds go on the median path. The budget sums to 72.8 ns; the measured median is 73.5 ns (min 70.9, max 75.9, 2,991 samples, simulation).
Histogram of wire-to-record latency for 2,991 messages. Counts are spread almost evenly, about 70 to 100 messages per bin, between 70.9 and 75.9 nanoseconds, with nothing outside that range.
Wire-to-record latency for 2,991 messages at 1 Gb/s line rate: median 73.5 ns, min 70.9, max 75.9. The flat 5 ns spread is one 200 MHz clock period, set by where each byte lands relative to the core clock at the clock-domain crossing.
Vivado block design: the Zynq ARM processing system drives an AXI SmartConnect into the feed handler block fh_wrap, with a clocking wizard and two processor-reset blocks supplying the core clock and resets, and the three RGMII receive pins entering the feed handler from the left.
The Vivado block design: the ARM talks to the feed handler over AXI through a SmartConnect, a clocking wizard makes the 200 MHz core clock, and the RGMII pins go straight into the fabric.
ITCH feed handler: wire to record Receive path in the Zynq-7020 fabric. Nothing between the PHY pins and the decoded record touches a processor. rx_clk 125 MHz (recovered by the PHY) core_clk 200 MHz PL PHY RTL8211F RGMII 1 Gb/s u_rgmii RGMII capture IDELAY + IDDR BUFIO / BUFR, 0 LUT u_mac Ethernet MAC preamble strip, CRC-32 67 LUT, 66 FF u_cdc Async FIFO 16 deep, Gray pointers, 2-flop synchronizers 54 LUT, 8 LUTRAM u_udp IPv4 / UDP header checks, port filter 92 LUT, 90 FF u_mold MoldUDP64 sequence and gap check 420 LUT, 495 FF u_itch ITCH 5.0 decode 8 msg types, watchlist 581 LUT, 958 FF record 512-bit, 1 per msg u_recq Record queue 512 entries, block RAM 7.5 BRAM, 201 LUT u_regs AXI4-Lite regs config, counters, pop 393 LUT, 704 FF AXI4-Lite SmartConnect 200 to 100 MHz PS Dual Cortex-A9 control plane, 100 MHz Last byte of one Add Order, time after it reaches the pins (cocotb simulation) 0 ns12 ns28 ns52.8 ns57.8 ns62.8 ns67.8 ns72.8 nsat pinsIDDR + GMIIMAC outin core clockUDP payloadMold messageITCH decoderecord valid Wire-to-record latency 72.8 ns (median 73.5 ns, n = 2,991) DeviceXC7Z020-2, PZ7020-StarLite Timing at 200 MHzWNS +0.185 ns, all met Fabric used1,824 LUT (3.4%), 2,459 FF Drawn byB. Uddin, Rev A
The receive path, wire to record, with each module's resource use and the time the last byte of an Add Order reaches each stage.
GTKWave trace of the decoder. RGMII nibbles and GMII bytes of one frame arrive on the receive clock; after the last byte, done_q pulses and rec_valid goes high on the core clock, with rec_type 41 (Add Order), the stock field and the price 0012345A on the record outputs.
Simulation waveform (cocotb + Icarus, viewed in GTKWave): one Add Order arriving on the RGMII pins and its decoded record leaving 72.8 ns later.
Vivado device view of the placed design on the Zynq-7020. The feed handler's cells sit in a compact block near the center-left of the fabric, colored by module: magenta RGMII capture, yellow MAC, green UDP parser, blue MoldUDP64, purple ITCH decoder, orange record queue, red AXI4-Lite registers. Green routing fans out to the ARM processor system on the left.
Where the design sits on the Zynq-7020, one color per module.
Vivado Design Timing Summary: worst negative slack 0.185 ns, worst hold slack 0.067 ns, worst pulse width slack 0.264 ns, zero failing endpoints, and the message: all user specified timing constraints are met.
Vivado timing after place and route: all constraints met at 200 MHz, worst setup slack +0.185 ns.
Median latency, pin to record
73.5 ns sim
Throughput
3.39M msg/s line rate
Timing at 200 MHz
WNS +0.185 ns
Device use
3.4% 1,824 LUT, 2,459 FF
U2

RV32IM five-stage pipelined RISC-V core

SystemVerilog on a Xilinx Zynq-7020, March to July 2026

In shortA processor I designed from scratch: it runs standard RISC-V programs, passes all 48 official tests, and matched a reference simulator over 12.5 million instructions.

An in-order CPU that runs real RISC-V programs on the FPGA, with the Zynq's ARM core loading programs and acting as the console.

  • I designed the five-stage pipeline with full operand forwarding, a load-use interlock and precise exceptions (Zicsr).
  • I built the multiplier on DSP48 slices, pipelined so it doesn't limit the clock.
  • I set up the verification: the official riscv-tests and RISCOF suites, plus an instruction-by-instruction lockstep check against the Spike reference simulator.
  • I benchmarked it with CoreMark in simulation, with a CPI breakdown from hardware performance counters.
See the code on GitHub
Terminal output of the riscv-tests run: every rv32ui and rv32um test, from lui through remu, marked PASS with its cycle and retired-instruction counts, ending in the line five-stage: 48/48 passed.
riscv-tests rv32ui and rv32um on the five-stage core: 48 of 48 pass.
RV32IM five-stage pipeline In-order, one instruction per cycle. Full forwarding into EX; the hazard unit stalls only when a value is not ready yet. branch mispredict in EX (1-cycle penalty) trap or MRET from MEM PC Branch predictor 64-entry BTB, 2-bit IF fetch at next PC BRAM output doubles as the IF/ID register IMEM 32 KB BRAM, 1 cycle IF/ID ID/EX EX/MEM MEM/WB ID decode, immediates register file, 2 read ports write-through from WB EX ALU, branch resolve MUL stage 1 (DSP48) divider, 33-cycle rs MEM load / store, MUL stage 2 CSR access, traps commit point DMEM 32 KB BRAM, 1 cycle WB select result write rd, retire register write-back forward from EX/MEM forward from MEM/WB Hazard unit ID source regs vs. EX destination load, MUL or CSR result not ready yet hold PC hold IF/ID insert bubble A dependent instruction right behind a load waits one cycle in ID, then takes the value from MEM/WB. Everything else forwards with no stall. ISARV32I + M + Zicsr, machine mode Verificationriscv-tests 48 / 48, Spike lockstep TargetZynq-7020, programs loaded by the ARM Drawn byB. Uddin, Rev A
Full forwarding into EX; the pipeline only stalls when an instruction needs a value that isn't ready yet.
GTKWave trace of the core. The load_use signal goes high for one cycle while the ID-stage PC holds, then the forwarding selects fwd_a and fwd_b switch to pick values from the EX/MEM and MEM/WB stages, and instructions retire on rvfi_valid.
Verilator waveform of a load-use stall: add t3 waits one cycle behind lw t2, then takes the loaded value from MEM/WB; the next two instructions forward from EX/MEM and MEM/WB.
Performance
2.857 CoreMark/MHz
CPI on CoreMark
1.117
Compliance
48 / 48 riscv-tests
47 / 47 RISCOF
Lockstep with Spike
12.5M instructions, 0 divergences
U3

NanoGuard: FPGA pre-trade risk checks you can change in minutes

Rutgers TechStart 2026, finalist (top 5 of the competition), team of six

In shortA startup prototype, and top-5 finalist at Rutgers TechStart 2026, that lets compliance staff change hardware trading-risk checks in plain English instead of waiting weeks for engineers.

Brokers with direct market access must check every order before it reaches the exchange (SEC Rule 15c3-5). FPGA checks are fast, but changing a rule takes weeks of engineering. NanoGuard was my idea for closing that gap, and I built the working prototype we demoed live to the judges.

  • I wrote the Verilog risk-check module: restricted list, max order size, price collar and capital limit, in a 2-stage pipeline with configurable registers.
  • I built the Python pipeline: the LLM rule builder with a constrained tool schema, a validator against the template catalog, a compiler to register values, and the approval step.
  • I verified the RTL against a Python reference model on 100,000 random orders, with zero mismatches, and built the Streamlit demo we ran on stage.
A later version of the dashboard, with an experimental design agent: a risk rule typed in plain English becomes a pipeline and an RTL circuit, elaborated with Yosys and simulated in Icarus Verilog, with all 27 test orders matching the expected result. The on-stage demo was an earlier Streamlit app.
  1. AI proposesA compliance officer types a rule in plain English. An LLM maps it to a pre-verified hardware template.
  2. Tests verifyThe rule is compiled to register values and checked in simulation with Icarus Verilog.
  3. A human approvesNothing reaches the hardware without sign-off. Out-of-scope requests become engineering tickets.
  4. Hardware enforcesThe FPGA checks every order in about 2 clock cycles. The AI is never in the trading path.
NanoGuard risk check: order to decision risk_check.v. Two pipeline stages, one order per clock. The approved rule only writes register values; the checks themselves are fixed RTL. SOFTWARERule compilerafter human approval cfg port CONFIGURATION REGISTERS · cfg_we / cfg_addr / cfg_data[63:0] 0x00max_qty4 clients 0x10capital_limit4 clients 0x20ref_price8 symbols 0x30collar_bps8 symbols 0x40restricted_mask8 bits ORDER INOne order per clock in_valid client [1:0] symbol [2:0] qty [31:0] shares price [31:0] cents STAGE 1 · per-order checks, in parallel STAGE 2 · capital check and decision Restricted symbolrestricted_mask[symbol] Max order sizeqty > max_qty[client] (0 = no limit) Price collar|price − ref| × 10000 > bps × ref Notionalqty × price, for the capital check limits stage-1 regs PRIORITY DECISIONFirst failing check wins 1 restricted 2 max size 3 price collar 4 capital else pass Reason code 0 to 4goes out with the decision. restricted too big off collar Capital limitexposure + notional > limit notional over cap capital_limit Running exposureone per client, held in registers add notional only when the order passes output regs DECISION OUTout_validout_passout_reason [2:0] clock 1 clock 2 · 2 cycles, in_valid to out_valid Latency2 cycles, one order per clock Verification100,000 random orders, 0 mismatches Sized for4 clients, 8 symbols (parameters) Drawn byB. Uddin, Rev A
The risk-check RTL: four checks in two pipeline stages, with every limit in a configuration register that the approved rule writes.
The six-person NanoGuard team standing outdoors on a sunny campus plaza in business dress. Brahin is in the center in a black suit and tie holding a notebook; the other members' faces are blurred.
Team: Asmitha Kornepati, Varsha Krishnan, Mahmoud Selim, Aayush Gokhale, Sreekar Muktevi and me (center).
PCB1

AeroBin: a clip-on fill-level sensor for any waste container

Custom ESP32-C3 board in KiCad, Verizon Smart Campus Competition 2026–27

In shortA circuit board I designed for a clip-on sensor that reports how full a waste container is, for the Verizon Smart Campus Competition.

AeroBin clips onto a bin that's already in place and reports how full it is, so pickups happen when a container needs one instead of on a fixed schedule. It won first place in last year's Verizon Smart Campus Competition, which took the team to Verizon headquarters. This year we're building it to track any waste container and to earn real revenue for Verizon. We're developing it with Verizon's engineering mentors, and Qualcomm has offered its technology to help.

  • I defined the hardware architecture and chose the sensor, power path and microcontroller.
  • I designed the V1 board in KiCad: a 45 × 32 mm two-layer PCB around an ESP32-C3-MINI-1 module, with a VL53L1CX time-of-flight sensor on I²C that measures the distance down to the waste.
  • I built the power path: USB-C input with USBLC6 ESD protection, an MCP73831 Li-Po charger, a JST-PH battery connector, an RT9080 3.3 V regulator, and a divider so the firmware can read the battery voltage.
  • I designed it for bring-up: seven labeled test points (3V3, VBAT, GND, UART TX/RX, I²C SCL/SDA), BOOT and EN buttons, a status LED, and native USB for flashing.
  • I'm designing the 3D-printed enclosure the board mounts in.

V1 connects over Wi-Fi so we can demo a working unit now; the product is planned to run on Verizon LTE-M.

Board
45 × 32 mm 2 layers, 1.6 mm
Parts
41 placed
Routing
558 tracks, 101 vias
Status
Routed awaiting fab
KiCad 3D render of the red AeroBin V1.0 board. The ESP32-C3 module with its PCB antenna runs along the left edge, the small time-of-flight sensor sits in the middle, a USB-C connector is on the right edge, two push buttons and three gold test pads are along the bottom, and the battery connector footprint is at the top right.
KiCad 3D render of V1: the ESP32-C3 module on the left, the time-of-flight sensor in the middle, USB-C on the right, and the BOOT and EN buttons and test points along the bottom.
KiCad PCB editor view of the routed board, with front copper in red and back copper in blue, ground poured on both layers, silkscreen labels on every part and test point, and copper kept clear under the module's antenna on the left.
The routed two-layer layout, with ground poured on both sides and copper kept clear under the module's antenna.
  1. A line per containerEach AeroBin is planned to run on its own Verizon LTE-M line, so every container we track is another paid connection.
  2. Any containerIt clips onto bins, dumpsters and recycling containers that are already deployed, so the number of lines grows with every site.
  3. Copper and device recyclingWe're targeting the containers that collect copper and old devices for recycling. The copper telecom companies are pulling from retired networks alone is worth over $7 billion, by one industry estimate.
The AeroBin V1 schematic. Top row, left to right: the USB-C connector with 5.1 kilohm CC resistors and a USBLC6 ESD protector on the data lines, the battery connector and MCP73831 Li-Po charger, and the RT9080 3.3 volt regulator. Below: the status LED, a 1 megohm divider for battery sensing, the VL53L1CX time-of-flight sensor on I2C with its interrupt and shutdown lines, the ESP32-C3-MINI-1 module with BOOT and EN buttons, and a row of seven test points.
The V1 schematic: USB-C input and ESD protection, Li-Po charger, 3.3 V regulator, ESP32-C3 module, time-of-flight sensor, battery sensing and test points. Open the full sheet.
BOM

Other boards and builds

Printed circuit boards and robotics from team projects

In shortOther circuit boards and builds from my student engineering teams: the solar car and a lunar mining robot.

RefBuildWhat I didStatus
PCB1AeroBin sensor board
Verizon Smart Campus Competition		Custom ESP32-C3 board in KiCad and a 3D-printed enclosure for a clip-on fill sensor. Detail sheet PCB1.Awaiting fab
PCB2LV3 Core carrier board
Rutgers Solar Car		Designed the STM32G4 mixed-signal board for battery telemetry and protection: reverse-polarity protection, voltage sensing, buck regulation. Brought it up on the car.Built
NET1Low-voltage CAN network
Rutgers Solar Car		Engineered a daisy-chained FDCAN topology linking 8 boards for real-time data between the battery managers and peripherals.Built
PCB3Lunabotics robot controller
Space Technology Association of Rutgers		Designed the board linking a Jetson Nano to sensors and motor controllers; wrote C and Python motor control and SLAM navigation on ROS 2.Built
DC1

Crusoe: data center facility operations

Facility Operations intern, May to August 2026, San Francisco, CA

In shortMy summer internship at an AI data center company, where I mapped a site's power and cooling equipment and worked on giving each piece one name every system agrees on.

Crusoe builds and runs AI data centers. I worked across the reliability, controls and commissioning teams. Most of my summer went to one problem: the same piece of equipment had a different name in the maintenance system, in SCADA and in the cloud dashboards, so nothing could be matched automatically.

Asset map
716 assets
Naming standard
5 levels from 7
Tag parser
23 unit tests
Equipment lists
12 missing types found
  • I built the asset map for a deployed modular site: 716 electrical, mechanical, security and life-safety assets, each linked to the asset that feeds it, so the power path from substation to rack PDU can be walked without opening a drawing.
  • I proposed a five-level naming standard for modular sites, adapted from a seven-level standard written for large buildings, and measured row by row how far the live SCADA tags sat from it.
  • I wrote a Python tag parser that flattens nested SCADA/MQTT telemetry tag exports (JSON) into a CSV any engineer can open in Excel, cutting on-site processing from hours to minutes, with 23 unit tests and a plain-language guide for non-programmers.
  • I built a commissioning scope-of-work RFP for two new buildings of a GPU data center campus, and a validation matrix that checks equipment lists against the drawing schedules in both directions. It found 12 equipment types missing from the original lists.
  • I evaluated ML and reinforcement-learning approaches for the predictive control layer of a data center digital twin, and modeled the cost of physics-only vs hybrid training.
Power and cooling, utility to rack A generic data center topology, drawn for illustration with no site data. In an asset map, every box is a row whose parent is the box that feeds it. POWER PATH SOURCE Utility or on-site generation MV Switchgear medium voltage XFMR Transformer steps down to LV SWBD Switchboard low voltage UPS UPS with batteries PDU PDU or busway to the rows RPDU Rack PDU in each rack IT Servers the IT load parent ← child: each asset points back to the one feeding it, so the whole tree can be walked from any breaker COOLING PATH CHW Chillers or dry coolers PUMP Pumps and CDUs move the coolant CRAH Air handlers or in-row coolers RACK Server inlet air or cold plates LSS + SEC Life safety and security fire suppression, EPO, cameras, access control MONITORINGBMS (mechanical) and EPMS (electrical) sensors read every box above, into SCADA ASSET MAP I BUILT 716 assets electrical, mechanical, security, life safety Each row: asset ID, parent,description, specs, drawingreference, and two tag IDs:the standard tag, and whatthe live SCADA calls it.The gap between those twocolumns is the deliverable. HOW THE CHAIN BECOMES ROWS AssetParent TransformerSwitchgear SwitchboardTransformer UPSSwitchboard Without the row, nothing can attach to it:no maintenance schedule, no failure history,no answer to "what goes down if this is out?" DrawingGeneric, no site data ScopePower, cooling, life safety PurposeWhat an asset map covers Drawn byB. Uddin, Rev A
What an asset map covers: a generic power and cooling path, where every box becomes a row with a parent.
From a current reading to an alarm How one measurement becomes a SCADA alarm that carries the asset's standard name. Illustrative; names and values are made up. SWBD-A1 A B C MAIN1600 AF phase A current, 60 Hz 412A COMMpower meter 1 SenseA current transformer on phase Afeeds the meter, which digitizes it. Modbus PSU CPU RUNALM I > 400 2 DecidePLC scans the reading and checks it against the limit Ethernet,MQTT SCADA · UNIT-01 · SWBD-A1LIVE Crusoe/SITE/UNIT-01/SWBD/A1/Current_PhA 300 350 400 450 HIGH 400 A −15 minnow ALARM · Current high on phase A · 412 ACrusoe/SITE/UNIT-01/SWBD/A1 → opens work order 3 AlarmThe alarm carries the asset's standard path, so an operator anywherecan open the matching maintenance record without asking what it's called.
From a current reading to an alarm: a current transformer feeds a meter, the PLC checks the limit, and the SCADA alarm carries the asset's standard name, so it opens the right maintenance record. Names and values are made up.
Digital twin: airflow and heat in a data hall An illustrative cross-section of the physics a twin models. Colors show simulated air temperature; not real site data. CRAH CRAH COLD AISLECOLD AISLE HOT AISLE CEILING RETURN PLENUM RAISED-FLOOR SUPPLY PLENUM RACKRACKRACKRACK Simulated air temperature 18 °C30 °C45 °C airflow What the twin does with thisPredicts rack inlet temperatures as load changes, and suggests CRAH supplysetpoints. I evaluated ML and RL approaches for that predictive layer.
What a digital twin models: cold air from the CRAH units runs under the raised floor, rises through the cold aisles, heats up through the servers and returns through the ceiling. Illustrative, not site data.

The drawings are generic illustrations: no site photos, layouts or internal data.

EXP

Experience

An internship, two engineering teams, and earlier work

In shortWhere I've worked: a data center internship, two student engineering teams, and earlier jobs in ECG signal analysis and car electronics.

E1
May to August 2026
San Francisco, CA

Data Center Facility Operations Intern

Crusoe
  • Built a Python tag parser that flattens nested SCADA/MQTT telemetry tag exports (JSON) into clean CSV datasets, cutting on-site processing from hours to minutes; 23 unit tests.
  • Proposed a five-level naming standard for modular sites so maintenance records, SCADA tags and cloud dashboards share one name per asset, and measured the live SCADA tags against it.
  • Built the asset map for 716 electrical, mechanical, security and life-safety assets, each linked to the asset that feeds it, from substation to rack PDU.
  • Wrote a commissioning scope-of-work RFP for two new GPU data center buildings and a validation matrix that found 12 equipment types missing from the original equipment lists.
  • Evaluated ML and reinforcement-learning approaches for the predictive control layer of a closed-loop data center digital twin, and modeled cost tradeoffs between physics-only and hybrid physics+ML training.
PythonMQTTSCADABMS/EPMSAsset mappingCommissioningDigital twin
See sheet DC1: drawings and details
Thumbnail of the data hall airflow drawing: CRAH units, cold and hot aisles and server racks shaded by air temperature.
Fig. E1 · data hall airflow, from sheet DC1 (illustrative)
E2
September 2024 to now
Piscataway, NJ

Low Voltage Systems Engineer

Rutgers Solar Car
  • Engineered a daisy-chain FDCAN topology linking 8 distributed system boards, enabling reliable real-time data exchange between high/low-voltage managers and peripheral modules.
  • Designed the “LV3 Core” mixed-signal carrier PCB (STM32G4 MCU) for low-voltage battery telemetry and protection.
  • Implemented reverse-polarity protection, voltage-sensing telemetry and buck-converter regulation, then validated signal integrity and I/O pin mapping during hardware bring-up.
FDCANSTM32G4KiCadMixed-signal PCBPower regulationBring-up
See PCB2 and NET1 in the boards list
FDCAN · differential pairCAN_HCAN_L120 Ω120 ΩN1N2N3LV3N5N6N7N88 boards, one bus · LV3 Core: STM32G4
Fig. E2 · CAN_H and CAN_L on an 8-node FDCAN bus (illustrative)
E3
September 2024 to now
Piscataway, NJ

Software/Controls Engineer

Space Technology Association of Rutgers (STAR)
  • Designed a custom PCB interfacing an NVIDIA Jetson Nano onboard computer with peripheral sensors and motor controllers, engineering signal-routing and power-distribution circuitry for reliable multi-sensor operation.
  • Developed C/Python control logic and motor-driver controls for a NASA Lunabotics lunar mining robot on Linux.
  • Implemented SLAM-based 3D perception and autonomous navigation using a Unitree 4D Lidar L2 and ROS 2.
Jetson NanoCPythonROS 2SLAMLidar
See PCB3 in the boards list
lunar arena · SLAM mapstartboulder
Fig. E3 · lidar SLAM map of a lunar test arena (illustrative)

Other work experience

Earlier jobs outside digital design.

E4
July 2025 to February 2026
Full-time
New Providence, NJ

ECG Data Analyst and Technician

Baxter (Bardy Diagnostics)

How it connects: this was signal-processing work. Every scan is a sampled waveform where real events have to be separated from noise and motion artifacts, and the ML models had to be checked against known answers, the same discipline as verifying hardware against a reference model.

  • Analyzed 200+ ECG scans a month, applying digital signal processing concepts to identify cardiac arrhythmias and signal artifacts.
  • Validated BDx software by generating test cases for CNN-RNN machine-learning models that automate the classification of abnormal heart rhythms (PACs and PVCs).
  • Kept diagnostic reports clinically accurate by telling true cardiac events from motion artifacts through waveform pattern recognition.
DSPECG waveformsML model validationTest casesCRAT certified
PVCmotion artifactNNVNnot a beatECG · lead II · 25 mm/s
Fig. E4 · ECG strip: normal beats, a PVC and a motion artifact (illustrative)
E5
June 2022 to March 2024
Paterson, NJ

Automotive Hardware Apprentice

Smart Auto Care
  • Installed aftermarket electronics in 10+ vehicles, integrating head units and wiring modules for Apple CarPlay and Android Auto.
  • Fabricated custom mounting brackets and wiring harnesses with 3D printing and AutoCAD for secure component fit.
  • Serviced HVAC and electrical systems: crimping, soldering and schematic tracing for sensor repairs.
Wiring harnessesSolderingSchematic tracing3D printingAutoCAD
head-unit harness adapterHEAD UNITVEHICLEBATT +12VACCGNDREMILLUMFL −FL +FR +crimped butt splices
Fig. E5 · head-unit harness with crimped splices (illustrative)
TP1

Toolbox

In shortThe languages, design tools and lab skills I use.

RTL and FPGA

Verilog and SystemVerilog, synthesis, timing closure, clock-domain crossing, functional verification. Vivado, ILA, cocotb, Verilator, Yosys.

Interfaces

Ethernet MAC (RGMII/GMII, FCS/CRC-32), UDP/IPv4, MoldUDP64, AXI4-Lite, FDCAN.

Programming

C, Python, Tcl, RISC-V assembly, MATLAB, Java, SQL, Linux, Git, ROS 2.

Boards and lab

KiCad, LTSpice, mixed-signal design, SolidWorks and Onshape, oscilloscopes, soldering, 3D printing.

J1

Get in touch

Open to Summer and Fall 2027 internships in FPGA, RTL, ASIC and verification.

ubrahin17@gmail.com
Headshot of Brahin Uddin
  • Rutgers University–New Brunswick · B.S. Electrical Engineering, minor in Computer Science · Class of 2028
  • Honors College · Engineering Honors Academy · Dean's List
  • New Brunswick, NJ
Resume (PDF) LinkedIn GitHub