This week I revisited the convolutional layer in my YOLOv3-tiny hardware implementation and realized that the original conv_2d module was not properly parametrizable for the full network. It was too tightly coupled to a specific layer configuration, particularly around fixed kernel size, channel count, and accumulation structure. That meant it would not scale cleanly across the different convolutional layers in YOLOv3-tiny.
I restructured the conv_2d module to be fully parameter driven. I introduced parameters for kernel size, number of input channels, number of output channels, and maximum supported input channels. The data path is now dimensioned based on these parameters rather than hard-coded constants. Internally, I redesigned the MAC array so that instead of supporting only 27 multipliers tied to a specific 3x3x3 style structure, it now instantiates 64 parallel multipliers. This gives more parallelism and aligns better with a scalable channel processing strategy.
I also added a dedicated accumulator inside the MAC unit. Previously, partial sums were not handled in a way that would scale across large input channel counts. Now, each output feature map element accumulates products across all input channels in a structured way. The accumulator supports up to 1024 input channels. For layers that have fewer than 1024 input channels, I zero-pad the unused inputs so that the accumulation loop and hardware structure remain consistent. This allows the same hardware structure to be reused across layers with different channel depths without redesigning the control logic.
Additionally, I updated the control logic so the same conv_2d module can handle both 1×1 and 3×3 convolutions. The kernel size parameter determines how the sliding window and multiply scheduling behave. The internal indexing and loop bounds now depend on the parameterized kernel size and channel counts, so the same module can be reused across all convolutional layers in YOLOv3-tiny.
Right now I am validating all 1×1 and 3×3 MAC operations in simulation without quantization or post processing. The goal is to ensure that the core multiply accumulate behavior matches a reference implementation before introducing fixed point quantization and activation functions.
On the project direction side, based on feedback, we decided to pivot away from traffic sign detection and instead focus on making the robot more careful around people. This allows us to use the standard COCO dataset with YOLOv3-tiny instead of building and training a custom dataset. That reduces training overhead and lets us focus on hardware deployment. I will still need to properly quantize the pretrained model for the FPGA board, but this avoids retraining from scratch.
Goals for next week:
-
Have most of the model working functionally in simulation
-
Implement a Python reference version so I can verify outputs and prepare for weight loading
-
Purchase the remaining hardware components
-
Prepare slides and demos for the presentation