Understanding ZYNQ project with standalone thresholds

[FrankHogervorst]

Hello, I've not got a bug specifically but I am trying to understand the ZYNQ project build with standalone thresholds.

I've previously implemented networks with the thresholds packed into the stitched IP which worked great and the AXI-stream interface is straightforward, but we are keen to update the weights without needing to change the bitstream.

I've run the whole FINN flow until to the end so I get the ZYNQ build and the PYNQ drivers to work out how this would work. The stitched IP has an interface for the data (just like I had with standalone_thresholds=False) but then the streamingFCLayers all have a seperate AXI interface (see image below). However, in the next step where it builds the ZYNQ project, that IP is packages up into one block with only the data interface and then two DMA's attached but the Streaming partition doesn't have any AXI interface for the weights anymore. Is that all located in the DMA's? Is there any information on how to feed those weights to the StreamingFClayers without the PYNQ wrappers?

We have the BNN-PYNQ CNV_w1a1 implemented into one of our previous designs, but want to update that block with a custom architecture (single input channel) so that's why I am keen to understand how to swap one for the other.

On that note, the flow didn't produce runtime_weights (also tested using the TFC network from the qnn-data folder), only the folder itself. Is there a specific command that needs to be run to get the run-time weights?

Steps to Reproduce

1. Clone the FINN repository
2. Checkout the dev branch, with commit hash: df872f7c
3. Add standalone_threshold=True parameter to src/finn/qnn-data/build_dataflow/build.py
4. Start the docker container with the command: ./run-docker.sh build_custom src/finn/qnn-data/build_dataflow

Actual behavior

Describe what actually happens instead.
Stitched IP:

ZYNQ project:

[maltanar]

Hi @FrankHogervorst , a bit of clarification around terminology first: in the FINN compiler standalone_thresholds actually refers to the threshold-based activations being implemented as a separate layer of its own instead of being part of the Matrix_Vector_Activate layer. In the stitched IP design you shared above, Thresholding_Batch_1 should be visible after the StreamingFCLayer_Batch_0. If you'd like runtime-configurable FC layer weights and thresholds, this is actually necessary as well.

I think what you are looking for is the runtime_writable_weights attribute for both StreamingFCLayer_Batch as well as Thresholding_Batch. Note that this also requires mem_mode="decoupled" for both. You can set this attribute by specifying it as part of the folding configuration json file like this example here:

https://github.com/Xilinx/finn-examples/blob/main/build/mobilenet-v1/folding_config/ZCU104_folding_config.json#L722
https://github.com/Xilinx/finn-examples/blob/main/build/mobilenet-v1/folding_config/ZCU104_folding_config.json#L789

...or alternatively you could create a custom build step that takes place after setting the folding factors, where you directly set the attribute programmatically with something like this.

Once this is done, you should be able to see the AXI lite interfaces exposed at the top level for the stitched IP / ZYNQ project, and the appropriate data files should be created under runtime_weights/ as part of the generated driver.

[FrankHogervorst]

Thanks Maltanar, that clears it up completely for me. I recall now seeing runtime_writeable_weights set to 0 in my final_hw_condig.json files.