Support espdl

[sun-xiangyu]

ESP-DL is a deep learning library developed by Espressif Systems for deploying neural networks on resource-constrained microcontrollers. The model extension is .espdl.
Since Netron is an excellent tool for visualizing neural network models, we hope to contribute by integrating ESP-DL model support into it.

For this pull request, we have implemented all necessary visualization functions, for example:

• Load .espdl model files.
• Present all layer-related parameters in the sidebar.
• Visualize the entire model as a computation graph.

@lutzroeder , please help review and meger it.

[lutzroeder]

Hi @sun-xiangyu, thank you for the pull request. Can you provide some context why a new format is needed and what purpose it serves instead of using an existing format?

[sun-xiangyu]

Hi @sun-xiangyu, thank you for the pull request. Can you provide some context why a new format is needed and what purpose it serves instead of using an existing format?

esp-dl is written for tiny Espressif MCUs (ESP32-Sx, Cx) that have <1MB RAM and no MMU.To hit the latency/energy numbers we had to add:

• Custom int8/int16 operators that keep the MACs in the vector unit
• Scales with power-of-two shift instead of float32 multipliers
• Support “NHCW” and “N/8HWC8” tensor layouts

None of the existing formats (ONNX, TFLite, Caffe, …) can describe all of these tricks at the same time, so we would have had to carry an out-of-tree “annotation” file anyway.

Users continue to work in PyTorch/TF → export to ONNX → run our open-source tool esp-ppq that does INT8/16 PTQ/QAT and graph transforms, then serializes the result as .espdl.

In short, it is the smallest possible delta that lets us describe the quantized, layout-tweaked graphs that our MCU inference engine needs.

[lutzroeder]

None of the existing formats (ONNX, TFLite, Caffe, …) can describe all of these tricks at the same time, so we would have had to carry an out-of-tree “annotation” file anyway.

Could this be accomplished by using one of the extensible metadata mechanisms formats offer. ONNX for example has metadata_props for most objects. Operators could still use their own conventions. This would avoid inventing yet another graph container format.

[sun-xiangyu]

None of the existing formats (ONNX, TFLite, Caffe, …) can describe all of these tricks at the same time, so we would have had to carry an out-of-tree “annotation” file anyway.

Could this be accomplished by using one of the extensible metadata mechanisms formats offer. ONNX for example has metadata_props for most objects. Operators could still use their own conventions. This would avoid inventing yet another graph container format.

We initially wanted to reuse the ONNX format, but we ran into some issues:

• Protobuf imposes too much overhead for our chip; we can only use FlatBuffer.
• We must ensure that all raw data in the model are 16-byte aligned—for example, the weights and biases in Conv layers.
• Our input layout differs from ONNX. While ONNX can technically accommodate it, the layout doesn’t match ONNX’s declared definitions, so using it verbatim would be confusing.