Project

# Title Team Members TA Documents Sponsor
76 FPGA-based stock market data feed handler
Neel Ghosal
Saksham Jairath
Sara Sehgal
Gerasimos Gerogiannis proposal1.pdf
Problem
Electronic trading systems must process extremely high-rate streams of market data with very low and predictable latency. Software-based feed handlers running on general-purpose CPUs often suffer from nondeterministic delays due to instruction overhead, caching, and operating system scheduling, which can lead to delayed reactions or dropped messages under heavy load. Hardware-based solutions are therefore commonly used in industry to achieve deterministic performance. This project addresses the need for a low-latency, reliable market data processing system.

Solution
We propose an FPGA-based hardware market data feed handler that processes packetized trading updates in real time. The system ingests a continuous byte stream, parses market data messages, maintains per-symbol trading state (top-of-book), and generates low-latency trigger events when predefined conditions are met. By implementing the data path entirely in hardware, the design provides deterministic latency and high throughput, demonstrating the advantages of hardware acceleration for latency-critical trading workloads.

Solution Components
Subsystem 1: Input Interface and Buffering
Receives incoming data via the FPGA’s UART interface and buffers it using a FIFO implemented in block RAM to prevent data loss during bursts.
Components: FPGA UART, BRAM FIFO.

Subsystem 2: Packet Parser
A finite state machine parses incoming bytes into structured market data messages based on a predefined packet format.
Components: SystemVerilog FSM.

Subsystem 3: Trading State Manager
Maintains best bid and best ask prices per symbol and updates state based on incoming messages.
Components: BRAM, comparison logic.

Subsystem 4: Trigger Engine and Output
Evaluates trading conditions and outputs trigger events and system metrics via UART.
Components: Arithmetic/comparison logic, UART transmitter.

Criterion For Success
Correctly parses all valid packets and updates top-of-book state to match a software reference model.
Sustains a target message throughput without data loss.
Produces deterministic, bounded latency from packet reception to trigger generation.
Detects and reports sequence gaps or malformed packets.
Meets FPGA resource and timing constraints.

Covert Communication Device

Ahmad Abuisneineh, Srivardhan Sajja, Braeden Smith

Covert Communication Device

Featured Project

**Partners (seeking one additional partner)**: Braeden Smith (braeden2), Srivardhan Sajja (sajja3)

**Problem**: We imagine this product would have a primary use in military/law enforcement application -- especially in dangerous, high risk missions. During a house raid or other sensitive mission, maintaining a quiet profile and also having good situational awareness is essential. That mean's that normal two way radios can't work. And alternatives, like in-ear radios act as outside->in communication only and also reduce the ability to hear your surroundings.

**Solution**: We would provide a series of small pocketable devices with long battery that would use LoRa radios to provide a range of 1-5 miles. They would be rechargeable and have a single recessed soft-touch button that would allow someone to find it inside of pockets and tap it easily. The taps would be sent in real-time to all other devices, where they would be translated into silent but noticeable vibrations. (Every device can obviously TX/RX).

Essentially a team could use a set of predetermined signals or even morse code, to quickly and without loss of situational awareness communicate movements/instructions to others who are not within line-of-sight.

The following we would not consider part of the basic requirements for success, but additional goals if we are ahead of schedule:

We could also imagine a base-station which would allow someone using a computer to type simple text that would be sent out as morse code or other predetermined patterns. Additionally this base station would be able to record and monitor the traffic over the LoRa channels (including sender).

**Solutions Components**:

- **Charging and power systems**: the device would have a single USB-C/Microusb port that would connect to charging circuitry for the small Lithium-ion battery (150-500mAh). This USB port would also connect to the MCU. The subsystem would also be responsible to dropping the lion (3.7-4.2V to a stable 3.3V logic level). and providing power to the vibration motor.

- **RF Communications**: we would rely on externally produced RF transceivers that we would integrate into our PCB -- DLP-RFS1280, https://www.sparkfun.com/products/16871, https://www.adafruit.com/product/3073, .

-**Vibration**: We would have to research and source durable quiet, vibration motors that might even be adjustable in intensity

- **MCU**: We are likely to use the STM32 series of MCU's. We need it to communicate with the transceiver (probably SPI) and also control the vibration motor (by driving some transistor). The packets that we send would need to be encrypted (probably with AES). We would also need it to communicate to a host computer for programming via the same port.

- **Structural**: For this prototype, we'd imagine that a simple 3d printed case would be appropriate. We'd have to design something small and relatively ergonomic. We would have a single recessed location for the soft-touch button, that'd be easy to find by feel.

**Basic criterion for success:** We have at least two wireless devices that can reliably and quickly transfer button-presses to vibrations on the other device. It should operate at at *least* 1km LOS. It should be programmable + chargeable via USB. It should also be relatively compact in size and quiet to use.

**Additional Success Criterion:** we would have a separate, 3rd device that can stay permanently connected to a computer. It would provide some software that would be able to send and receive from the LoRa radio, especially ASCII -> morse code.