[RFC] TVMC: Add support for µTVM

Development pre-RFC
9

Hi Andrew!

Thanks a lot for the review.

→ 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.

OK.

→ Model Library Format 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.

Right, I think there is a consensus round the need :slight_smile: Model Library Format looks promising, I think it would be good to list all the use-cases (TVM, microTVM using an SDK, static runtime, application dlopen’ning directly a module .so) and examples for each on where (which folder) each kind of files will finally land after each command. I’ll try to make it and comment on the Mini-map.

→ 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:

Yeah, I thought a bit more about it. It sounds good, yep. I think run would need to have micro sub-command :+1:

and a new command tvmc micro gen-project (or something) would be added to generate the e.g. Zephyr project.

oh that’s cool. Copying (or generating) it from the template dir you mentioned right?

→ 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.

Right, I think it is not indeed necessary to pass the SDK (like zephyr) to the compile command because I understand build.relay doesn’t need to know anything about the “board” (contrary to what is used in the prototype of this RFC document) and about the SDK used. tvmc micro build maybe should address it?

For this, I’d propose that an e.g. git sha1 of the Project API repo should be enough.

Sorry, I could not follow you here.

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.

By “device serial numbers” do you mean the usb serial device number? If so currently we allow only one of such a device to be available and it’s probed, failing if more than 1 serial port is available no? Maybe we should stick with that default and add an option to the user to specify it when desired. Anyway, I think that info should not be in the metadata, it should be left by the user to specify when tvmc micro flash and tvmc run is executed?