"To verify the simulations a \"golden\" output is calculated as a reference. This is calculated directly from the Brevitas model using torch."
"To verify the simulations a \"golden\" output is calculated as a reference. This is calculated directly from the Brevitas model using PyTorch, by running some example data from the MNIST dataset through the trained model."
]
},
{
"cell_type": "code",
"execution_count": 22,
"execution_count": 2,
"metadata": {},
"outputs": [
{
...
...
@@ -67,7 +67,7 @@
" dtype=float32)"
]
},
"execution_count": 22,
"execution_count": 2,
"metadata": {},
"output_type": "execute_result"
}
...
...
@@ -100,7 +100,7 @@
},
{
"cell_type": "code",
"execution_count": 23,
"execution_count": 3,
"metadata": {},
"outputs": [
{
...
...
@@ -152,7 +152,7 @@
},
{
"cell_type": "code",
"execution_count": 27,
"execution_count": 4,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -165,7 +165,7 @@
},
{
"cell_type": "code",
"execution_count": 57,
"execution_count": 5,
"metadata": {},
"outputs": [
{
...
...
@@ -207,7 +207,7 @@
},
{
"cell_type": "code",
"execution_count": 29,
"execution_count": 6,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -225,7 +225,7 @@
},
{
"cell_type": "code",
"execution_count": 30,
"execution_count": 7,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -245,7 +245,7 @@
},
{
"cell_type": "code",
"execution_count": 33,
"execution_count": 8,
"metadata": {},
"outputs": [
{
...
...
@@ -269,10 +269,10 @@
" "
],
"text/plain": [
"<IPython.lib.display.IFrame at 0x7fa3496350f0>"
"<IPython.lib.display.IFrame at 0x7fb461dd6710>"
]
},
"execution_count": 33,
"execution_count": 8,
"metadata": {},
"output_type": "execute_result"
}
...
...
@@ -295,7 +295,7 @@
},
{
"cell_type": "code",
"execution_count": 34,
"execution_count": 9,
"metadata": {},
"outputs": [
{
...
...
@@ -331,7 +331,7 @@
},
{
"cell_type": "code",
"execution_count": 35,
"execution_count": 10,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -351,14 +351,14 @@
},
{
"cell_type": "code",
"execution_count": 58,
"execution_count": 11,
"metadata": {},
"outputs": [
{
"name": "stdout",
"output_type": "stream",
"text": [
"Results are the same\n"
"Results are the same!\n"
]
}
],
...
...
@@ -403,7 +403,7 @@
},
{
"cell_type": "code",
"execution_count": 60,
"execution_count": 12,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -421,7 +421,7 @@
},
{
"cell_type": "code",
"execution_count": 61,
"execution_count": 13,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -443,7 +443,7 @@
},
{
"cell_type": "code",
"execution_count": 62,
"execution_count": 14,
"metadata": {},
"outputs": [
{
...
...
@@ -475,7 +475,7 @@
},
{
"cell_type": "code",
"execution_count": 63,
"execution_count": 15,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -486,7 +486,7 @@
},
{
"cell_type": "code",
"execution_count": 64,
"execution_count": 16,
"metadata": {},
"outputs": [],
"source": [
...
...
@@ -499,7 +499,7 @@
},
{
"cell_type": "code",
"execution_count": 66,
"execution_count": 17,
"metadata": {},
"outputs": [
{
...
...
@@ -519,6 +519,13 @@
"else:\n",
" print(\"The results are not the same!\")"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {},
"outputs": [],
"source": []
}
],
"metadata": {
...
...
%% Cell type:markdown id: tags:
# FINN - Functional Verification of End-to-End Flow
**Important: This notebook depends on the tfc_end2end_example notebook, because we are using models that are available at intermediate steps in the end-to-end flow. So please make sure the needed .onnx files are generated to run this notebook.**
In this notebook, we will show how to take the intermediate results of the end-to-end tfc example and verify their functionality with different methods. In the following picture you can see the block in the end-to-end flow about the *Simulation & Emulation flows for functional verification*. Besides the methods in this notebook, there is another one that is covered in the Jupyter notebook [tfc_end2end_example](tfc_end2end_example.ipynb): remote execution. The remote execution allows functional verification directly on the PYNQ board, for details please have a look at the mentioned Jupyter notebook.
%% Cell type:markdown id: tags:
%% Cell type:markdown id: tags:
We will use the following helper functions, `showSrc` to show source code of FINN library calls and `showInNetron` to show the ONNX model at the current transformation step. The Netron displays are interactive, but they only work when running the notebook actively and not on GitHub (i.e. if you are viewing this on GitHub you'll only see blank squares).
To verify the simulations a "golden" output is calculated as a reference. This is calculated directly from the Brevitas model using torch.
To verify the simulations a "golden" output is calculated as a reference. This is calculated directly from the Brevitas model using PyTorch, by running some example data from the MNIST dataset through the trained model.
If an ONNX model consists of [standard ONNX](https://github.com/onnx/onnx/blob/master/docs/Operators.md) nodes and/or FINN custom operations that do not belong to the fpgadataflow (backend $\neq$ "fpgadataflow") this model can be checked for functionality using Python. General information about FINN custom op nodes can be found in Jupyter notebook [2_custom_op.ipynb](../internals/2_custom_op.ipynb).
To simulate a standard ONNX node [onnxruntime](https://github.com/microsoft/onnxruntime) is used. onnxruntime is an open source tool developed by Microsoft to run standard ONNX nodes. For the FINN custom op nodes execution functions are defined. The following is an example of the execution function of a XNOR popcount node.
"""Simulates XNOR-popcount matrix multiplication as a regular bipolar
matrix multiplication followed by some post processing."""
# extract the operand shapes
(M, K0) = inp0.shape
(K1, N) = inp1.shape
# make sure shapes are compatible with matmul
assert K0 == K1, "Matrix shapes are not compatible with matmul."
K = K0
# convert binary inputs to bipolar
inp0_bipolar = 2.0 * inp0 - 1.0
inp1_bipolar = 2.0 * inp1 - 1.0
# call regular numpy matrix multiplication
out = np.matmul(inp0_bipolar, inp1_bipolar)
# XNOR-popcount does not produce the regular dot product result --
# it returns the number of +1s after XNOR. let P be the number of +1s
# and N be the number of -1s. XNOR-popcount returns P, whereas the
# regular dot product result from numpy is P-N, so we need to apply
# some correction.
# out = P-N
# K = P+N
# out + K = 2P, so P = (out + K)/2
return (out + K) * 0.5
%% Cell type:markdown id: tags:
The function contains a description of the behaviour in Python and can thus calculate the result of the node.
This execution function and onnxruntime is used when `execute_onnx` from `onnx_exec` is applied to the model. The model is then simulated node by node and the result is stored in a context dictionary, which contains the values of each tensor at the end of the execution. To get the result, only the output tensor has to be extracted.
The procedure is shown below. We take the model right before the nodes should be converted into HLS layers and generate an input tensor to pass to the execution function. The input tensor is generated from the Brevitas example inputs.
The result is compared with the theoretical "golden" value for verification.
%% Cell type:markdown id: tags:
## Simulation (npysim) using C++
When dealing with HLS custom op nodes in FINN the simulation using Python is no longer sufficient. After the nodes have been converted to HLS layers, the simulation using C++ can be used. To do this, the input tensor is stored in an .npy file and C++ code is generated that reads the values from the .npy array, streams them to the corresponding finn-hlslib function and writes the result to a new .npy file. This in turn can be read in Python and processed in the FINN flow. For this example the model after the conversion to HLS layers is used.
Besides the .cpp file, the folder contains .h files with the weights and thresholds. The shell script contains the compile command and *node_model* is the executable generated by compilation. Comparing this with the `executable_path` node attribute, it can be seen that it specifies exactly the path to *node_model*.
%% Cell type:markdown id: tags:
To simulate the model the execution mode(exec_mode) must be set to "npysim". This is done using the transformation SetExecMode.
Now the model can be executed using `execute_onnx`. The function reads the `exec_mode` and writes the input into the correct directory in a .npy file. To be able to read this in C++, there is an additional .hpp file ([npy2apintstream.hpp](https://github.com/Xilinx/finn/blob/master/src/finn/data/cpp/npy2apintstream.hpp)) in FINN, which uses cnpy to read .npy files and convert them into streams, or to read a stream and write it into an .npy. [cnpy](https://github.com/rogersce/cnpy) is a helper to read and write .npy and .npz formates in C++.
The result is again compared to the "golden" output.
The emulation using [PyVerilator](https://github.com/maltanar/pyverilator) can be done after IP blocks are generated from the corresponding HLS layers. Pyverilator is a tool which makes it possible to simulate verilog files using verilator via a python interface.
We have two ways to use rtlsim, one is to run the model node-by-node as with the simulation methods, but if the model is in the form of the dataflow partition, the part of the graph that consist of only HLS nodes could also be executed as whole.
%% Cell type:markdown id: tags:
Because at the point where we want to grab and verify the model, the model is already in split form (parent graph consisting of non-hls layers and child graph consisting only of hls layers) we first have to reference the child graph within the parent graph. This is done using the node attribute `model` for the `StreamingDataflowPartition` node.
First the procedure is shown, if the child graph has ip blocks corresponding to the individual layers, then the procedure is shown, if the child graph already has a stitched IP.
%% Cell type:markdown id: tags:
### Emulation of model layer-by-layer
The child model is loaded and the `exec_mode` for each node is set. Then it is saved in a new .onnx file so that the changed model can be referenced in the parent model.
The next step is to load the parent model and set the node attribute `model` in the StreamingDataflowPartition node (`sdp_node`). Afterwards the `exec_mode` is set in the parent model in each node.
Because the necessary files for the emulation are already generated in Jupyter notebook [tfc_end2end_example](tfc_end2end_example.ipynb), in the next step the execution of the model can be done directly.
Here we use the same procedure. First the child model is loaded, but in contrast to the layer-by-layer emulation, the metadata property `exec_mode` is set to "rtlsim" for the whole child model. When the model is integrated and executed in the last step, the verilog files of the stitched IP of the child model are used.
