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 :) 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? --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-tvmc-add-support-for-tvm/9049/9) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/26bf4baa6332fe1ed08f7ad05516a2af40a57b3d66486d5465fc0f32b3394149).
