Hi Manupa,
Thanks a lot for the review!
My view is we should be primarily be able to provide a path way to get something proposed/(eventually get agreed) as the Model Library ([µTVM] Mini-Map: the µTVM Developer Workflow)
Yes, I agree. My proposal conflicts with what is proposed by Andrew on the Mini-Map regarding the Model Library and the Project-level API. I’ll try to update my proposal to reflect it.
I think firmware compilation should be seperate from tvmc compile, however its upto to debate whether we want a seperate peer to compile subcommand or an intergrated option for the compile subcommand. I think most users would want to use TVM directly embedded in the application (w/o going through a RPC server) – similiar what’s done here : ([µTVM] Static Runtime Code Generator - #2 by areusch). Thus, we would not want to tvm to create the final .hex/.elf in tvmc compile but maybe we can have tvmc compile --firmware / tvmc .
I understand that currently tvmc already generates a .tar containing a mod.so object and that shared object can then be either passed to a remote RPC server to be executed or be loaded by the application directly (embedded in it). tvmc generates that .so object on the ‘compile’ stage and that won’t change for Library Module and it will reside in lib/ folder. So for the microTVM targets, that will use the Project API, I think it also makes sense to generated an object ready to be run/loaded on the ‘compile’ stage. How about ‘compile’ command build the relay model, generated the lib0,1,n.c and devc.c (the C sources) – as it does already – and then trigger the firmware build via the Project API that, by its turn, will finish producing the .bin, .hex, .elf files? I think the firmware image in the microTVM has a similar “role” as the .so to be used via a RPC call or when embedded in a application. I’ll comment it too on the Mini-Map topic.
One thing that occurred to me is that we haven’t specify for the Project API where the the parameters.json and the graph,json will reside. Maybe in a bundle inside each project?
I think if we agree tvmc compile is to be reserved for the creation of Model Library, then we can have alignment/unification with current tvmc target specification. What do you think?
I can’t see why tvmc ‘compile’ stage needs to be reserved only for the creation of the Model Library case. Why can’t it also drive the Project-level API case? Well, one thing is that I think that with the new design proposed in the Mini-Map only the target has to be specified, not the board (–board), because that information will be in the project metadata. Then tvmc would pass only the specified target to the SDK used by the project (like Zephyr’s SDK). But maybe you’ve spotted a case I can’t see. Would you mind to explain to me a tad further?