Merge pull request Xilinx#1023 from Xilinx/fix/minor_fixes

Minor fixes to documentation and examples for dev branch

Author: auphelia

docs/finn/developers.rst

@@ -2,8 +2,6 @@
 Developer documentation
 ***********************
 
-.. note:: **This page is under construction.**
-
 This page is intended to serve as a starting point for new FINN developers.
 Power users may also find this information useful.
 

docs/finn/getting_started.rst

@@ -125,7 +125,7 @@ General FINN Docker tips
 
 Supported FPGA Hardware
 =======================
-**Vivado IPI support for any Xilinx FPGA:** FINN generates a Vivado IP Integrator (IPI) design from the neural network with AXI stream (FIFO) in-o>
+**Vivado IPI support for any Xilinx FPGA:** FINN generates a Vivado IP Integrator (IPI) design from the neural network with AXI stream (FIFO) in-out interfaces, which can be integrated onto any Xilinx-AMD FPGA as part of a larger system. It’s up to you to take the FINN-generated accelerator (what we call “stitched IP” in the tutorials), wire it up to your FPGA design and send/receive neural network data to/from the accelerator.
 
 **Shell-integrated accelerator + driver:** For quick deployment, we target boards supported by  `PYNQ <http://www.pynq.io/>`_ . For these platforms, we can build a full bitfile including DMAs to move data into and out of the FINN-generated accelerator, as well as a Python driver to launch the accelerator. We support the Pynq-Z1, Pynq-Z2, Kria SOM, Ultra96, ZCU102 and ZCU104 boards, as well as Alveo cards.
 

docs/finn/hw_build.rst

@@ -87,8 +87,4 @@ transformation for Zynq, and the `VitisLink` transformation for Alveo.
 Deployment
 ==========
 
-
-Deployment
------------
-
 The bitfile and the driver file(s) can be copied to the PYNQ board and be executed there. For more information see the description in the `end2end_example <https://github.com/Xilinx/finn/tree/main/notebooks/end2end_example>`_ Jupyter notebooks.

docs/finn/img/mem_mode.png

@@ -181,7 +181,7 @@ Disadvantages:
 
 Internal_decoupled mode
 ------------------------
-In *internal_decoupled* mode a different variant of the MVAU with three ports is used. Besides the input and output streams, which are fed into the circuit via Verilog FIFOs, there is another input, which is used to stream the weights. For this the `streaming MVAU <https://github.com/Xilinx/finn-hlslib/blob/master/mvau.hpp#L214>`_ from the finn-hls library is used. To make the streaming possible a Verilog weight streamer component accesses the weight memory and sends the values via another FIFO to the MVAU. This component can be found in the `finn-rtllib <https://github.com/Xilinx/finn/tree/dev/finn-rtllib>`_ under the name *memstream.v*. For the IP block generation this component, the IP block resulting from the synthesis of the HLS code of the streaming MVAU and a FIFO for the weight stream are combined in a verilog wrapper. The weight values are saved in .dat files and stored in the weight memory from which the weight streamer reads. The resulting verilog component, which is named after the name of the node and has the suffix "_memstream.v", exposes only two ports to the outside, the data input and output. It therefore behaves externally in the same way as the MVAU in *internal_embedded* mode.
+In *internal_decoupled* mode a different variant of the MVAU with three ports is used. Besides the input and output streams, which are fed into the circuit via Verilog FIFOs, there is another input, which is used to stream the weights. For this the `streaming MVAU <https://github.com/Xilinx/finn-hlslib/blob/master/mvau.hpp#L214>`_ from the finn-hls library is used. To make the streaming possible a Verilog weight streamer component accesses the weight memory and sends the values via another FIFO to the MVAU. This component can be found in the `finn-rtllib <https://github.com/Xilinx/finn/tree/dev/finn-rtllib>`_ under the name *memstream.v*. For the IP block generation this component, the IP block resulting from the synthesis of the HLS code of the streaming MVAU and a FIFO for the weight stream are combined. The weight values are saved in .dat files and stored in the weight memory from which the weight streamer reads. The resulting verilog component, which is named after the name of the node and has the suffix "_memstream.v", exposes only two ports to the outside, the data input and output. It therefore behaves externally in the same way as the MVAU in *internal_embedded* mode.
 
 Advantages:
 

docs/finn/internals.rst

@@ -1,6 +1,6 @@
 brevitas@git+https://github.com/Xilinx/brevitas@master#egg=brevitas_examples
 dataclasses-json==0.5.7
-docutils==0.17.1
+docutils==0.19
 gspread==3.6.0
 importlib_resources
 IPython
@@ -9,7 +9,7 @@ netron
 pytest
 pyverilator@git+https://github.com/maltanar/pyverilator@master#egg=pyverilator
 qonnx@git+https://github.com/fastmachinelearning/qonnx@main#egg=qonnx
-sphinx_rtd_theme==0.5.0
+sphinx_rtd_theme==2.0.0
 torch
 torchvision
 tqdm

docs/requirements.txt

@@ -46,7 +46,7 @@
    "id": "5dbed63f",
    "metadata": {},
    "source": [
-    "## Introduction to the CNV-w2a2 network <a id=\"intro_cnv\"></a>\n",
+    "## Introduction to the CNV-w2a2 network <a id='intro_cnv'></a>\n",
     "\n",
     "The particular quantized neural network (QNN) we will be targeting in this notebook is referred to as CNV-w2a2 and it classifies 32x32 RGB images into one of ten CIFAR-10 classes. All weights and activations in this network are quantized to two bit, with the exception of the input (which is RGB with 8 bits per channel) and the final output (which is 32-bit numbers). It is similar to the convolutional neural network used in the [cnv_end2end_example](../end2end_example/bnn-pynq/cnv_end2end_example.ipynb) Jupyter notebook.\n",
     "\n",
@@ -116,7 +116,7 @@
    "id": "c764ed76",
    "metadata": {},
    "source": [
-    "## Quick recap, how to setup up default builder flow for resource estimations <a id=\"recap_builder\"></a>"
+    "## Quick recap, how to setup up default builder flow for resource estimations <a id='recap_builder'></a>"
    ]
   },
   {
@@ -305,7 +305,7 @@
    "id": "7e561a91",
    "metadata": {},
    "source": [
-    "## Build steps <a id=\"build_step\"></a>"
+    "## Build steps <a id='build_step'></a>"
    ]
   },
   {
@@ -369,7 +369,7 @@
    "id": "e9c2c97f",
    "metadata": {},
    "source": [
-    "### How to create a custom build step <a id=\"custom_step\"></a>"
+    "### How to create a custom build step <a id='custom_step'></a>"
    ]
   },
   {
@@ -643,7 +643,7 @@
    "id": "a6edf5c4-9213-45cd-834f-615c12685d9e",
    "metadata": {},
    "source": [
-    "## Specialize layers configuration json <a id=\"specialize_layers\"></a>"
+    "## Specialize layers configuration json <a id='specialize_layers'></a>"
    ]
   },
   {
@@ -675,7 +675,7 @@
    "id": "bc90b589-7a92-4996-9704-02736ac4e60e",
    "metadata": {},
    "source": [
-    "The builder flow step before `step_specialize_layers` generates a template json file to set the preferred implementation style per layer. We can copy it from one of the previous runs to this folder and manipulate it to pass it to a new build."
+    "The builder flow step before `step_create_dataflow_partition` generates a template json file to set the preferred implementation style per layer. We can copy it from one of the previous runs to this folder and manipulate it to pass it to a new build."
    ]
   },
   {
@@ -934,7 +934,7 @@
    "id": "5ffbadd1",
    "metadata": {},
    "source": [
-    "## Folding configuration json <a id=\"folding_config\"></a>"
+    "## Folding configuration json <a id='folding_config'></a>"
    ]
   },
   {
@@ -1270,7 +1270,7 @@
    "id": "4a675834",
    "metadata": {},
    "source": [
-    "## Additional builder arguments <a id=\"builder_arg\"></a>"
+    "## Additional builder arguments <a id='builder_arg'></a>"
    ]
   },
   {
@@ -1294,7 +1294,7 @@
    "id": "e0c167f4",
    "metadata": {},
    "source": [
-    "### Verification steps <a id=\"verify\"></a>"
+    "### Verification steps <a id='verify'></a>"
    ]
   },
   {
@@ -1505,7 +1505,7 @@
    "id": "4609f94d",
    "metadata": {},
    "source": [
-    "### Other builder arguments <a id=\"other_args\"></a>"
+    "### Other builder arguments <a id='other_args'></a>"
    ]
   },
   {
@@ -1610,7 +1610,7 @@
    "id": "3b98eb65",
    "metadata": {},
    "source": [
-    "### Example for additional builder arguments & bitfile generation <a id=\"example_args\"></a>"
+    "### Example for additional builder arguments & bitfile generation <a id='example_args'></a>"
    ]
   },
   {

notebooks/advanced/4_advanced_builder_settings.ipynb

@@ -1,4 +1,5 @@
-# Copyright (c) 2020 Xilinx, Inc.
+# Copyright (C) 2020-2022 Xilinx, Inc.
+# Copyright (C) 2022-2024, Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without

src/finn/qnn-data/build_dataflow/build.py

@@ -4,7 +4,8 @@
   "mvau_wwidth_max": 10000,
   "synth_clk_period_ns": 10.0,
   "board": "Pynq-Z1",
-  "standalone_thresholds": true,
+  "standalone_thresholds": false,
+  "folding_config_file": "folding_config.json",
   "shell_flow_type": "vivado_zynq",
   "verify_save_rtlsim_waveforms": true,
   "force_python_rtlsim": true,

src/finn/qnn-data/build_dataflow/dataflow_build_config.json

@@ -1,8 +1,7 @@
 {
   "Defaults": {},
-  "Thresholding_hls_0": {
-    "PE": 49,
-    "ram_style": "distributed"
+  "Thresholding_rtl_0": {
+    "PE": 49
   },
   "MVAU_hls_0": {
     "PE": 16,