-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC][TVMC] Add support for micro targets #43
[RFC][TVMC] Add support for micro targets #43
Conversation
This RFC is about how TVMC (TVM CLI tool) can be extended to support microTVM targets, considering the variety of platforms supported by microTVM, like Zephyr and Arduino, and also considering future platforms, taking into account the use of custom/adhoc platforms provided by users at their convenience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the RFC! LGTM, just small changes.
I have a question about the case when user provides a template directory. This might not necessarily be related to TVMC, but I'm curious to know where do we check if the provided template project API
supports required methods such as build, flash, etc.
At the current state of TVMC, do we only see an RPC error if that happens?
|
||
**[0]** [RFC] TVMC: Add support for µTVM -- https://discuss.tvm.apache.org/t/rfc-tvmc-add-support-for-tvm/9049 | ||
|
||
**[1]** [RFC][Project API] Extend metadata in ProjectOption -- https://github.com/apache/tvm-rfcs/pull/33 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe refer to the merged RFC now?
https://github.com/apache/tvm-rfcs/blob/main/rfcs/0020-project_api_extend_metadata.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
selected as an option under 'build' will become available. | ||
|
||
`flash` can be used for effectively flashing, to the selected board, the | ||
firmware built. Again, pertinent options for 'flash' context considering the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change to built firmware
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
argh, sure, thanks! Fixed.
|
||
A **key-value pair** is used to specify the options specific to the platforms. | ||
If the option is of type 'bool' the values available are 'true' and 'false'. | ||
Details on project option types are described in **RFC-0020**. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add link for RFC-0020
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@mehrdadh thanks for the review! Yes, if a Project API method implementation is absent a Thus, just as a reference something similar to the following will happen:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gromero thanks for evaluating that case. LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
||
$ tvmc micro flash /tmp/x200 zephyr | ||
usage: tvmc micro flash PROJECT_DIR zephyr [--list-options] -o OPTION=VALUE [OPTION=VALUE ...] | ||
tvmc micro flash PROJECT_DIR zephyr: error: the following arguments are required: -o |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious: why is -o
a required arg? seems it should be always optional (i agree zephyr_board is required for the zephyr microtvm_api_server.py
, but as an API-level concept, it shouldn't always be required to specify -o
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@areusch that's right it should not be always required. It was as a TODO in the Draft PR. I think that if one or more required options exist in the project then -o
must be required, otherwise that should be optional. (actually now --project-options
- I'll update the text accordingly to the reviews in the code that changed the name of that option). It's now done in apache/tvm@93bb565
As a reference, if all options in zephyr are optional, after that change tvmc
will show --project-option
between [ ]
and also no option in the help text appears marked with (required)
:
$ tvmc micro create-project --force /tmp/x46 ~/scripts/sine.tar zephyr --help
usage: tvmc micro create-project project_dir MLF zephyr [--project-option [OPTION=VALUE ...]] [-h]
optional arguments:
--project-option [OPTION=VALUE ...]
extra_files_tar=EXTRA_FILES_TAR
if given, during generate_project, uncompress the tarball at this path into the project dir.
project_type={aot_demo, host_driven}
type of project to generate.
west_cmd=WEST_CMD
path to the west tool. If given, supersedes both the zephyr_base option and ZEPHYR_BASE environment variable. Defaults to '/usr/bin/python3 -m west'.
zephyr_board={mimxrt1050_evk, mps2_an521, nrf5340dk_nrf5340_cpuapp,
nucleo_f746zg, nucleo_l4r5zi, qemu_cortex_r5, qemu_riscv32,
qemu_riscv64, qemu_x86, stm32f746g_disco}
name of the Zephyr board to build for.
config_main_stack_size=CONFIG_MAIN_STACK_SIZE
sets CONFIG_MAIN_STACK_SIZE for Zephyr board.
-h, --help, --list-options
show this help message with platform-specific options and exit.
[...] | ||
``` | ||
|
||
Once both `micro` device and project directory are specified `--list-options` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would --help
not do this? it's okay to go with this route, just curious
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that --list-options
is ok, given that it makes clear to an end user that those options are dynamic options, implemented by the underlying template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@areusch in essence, and specifically to tvmc run
command, this is related to the issue of parse_known_args()
"intercepting" --help
(and -h
) because add_help = True
in the parsers everywhere. Hence that's related to your comment in apache/tvm#9229 (comment).
I was able to resolve it for tvmc micro
tho, so --help
and --list-options
are aliases and show the dynamic options. Thus if we could keep --list-options
in the RFC it would work for both run
and micro
subcommands when listing the options. But on the other hand I'll experiment as you suggested anyway (setting add_help=False on every parser)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I'm very happy with the results we got with this.
` _ffi.libinfo.find_lib_path()` and so can correctly find the libraries taking | ||
into account if TVM being used is from sources or from a installed package. | ||
|
||
Hence for the specific case of the template directories a new function named |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do templates have a friendly name in the metadata or they are presented as the names of the directories such as "arduino" and "zephyr"? This is just out of curiosity, no need to add or change anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at the moment we are using zephyr/arduino and crt( for standalone host crt).
@leandron Thanks a lot for the review. |
This RFC is about how TVMC (TVM CLI tool) can be extended to support microTVM
targets, considering the variety of platforms supported by microTVM, like Zephyr
and Arduino, and also considering future platforms, taking into account the use
of custom/adhoc platforms provided by users at their convenience.