Roshni’s Status Report for 10/17/2026

This week I finished the retarget of the beamforming pipeline to the full 20 to 80 kHz band and got every module passing in both the 384 kS/s full-band and 192 kS/s narrow-band configurations. The decimator is now decimation 8 with a 127-tap filter and 128-sample delay buffers. I fixed the 192 kS/s filter coefficients, which turned out to be a 28 to 45 kHz filter, not 36 to 44 kHz, and added a clock enable to the filter so it works with samples that arrive hundreds of clocks apart. The scan controller now steers ±52° in 61 steps and exposes a latched 61 × 32-bit energy snapshot, a sweep counter, a saturation flag and a configurable output shift, which is the interface Essie’s software expects. All four testbenches pass bit-exact or within 1 LSB against the golden model.

I also finished a full pass on the Design Report and re-checked its math against the RTL. I trimmed the longest section toward its page limit.

I am mostly on track. The open item is the integration glue around the verified modules: top level, bus wrapper and bitstream.

For next week:

  1. Build the top level and register wrapper (including an ID register), and deliver the .bit, .hwh and a written register map to Essie
  2. Decide the clock structure for the 3.072 MHz mic clock and the 100 MHz logic
  3. Add the stored-block energy window to the scan controller
  4. Build the time-shared filter and verify it against the parallel version

Roshni’s Status Report for 10/03/2026

This week I replaced the placeholder straight-line mic array with the real geometry pulled directly from the fabricated PCB, which required generalizing the beamforming math to handle it. This also resolved an earlier spacing concern, testing the real layout showed no aliasing issue at our target frequency, confirmed independently by a teammate’s analysis, so no hardware changes are needed there.

I implemented and verified two more hardware modules (the fine delay interpolator and the full direction-scanning controller), each checked against the same reference model as before, with real bugs found and fixed in both. The full 30-channel system passed an end-to-end test, correctly identifying a known sound direction.

I also started the next pipeline stage (raw mic data to usable samples), fixed some bugs there, and am still tracking down one more discrepancy.

I am mostly on track, with one open item carried into next week.

For next week:

  1. Root-cause the remaining decimation discrepancy
  2. Add the missing full-sweep data output to the scan controller
  3. Lock in the hardware clock frequency
  4. Regenerate lookup tables at full deployment scale

Roshni’s Status Report for 09/26/2026

This week I took the bandpass filter piece from last week’s Python reference model and implemented it in SystemVerilog, then built a way to prove the hardware version actually matches the software version.

I wrote the filter as a pipelined chain of small multiply-add stages rather than one big calculation, since that structure runs much faster on real hardware. I also set up an automatic export from the Python model that generates matching test files — the same filter settings, a test signal, and the expected correct output — so both versions could be fed identical inputs and compared directly. First run surfaced two real bugs: a scaling error from how the lower-precision hardware numbers get converted back to normal values, and a timing offset where the hardware’s early outputs (before its internal pipeline fully “warms up”) were being compared against the wrong reference samples. After fixing both, the hardware version matched the software version exactly, sample for sample.

For later reference, here’s what I used/researched this week:

  • Icarus Verilog for simulating and running the hardware version
  • SystemVerilog, using a pipelined “transposed” filter structure suited for FPGAs
  • Fixed-point number formatting (converting between normal numbers and the limited-precision format hardware uses)

I am scheduled on track relative to our project roadmap.

For next week, I plan to:

  1. Implement the fractional delay stage in SystemVerilog, verified the same way against the Python reference
  2. Replace the placeholder ultrasonic passband with a real measured leak recording once available
  3. Update mic spacing/count to match Wes’s finalized PCB geometry
  4. Coordinate with Wes to confirm the final array geometry matches the delay-table assumptions

Roshni’s Status Report for 09/20/2026

This week I built out the software validation layer for our beamforming pipeline before committing anything to RTL. The goal was to get a working, testable reference model of the full delay-sum beamforming chain in Python first, so the algorithm itself is verified before I start writing SystemVerilog.

I built the full beamforming pipeline in software, piece by piece. First, a tool that calculates, for every possible direction and every microphone, exactly how much to delay that mic’s signal — split into a whole-number part (easy to apply) and a small leftover fraction (which needs a bit more work to apply accurately). Second, a filter that keeps only the specific pitch range our leak’s ultrasonic sound lives in. Third, a way to apply that small leftover fractional delay accurately, using a standard interpolation technique, this matches how real published FPGA-based beamformers are built, which I confirmed by checking the research literature before building it myself. Fourth, the part that actually tests each candidate direction: it applies the delays, adds all the microphones together, and does this for every direction in turn, keeping track of which direction produced the loudest combined result. Finally, I ran a test where I deliberately rounded all the numbers down to a lower-precision format similar to what the actual chip will use, just to get an early sense of whether that lower precision would hurt accuracy, before committing to that precision level in real hardware.

To check that all of this actually works, I built a test setup: a simulated ultrasonic sound placed at a few different known angles, “heard” by each simulated microphone with a very precise, trustworthy timing calculation, then run through the whole pipeline above to see if it could figure out the correct angle on its own. The detected angles came out accurate to within the smallest measurable step of our current setup (2 degrees), across every angle tested. Also, the lower-precision version (the one using the rounded-down numbers meant to mimic real hardware) gave results just as accurate as the full-precision version, meaning that, at least so far, using lower-precision numbers on the actual chip likely won’t hurt accuracy.

For later reference, here’s what I used/researched this week:

  • NumPy / SciPy for the signal-processing simulation environment
  • scipy.signal.firwin for FIR bandpass filter design
  • Lagrange interpolation for the fractional (fine) delay stage
  • The coarse-delay + fine-delay (Lagrange/Farrow-style) beamforming architecture used in FPGA-based ultrasound and array-signal-processing literature
  • Fixed-point quantization emulation for an early resource/precision tradeoff check

I am scheduled on track relative to our project roadmap.

For next week, I plan to:

  1. Replace the placeholder ultrasonic passband with the actual measured frequency signature of a real leak recording, once we have one
  2. Update the mic spacing and count in the model to match Wes’s finalized PCB geometry
  3. Begin RTL implementation of the FIR filter module, verified stage by stage against the Python reference model
  4. Coordinate with Wes to confirm the final array geometry matches the assumptions baked into the delay-table math