mehrdadh commented on a change in pull request #8: URL: https://github.com/apache/tvm-rfcs/pull/8#discussion_r679553340
########## File path: rfcs/0008-microtvm-project-api.md ########## @@ -0,0 +1,518 @@ +- Feature Name: microtvm_project_api +- Start Date: 2020-06-09 +- RFC PR: [apache/tvm-rfcs#0000](https://github.com/apache/tvm-rfcs/pull/0000) +- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000) + +# Summary +[summary]: #summary + +This RFC describes how TVM integrates with build systems for unconventional platforms, such as those +for microcontrollers and for other bare-metal scenarios. + +# Motivation +[motivation]: #motivation + +Though TVM's primary goal is generating code to implement models from a high-level description, +there are several reasons why a user might want to interact with a platform's build system through +TVM: + +1. To perform autotuning. TVM's internal operator implementations are merely templates and rely on + an automatic search process to arrive at a fast configuration for the template on a given + platform. This search process requires that TVM iteratively build and time code on the platform. +2. To perform remote model execution. A user may wish to try several different models or schedules + on a different platform without rewriting the platform-specific code. Users can do this by + building generated model code against a generic implementation of the microTVM RPC server. +3. To debug model execution remotely. Some aspects of model execution are easy to debug using a + platform-specific debugger; however, some things, such as analyzing intermediate tensor values, + are more easily accomplished with TVM-specific tooling. By leveraging the generic microTVM + RPC server used in (2), TVM can provide such tooling in a platform-agnostic way. + +TVM currently supports these use cases through a set of interfaces: +1. `tvm.micro.Compiler`: used to produce binary and library artifacts. +2. `tvm.micro.Flasher`: used to program attached hardware +3. `tvm.micro.Transport`: used to communicate with on-device microTVM RPC server + +Thus far, implementations of these interfaces have been made for Zephyr, mBED OS, and for +simulated hardware using a POSIX subprocess. The latter two interfaces have proven to be a +relatively good fit; however, `tvm.micro.Compiler` is difficult to implement because it attempts +to replicate a platform's build system in TVM. TVM does not want to incorporate platform-specific +build logic into its codebase. + +This proposal unifies these three interfaces to form a "Project-level" interface, recognizing that +it's typical to interact with unconventional platforms and their build systems at this level. It +simplifies the `Compiler` interaction into a project-level Build, and adds an explicit +`generate_project` method to the interface. These changes remove the need to build components +and drive the link process from TVM. + +As a goal, this proposal aims to allow for the same use cases as are currently supported with these +improvements: + +1. Integrating more naturally with build systems typical of embedded platforms. +2. Allowing TVM to automatically generate projects platforms to define automated scripts to build projects + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +TVM can interact with platform SDKs via its **Project API**. Such SDKs are common when working with +non-traditional OS platforms, such as those commonly used in embedded systems (e.g. Arduino, Zephyr, +iOS). Given a platform-specific implementation of this Project API, TVM can: +1. Generate projects that integrate implemented TVM models with generic platform runtime componeents +2. Build those generated projects +3. Program attached hardware +4. Drive remote model execution via the TVM RPC Server interface. + +This last capability means that TVM can drive autotuning, remotely perform model inference, and debug +models on non-traditional OS such as Arduino, Zephyr, and mobile platforms such as iOS and Android. + +To provide support for a platform, a **template project** is first defined. Template projects are +expected to exist entirely inside a directory and are identified to TVM by the path to the directory +locally. Template projects may live either inside the TVM repository (when they can be included in the +TVM CI) or in other version control repositories. The template project contains at minium an +implementation of the **Project API** inside an executable program known as the +**TVM Project API Server**. + +To begin working with a particular platform's Project API implementation, the user supplies TVM with +the path to the top-level directory. TVM launches an instance the Project API Server (found at a +standard location in that directory). TVM communicates with the Project API Server using JSON-RPC +over standard OS pipes. + +TVM supplies generated code to the Project API Server using [Model Library Format](0001-model-library-format.md). Review comment: sorry, but this needs to change again since the PR is merged :( -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@tvm.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
