Portfolio / 2026 v2.0 · Last updated 2026-04-23

Deepansh Sabharwal

Computer Engineering at UBC. Working where hardware and software meet: RTL-level FPGA design, bare-metal RISC-V, and edge AI on embedded hardware.

Status
Available, Fall 2026 co-op. Embedded, FPGA, firmware, edge AI.
Program
B.A.Sc. Computer Engineering, UBC. Second year.
Location
Kelowna, BC  · UTC-7. Open to relocation and remote.
Focus
HDL and FPGA, RISC-V pipelines, embedded vision, sensor systems.

01 / Selected Work

Projects

Four projects across hardware, firmware, and applied ML. Each stated as problem, approach, result, and stack. Measurable outcomes are cited where they exist.

Case 01 · FPGA, Verilog 2025 · Lead

FaultLatchedPWM

A deterministic, hardware-enforced PWM controller that cannot be overridden in software.

Context

Motor-control and embedded-actuation loops routinely implement safety logic in firmware, creating a software path that can be bypassed, corrupted, or starved. The project removes the firmware layer from the safety envelope by enforcing period and duty constraints in RTL on a Gowin GW2A-LV18 (Tang Nano 20K).

Approach

A 32-bit configurable PWM generator is gated by a hardware guard module that validates constraints pre-output. Violations drive a five-state FSM (INITIDLERUNFAULTSAFE) into a latched fault state. Recovery requires an explicit externally-asserted sequence. There is no firmware override path; the FSM is the single source of truth.

Result
MetricConstraintAchieved
Fmax100 MHz127 MHz
LUT utilizationn/a~2%
Register utilizationn/a<1%
Target deviceGW2A-LV18Verified

Verified via Icarus Verilog simulation with waveform-based fault injection. Synthesized and place-and-routed in Gowin EDA.

Stack
VerilogFSM designGowin EDAIcarus VerilogTang Nano 20K

Case 02 · Embedded, Systems 2025 · Sole author

RISC-V Toolchain to Hardware-Emulation Pipeline

End-to-end bare-metal pipeline from C source to a 64-bit RISC-V virtual machine, with no operating system in the path.

Context

Understanding an ISA in isolation does not produce working systems. The work targets the full chain: source to ELF to boot to emulation, with privilege transitions managed explicitly. The objective is ground-up fluency in how instructions become silicon behaviour, as preparation for deploying the same flow to a physical FPGA.

Approach

C source is cross-compiled to RISC-V ELF via the GNU toolchain. OpenSBI handles M-mode boot; riscv-pk manages privilege transitions. The resulting binary runs on a 64-bit virtual RISC-V target in QEMU. Each stage of the pipeline, from ELF section layout to boot sequence to emulation memory model, is analysed rather than treated as opaque.

Result

Operational bare-metal pipeline. Next phase: physical deployment on Tang Nano 20K, replacing the QEMU target with an in-fabric soft core. placeholder: benchmark latency and instruction throughput on target

Stack
RISC-V ISAGCCQEMUOpenSBIBare-metal CELF

Case 03 · Research, Edge AI 2026 · Author, UBC proposal

Wildlife-Vehicle Collision Warning System

A solar-powered edge-AI node that detects and classifies large animals approaching a roadway, then triggers dynamic warning signs with no cloud dependency.

Context

Deployed North American Roadway Animal Detection Systems (RADS) trigger on motion signatures and do not classify species. This produces false positives from wind, vegetation, and small animals. The proposal addresses a documented gap: on-device computer vision to discriminate target species (deer, moose, elk) from background events. Target corridor: Hwy 97 Okanagan.

Approach

A FLIR thermal camera feeds a YOLOv8-nano model accelerated via TensorRT on a Jetson Orin NX. Inference runs entirely at the edge; only detection events transit the LoRaWAN uplink. Power is solar with battery buffer, sized for 72-hour no-sun operation. Warning sign actuation is on a local GPIO path with sub-second latency from detection to signal.

Result

Proposal submitted to BC Ministry of Transportation, April 2026. Specification, power budget, and thermal analysis complete. Hardware bring-up pending funding. placeholder: target detection precision and recall once benchmarked

Stack
Jetson Orin NXFLIR thermalYOLOv8-nanoTensorRTLoRaWANSolar power

Case 04 · Hardware, EV 2024 · Electrical lead

CyberTrike

An RC-controlled three-wheeled electric vehicle prototype, from schematic to rolling chassis, as a UBC team project.

Context

First-year team project. Objective: a working drivable prototype inside one term, with a small team and a protoboard-only electrical stack. The role owned the electrical path end-to-end: motor control, power distribution, and the wireless control link.

Approach

Arduino-driven PWM motor control, hand-drawn circuit schematics translated to protoboard, and an NRF24L01 radio link for the remote. Power routing was kept on a single rail to simplify debugging; thermal and current margins sized conservatively given the prototyping medium.

Result

Rolling, remotely controlled prototype. Radio link reliable at project-scale distances. Post-mortem: migration from protoboard to a proper PCB is the first improvement for a v2.

Stack
ArduinoPWMCircuit designNRF24L01SolidWorks

02 / Systems

On hardware-enforced safety in FaultLatchedPWM

Why the safety envelope in this controller is in RTL rather than firmware, what the tradeoffs are, and how the FSM is structured to make recovery explicit rather than incidental.

A PWM controller for motor actuation has two jobs. It must produce a clean, configurable switching waveform, and it must not produce an unsafe one. The second job, in most implementations, is delegated to firmware. A microcontroller compares the commanded duty against a limit, and refuses to load the compare register if the limit is exceeded. This is convenient and almost always adequate. It is also a path that can be bypassed, corrupted by a stack overflow, starved by a priority inversion, or silently reverted by a firmware update. The failure mode is invisible until it is not.

FaultLatchedPWM takes a different position. The safety envelope belongs in the fabric. The PWM generator is subordinate to a hardware guard module that observes the commanded period and duty values and a fault signal, and holds a single latched bit: is the system permitted to drive output. The guard is combinational and registered; the latch is explicit; the reset path is explicit. The firmware cannot override it because there is no firmware path to the latch. The only way out of a fault state is an externally asserted recovery sequence, which can itself be gated by whatever higher-level supervision the integrator chooses.

The state machine has five states. INIT establishes known values on power-up and releases to IDLE when the configuration registers are stable. IDLE drives the output low and waits for an enable. RUN generates the waveform under the guard module's continuous supervision. FAULT is the latched state: output is driven low, the fault signal is asserted on an external pin, and no further transitions are accepted except a specific recovery pattern. SAFE is reached after recovery, and returns to IDLE only when the configuration has been re-validated. The critical property is that the RUN to FAULT transition is single-cycle and irreversible without external intervention, and that FAULT never yields to RUN directly. This eliminates an entire class of chattering failures where a marginally-valid configuration oscillates across the guard boundary.

FSM: INIT to IDLE to RUN, with fault and recovery branches to FAULT and SAFE config ok enable fault detect reset seq. re-validate INIT power-up IDLE output low RUN pwm active FAULT latched SAFE verified
Click or focus a node. Connected edges highlight; siblings dim.
verilog
// FaultLatchedPWM: guard-gated PWM generator, excerpt
// The output is driven low unless guard_ok is asserted AND
// the FSM is in the RUN state. There is no firmware path.

module fault_latched_pwm #(
    parameter integer WIDTH = 32
)(
    input  wire                 clk,
    input  wire                 rst_n,
    input  wire [WIDTH-1:0]  period_i,
    input  wire [WIDTH-1:0]  duty_i,
    input  wire                 enable_i,
    input  wire                 recover_i,
    output reg                  pwm_o,
    output wire                 fault_o
);

    localparam [2:0]
        S_INIT  = 3'd0,
        S_IDLE  = 3'd1,
        S_RUN   = 3'd2,
        S_FAULT = 3'd3,
        S_SAFE  = 3'd4;

    reg [2:0] state, state_n;
    wire guard_ok = (duty_i <= period_i) && (period_i != 0);
    assign fault_o = (state == S_FAULT);

    always @(*) begin
        state_n = state;
        case (state)
            S_INIT  : if (guard_ok)            state_n = S_IDLE;
            S_IDLE  : if (enable_i && guard_ok) state_n = S_RUN;
            S_RUN   : if (!guard_ok)           state_n = S_FAULT;  // single-cycle, irreversible
            S_FAULT : if (recover_i)           state_n = S_SAFE;
            S_SAFE  : if (guard_ok)            state_n = S_IDLE;
            default :                            state_n = S_INIT;
        endcase
    end

endmodule

03 / Archive

Other work

Shorter projects and self-authored learning repositories. Listed for reference, not as headline work.

Year Kind Title Link
2025 ML, Python AI Soil Suitability Predictor, logistic regression with cross-validation over temperature, humidity, rainfall, wind speed, and soil moisture github →
2025 Python, API SkyCast Live, real-time weather dashboard over a REST integration write-up →
2025 Learning repo C Programming, beginner to intermediate, self-authored github →
2025 Learning repo Java, beginner to intermediate, self-authored github →
2025 Learning repo Bash Scripting, beginner to intermediate, self-authored github →
2025 Certification Mastering OpenCV with Python, OpenCV University, December 2025 certified

04 / Background

About

Second-year Computer Engineering at UBC. My work spans the hardware-software boundary: writing Verilog state machines for physical FPGAs, building bare-metal RISC-V compilation pipelines, training ML models on real datasets, and wiring circuits on physical prototypes.

I pursue co-op roles where hardware is a real constraint, not an abstraction. Timing closure, silicon area, power budget, and thermal limits are the environment I want to work in. The attraction is not difficulty for its own sake. It is that the feedback loop from design decision to observable behaviour is shorter and less mediated than in pure software, and the reasoning discipline it demands is a better use of my attention.

Active research: a solar-powered thermal-camera wildlife-detection node proposed to the BC Ministry of Transportation for the Hwy 97 Okanagan corridor. In parallel, progressing the RISC-V pipeline toward physical deployment on the Tang Nano 20K.

Education
B.A.Sc. Computer Engineering, UBC. Second year, in progress.
Languages
English, Hindi, Punjabi.
Currently
Tang Nano 20K bring-up. Thermal-camera dataset labelling.
Reading
placeholder: current technical reading, one or two titles

05 / Contact

Direct

Open to co-op positions in embedded, FPGA, firmware, and edge AI, starting September 2026.

Email deepanshsabh.60@gmail.com
Resume Deepansh Sabharwal.docx download
Response Usually within 48 hours, weekdays, UTC-7.