Refactor MLIF

[PhilippvK]

Motivation

First, I would like to clarify that MLIF is an abbreviation for "Machine Learning Interface" @rafzi came up with some time ago.

There are a few things regarding the future of this MLonMCU component I would like to discuss in the following.

Alternative Naming

For users not familar with the term MLIF it might sound confusing, especially considering that it can easily messed up with MLF (Model Library Format) which is used in MLonMCU as well. Let me know what your think about this.

Extendability

Im am not so happy with the way how the frameworks, backends and targets are selected via the command line.

Compared to the original version I already replaced the mechanism implicityly using -DTVM_DIR=foo -DTF_SRC= and -DTVM_RT=ON -DTVM_AOT=OFF by explicity flags taking a string value instead which will be checked in lib/ml_interface/CMakeLists.txt:

-DFRAMEWORK=tvm -DBACKEND=tvmaot -DTARGET_SYSTEM=etiss_pulpino

However this does not generalize well as different Frameworks/Backend/Targets are not independend to each other.

A first proposal to an alternative approach would be the following:

Every Framework

Example structure:

.
└── cmake
    ├── backends
    │   ├── tvmaot.cmake
    │   ├── tvmcg.cmake
    │   └── tvmrt.cmake
    ├── frameworks
    │   ├── tflite.cmake
    │   └── tvm.cmake
    └── targets
        ├── etiss_pulpino.cmake
        └── host_x86.cmake

However there are also some caveats:

• Redundancy of code which could be shared between files
• Ideally backends should imply the framework they are based to get rid of the need to specify both on the command line
• Using tvmaot.cmake etc. inside here does not feel right as the Repo should be useful even without MLonMCU on top. Therefore be might be able to omit -DBACKEND=tvmaot and just use something like this instead: -DFRAMEWORK=tvm -DTVM_EXECUTOR=aot

In the end it would be great if we could come up with an interface which suits solve the mentioned issues. Ideally a third part should be able to replace our mlonmcu-sw completely by their target-software stack (i.e. RTOS based) by just makeing sure that the alternative implementation is using the pre-defined interfaced supported by MLonMCU.

[PhilippvK]

The code mentioned changes are done.

[PhilippvK]

Leaving this open as the naming (Machine Learning Interface / MLIF) is still not ideal in my opinion...