CARES senior project · weekly report · 2026-10-31 to 2026-11-06

CARES Weekly Report, Nov 6

Goal of the project: run the ReXNet-150 audio classifier on the FINALE accelerator chip design, on the DE10-Pro FPGA board. This week the old 2022 demo ran on the board for the first time, the chip simulation became about 470 times faster, and the first 26 ReXNet operations (the stem and blocks f0 to f3) were tested one by one. Ten bugs were found and fixed; six problems remain.

This week in numbers

32.5 fps

2022 MobileNetV2-SSD demo on the FPGA board, 500 images

~~78 min~~10 s

simulating the stem convolution, before and after

716 / 26

ReXNet operations within ±1 of the correct output: 7 before this week's fixes, 16 after (8 of them need this week's chip-design fixes)

10 fixed

bugs: 6 in our firmware and scripts, 4 in the chip design

What was done

Remote power-on for the lab PC. A small Ethernet board on the lab network now sends the "wake up" packet; the PC can be started from a cold power-off over the internet. Power-cycling the PC also resets the FPGA board.
First working FPGA run. After the card was reseated, the 2022 FPGA image loaded and the PC found the board on PCIe. The 2022 demo processed 500 images at 32.5 fps on the FPGA (25.5 fps including the PC side). Its output has never been compared with the original model, so this shows that the board runs, not that its results are correct.
Simulation 470× faster. 99.6 % of simulation time was the simulated memory chip in the test bench, which re-copied its whole 256 MB on every write. A one-line change fixed it; results are bit-identical.
Test flow for one operation at a time. New scripts build one test per operation from the real model data and run all 26 operations of stage 1 (stem to block f3) in under a minute.
First results and first fixes. 7 operations passed at once. Four debug investigations ran in parallel on the failing operations. Six firmware and script bugs were fixed. Three bugs in the multiply unit of the chip design were proven and fixed.
Sigmoid unit fixed. A bug in its "too large" check was proven and fixed; four sigmoid operations now pass.
Second debug round on standalone depthwise convolution and on wide 1×1 convolution. No root cause found; both parked by decision.
Found that 82 chip-design files are identical to the 2022 design that works on the board. Every confirmed bug so far is in parts the previous student added or changed.
First FPGA rebuild. The 2022 FPGA project was rebuilt with only the October memory-transfer fix (Quartus, 6 h 14 min, finished Nov 5). Timing misses by up to 0.26 ns on the memory-controller clocks, the same as an unpatched rebuild in March. Not loaded on the board yet. A small PC program that runs the stem convolution on the board and compares it with the simulation is ready.
Checked the sigmoid unit: it is not on the FPGA yet. The board runs the 2022 image, which has no sigmoid or multiply unit. The new sigmoid unit (a 1024-entry lookup table for 32 channels at once) needs an FPGA rebuild.

The 26 operations today

Where the tested operations sit in the whole network: each small square is one of ReXNet-150's 161 chip operations, left to right in data-flow order. Grey squares are not tested yet. The order inside each tested block, with the side paths, is drawn in the ReXNet-150 Datapath Map.

Why stage 1 stops at block f3

The stem and blocks f0 to f3 already contain every kind of operation in the network and its largest images (112×112, 56×56). Later blocks only repeat these kinds at smaller sizes, and their firmware wraps each block in one call that must be split before testing.

1 · Passed before this week's fixes 2 · Passes after firmware/script fixes 3 · Passes after the multiply fix 4 · Passes after the sigmoid fix 5 · Not solved Not tested yet

Class	What it needs	Operations	Share of 26
1 · passed before	Within ±1 with the inherited chip design plus the October memory-transfer patch. This week's faster test-bench memory changed no result, only the speed.	00 05 10 16 21 22 25 (7)	26.9 %
2 · firmware/script fix	Our firmware/script fix alone (bug 2, average scale and offset). No chip-design change.	20 (1)	3.8 %
3 · multiply fix	Class-2 fixes (bug 1 multiply settings, bug 5 block spacing) plus chip fixes 7–9. Errors 192 / 2,733 / 1,052 / 695 bytes, all ±1.	02 07 12 18 (4)	15.4 %
4 · sigmoid fix	Class-2 fixes (bug 3 send each block twice, bug 4 table switch) plus chip fix 10. Real channels ±1; padding channels show 128 instead of 0 by design (the input padding is sigmoid(0)) and are discarded.	06 11 17 23 (4)	15.4 %
5 · not solved	Bugs 11–13, 15 and 16 below. Depthwise (03 08 13 19) and wide 1×1 conv (04 09 14) are parked after two debug rounds.	01 03 04 08 09 13 14 15 19 24 (10)	38.5 %
not tested yet	Outside stage 1. Never simulated.	blocks f4 to f16, pool, classifier (135)	—

Classes 3 and 4 were each tested with only their own chip fix; the multiply and sigmoid fixes have not yet been tested together in one design.

All results are from simulation. No ReXNet operation has run on the FPGA board yet.

stem

conv

sigmoid

multiply

depthwise

1×1 conv

conv

sigmoid

multiply

depthwise

1×1 conv

conv

sigmoid

multiply

depthwise

1×1 conv

add

conv

sigmoid

multiply

depthwise

average

conv

sigmoid

multiply

1×1 conv

An operation is one step the chip runs on its own. One ReXNet layer can need several: the stem is a convolution (00) followed by a SiLU activation, which the model file stores as a sigmoid (01) and a multiply (02). An operation passes when every output byte is within ±1 of the correct answer, which is the original model run on a PC (±1 is normal rounding). Each operation is tested alone, starting from the correct input; errors adding up across operations are not tested yet.

Bugs found this week

#	Bug	Effect	Status
In our firmware and test scripts
1	Multiply settings written one slot off (02 07 12 18)	Output scale was 0; every output the same value	fixed
2	Average operation: wrong scale and offset formula	Outputs wrong by up to 255	fixed operation 20 passes
3	Sigmoid unit waits for two inputs (copied from the two-input units)	Simulation froze	worked around firmware sends each block twice
4	Sigmoid table exists only with a compile switch that is off	Undefined outputs	fixed in sim must also be on in the FPGA build
5	Data blocks placed 1 MB apart, some are 2 MB	Blocks overwrote each other	fixed overlap now checked automatically
6	First convolution of block f3 (16) read the wrong memory address	Read old data. Only in the whole-network program, not in these one-operation tests	fixed
In the chip design, each proven with a Python copy of the circuit that reproduces the simulator's output byte for byte
7	Multiply unit: each channel's result written over all 32 channels	4 multiply operations 45–86 % wrong; after the fix at most 0.14 % wrong, all ±1	fixed
8	Multiply unit: negative numbers shifted as if positive		fixed
9	Multiply unit: 20-bit register too small (needs 25)		fixed
10	Sigmoid unit: "too large" check reads one bit, not the whole number	Large inputs wrapped around; after the fix 4 sigmoid operations within ±1	fixed
Not solved
11	Depthwise convolution run alone outputs only its bias (03, 08, 13, 19)	Likely addresses its input buffer past 256 slots; the 2022 demo never ran it alone	parked
12	1×1 convolution writes nothing when output is 56 or 112 wide (04, 09, 14)	Undefined values in the multiply-add circuit above width 28	parked
13	Stem sigmoid needs an input scale above 1 (01)	The chip's scale format only holds values below 1	open
14	Sigmoid unit: proper chip fix so one input is enough (removes the bug 3 workaround)	One attempt moved the freeze, did not remove it	open
15	Add operation (15): errors up to 8, 21,504 bytes unwritten	The errors: our correct answer is taken after the next step (a concatenation), which uses a different scale. The missing bytes: not explained	open
16	Second multiply in f3 (24) freezes	Control processor stops at the third data load	open

Decisions needed

When to rebuild the FPGA image with all chip fixes (bugs 7–10 and the sigmoid table switch of bug 4). A rebuild takes about 6 h on the lab PC. The Nov 5 rebuild has only the October memory-transfer fix.
Ask the previous student how standalone depthwise convolution was meant to work (bug 11, parked)?

Plan for next week (proposed)

Load the Nov 5 rebuild on the board: rerun the 2022 demo, then run the stem convolution (00) and compare it byte by byte with the simulation.
Test the multiply and sigmoid fixes together in one design.
Investigate the add (15, bug 15) and the frozen multiply (24, bug 16).
Run two or more operations back to back, so the chip's own output feeds the next operation.
Extend the test table past block f3 (stage 2).
Check whether the 2022 SSD firmware stays under the memory-transfer size limit fixed in October (that bug is also in the 2022 image), and compare one board output with the original model.
If approved, start the FPGA rebuild with all chip fixes.