# \[µTVM\] microTVM M2 Roadmap

**URL:** <https://discuss.tvm.apache.org/t/tvm-microtvm-m2-roadmap/8821>\
**Category:** RFC\
**Created:** [January 8, 2021, 10:36pm UTC](https://discuss.tvm.apache.org/t/tvm-microtvm-m2-roadmap/8821 "2021-01-08T22:36:41Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![areusch](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/areusch/32/2118_2.png) [@areusch](https://discuss.tvm.apache.org/u/areusch)\
**Post date:** [January 8, 2021, 10:36pm UTC](https://discuss.tvm.apache.org/t/tvm-microtvm-m2-roadmap/8821/1 "2021-01-08T22:36:41Z")

</div>

# Background

This document proposes a roadmap towards microTVM **M2** (milestone 2). It aims to collect all of the µTVM thinking done across various forum threads, conversations, and from TVMConf. There are no specific deadlines included here—this document mainly serves to prioritize and group a related set of tasks towards some medium-term goals. That said, this proposal is written expecting the work to span roughly H1 2021.

# Looking Back

Goals from the previous [Standalone µTVM Roadmap](https://discuss.tvm.apache.org/t/rfc-tvm-standalone-tvm-roadmap/6987) are shown here along with some summary points:

**Test simple models on supported hardware without writing any microcontroller code**

- It’s possible to run some models on supported hardware so long as they use a small subset of operators and those models fit into working memory
- It’s difficult to get a list of supported operators
- It’s difficult to decide whether a model fits into memory without directly examining the firmware binary
- TVM drives the compilation flow, which can make debugging difficult

**Easily package a tested model (from #1) into a C library**

- Compiling a Relay function under µTVM produces a C library
- The TVM compilation flow doesn’t diverge from the standard TVM `c` flow
- Public APIs to export the C library are not obvious/well-documented, but you can save the generated library
- Compilation flags for the generated code need to be inferred
- Libraries with external codegen are not supported yet

**Easily autotune supported operators without having to write too much TVM code beyond the model definition**

- This is possible, but definitely not easy.
- AutoTVM bridge for µTVM is still not checked in
- The number of tunable schedules for supported targets is small

# M2 Goals

This roadmap aims to enable these end-user goals:

1. **Support more runtime environments**

2. **µTVM command-line tools (tvmc)**

3. **Make it easy to characterize model footprint**

# Projects

We think these projects are the right ones to pursue in order to enable these goals. More detail for each of these projects will be given in RFCs to follow this one. Projects are listed roughly in the order we propose they be done (but most of these don’t conflict with one another, so given extra bandwidth they could be tackled at any point in time).

1. **Library Generator**

2. **Autotuning support**

3. **Ahead-of-Time Runtime**

4. **RISC-V ISA support**

5. **Comprehensive memory planner**

6. **Project-level API ([RFC](https://discuss.tvm.apache.org/t/tvm-simplifying-the-compiler-interface/8703/3))**

7. **`tvmc` integration**

8. **Pinned Memory**

9. **Footprint Estimation in `tvmc`**

10. **AutoScheduling**

11. **Support multi-core and accelerator-based inference**

## Next Steps

This document is a proposal to the community, and feedback is welcomed. This thread is a great place to discuss the overall direction as well as if there are specific features or goals that are missing or that you’d like to see prioritized.

We intend to drive some of this work from OctoML, but there are a lot of tasks and there are plenty of ways to get involved.

Each of the projects listed here is typically implemented in phases:

1. Proof-of-Concept/RFC
2. PR reviews
3. Documentation updates

If you want to work on one of them, it’s best to post up an RFC/PoC to begin a discussion around it. There are also plenty of ways to make smaller contributions, including reviewing RFCs and PRs, adding polish and smaller features after each projects lands, and fixing bugs and updating documentation.
