[RFC] TVMC: Add support for µTVM

Development RFC
7

hi @gustavo,

Thanks for posting this up and apologies for the late review! I think tvmc integration would be a very positive thing for µTVM. Here are some thoughts:

→ First off, I agree with @manupa-arm and @leandron that we should split the compilation process into two pieces:

  1. performing tvm.relay.build on a model (e.g. tvmc compile)
  2. compiling a firmware binary (e.g. tvmc micro build)

I think making this split gives us a few advantages, the main one being that it allows tvmc to be a tool in development workflows we haven’t yet envisioned. This also fits well with the way the rest of TVM is built.

→ Model Library Format

2- “Glue” between stages

In order to coordinate between the different stages in the workflow (compile, flash, run, tune) it’s necessary to have a persistent file with metadata describing several aspects of the build

I think this sounds very similar to Model Library Format, so I think we have similar concerns. If we make the split above, it seems like they serve a similar purpose. I think it would be great to wrap any concerns here into the Model Library Format RFC, which we should write soon.

→ Commands

I think it might be interesting to contemplate making a micro sub-command of tvmc for build, flash, and perhaps run. This would provide a place for micro-specific commands without cluttering the top-level command tree of tvmc, which could confuse non-micro users. So this would be:

  1. tvmc compile
  2. tvmc micro build
  3. tvmc micro flash
  4. tvmc run

These commands should line up well with the Project API–the main difference being that commands #2 and #3 would be handled entirely by the generated project’s build system, and a new command tvmc micro gen-project (or something) would be added to generate the e.g. Zephyr project.

It would also be great if, for now, the tvmc micro subcommands all took an explicit command-line arg to that identifies the project using the directory where the project lives (or should live for tvmc micro build). ZephyrCompiler needs this information anyway–it just doesn’t treat it as a “template project” for now. I think it would also be fine in the tvmc micro build implementation to shutil.copytree the template project (for now, given as a separate e.g. --template-project arg) into the location specified on the command-line.

→ Selecting microTVM targets

I think if we specify --target on the command-line, that should be the TVM target string. We could add “zephyr” to that target string, but here is one thing to consider: the point of that target string is to capture, for autotuning’s sake, the configuration of the code and target device up to the point it impacts the timed implementation. For this, I’d propose that an e.g. git sha1 of the Project API repo should be enough.

After the Project API refactor, we will need to identify to tvmc micro gen-project which Project API to use. This can be done through the project paths given on the command line, assuming we take the approach in the mini-map of placing the project API implementation in a known file e.g. $project_path/microtvm.py. So, I’m not sure we need to explicitly mention Zephyr by name in the tvmc command line.

→ Misc thoughts

It’s also proposed that adding information about the target and board used in the compile stage into the metadata file avoids the need to specify the ‘–device’ flag again on next stages, like for ‘run’, since the target and board were already specified previously and can’t change…

I agree with this but I would also propose the caveat that device serial numbers be left out of the generated metadata. The reason is that these are specific to the machine while compiled firmware may not be, so placing them in the Model Library Format metadata and then downstream artifacts may restrict portability.

→ Next steps

I think it would be great to agree on the Model Library Format and Mini-Map before we proceed too far towards merging this one. Beyond that, I think it should be more-or-less compatible before and after the Project API change. In my mind, I’d thought to do these two in sequence, but I’m glad we have discussed this because I think tvmc support will be a great addition to µTVM and I think we can proceed in parallel.

Let me know your thoughts!