-
Notifications
You must be signed in to change notification settings - Fork 74k
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
TFLM: Add new Cortex M target for running on a FVP #46830
Conversation
* Adds new target for running on a fixed virtual platform based on Arm Corstone-300 software. * Adds test script for running with FVP. * Adds new download scripts. * Adds new CI script. * Adds readme file.
Thanks for contributing to TensorFlow Lite Micro. To keep this process moving along, we'd like to make sure that you have completed the items on this list:
We would like to have a discussion on the Github issue first to determine the best path forward, and then proceed to the PR review. |
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'll try and give some concrete suggestions for micro_test.h tomorrow.
Also, can you add to the PR description how much additional time you expect this to add to the CI? We already take quite long (20+ minutes) and I at least want to have any additions be documented.
tensorflow/lite/micro/tools/make/targets/cortex_m_corstone_300_makefile.inc
Outdated
Show resolved
Hide resolved
@advaitjain To speed up the time for the CI script we could just test the CMSIS-NN kernels. Then it took 1 minute and 44 seconds |
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.
5 mins is a lot to add to each CI run (we are currently at 20mins). Let's not add to test_all.sh in this PR.
Once all the changes are merged, we can figure out what a suitable approach might be. We can also test on the CI servers and see what the time increase is on there.
Running a smaller set of tests, or making it a continuous build instead of at every presubmit might be more reasonable. 2 mins might be ok, but we start to go down a slippery slope that I'd like to avoid.
As another data-point, the xtensa builds also take around 4 mins and we have them as continuous builds (3 times a day) which we have found sufficient.
CCFLAGS += -D$(ARM_CPU)$(CMSIS_ARM_FEATURES) | ||
|
||
THIRD_PARTY_CC_SRCS += \ | ||
$(wildcard $(ETHOS_U_CORE_PLATFORM)/*.c) |
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.
Perhaps it better to be explicit what files we include from core platform?
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.
Yes
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 don't see any changes for this comment. Just flagging in case you missed some changes when adding commits.
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 see the changes at lines 135-137
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'm a bit confused. I see
THIRD_PARTY_CC_SRCS += \
 $(wildcard $(ETHOS_U_CORE_PLATFORM)/*.c)
and
THIRD_PARTY_CC_SRCS += \
 $(ETHOS_U_CORE_PLATFORM)/retarget.c \
 $(ETHOS_U_CORE_PLATFORM)/uart.c`
is this intentional?
I was able to get the time down to 3 minutes and 14 seconds by changing the FVP cpulimit to 1. With only CMSIS-NN kernels it was 74 seconds. |
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.
looks good. only minor nits and there's a merge conflict due to #46904
We can get this merged and then look at what is involved in turning on this target on CI separately.
tensorflow/lite/micro/system_setup.h
Outdated
#ifndef TENSORFLOW_LITE_MICRO_TESTING_SYSTEM_SETUP_H_ | ||
#define TENSORFLOW_LITE_MICRO_TESTING_SYSTEM_SETUP_H_ | ||
|
||
namespace system_setup { |
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.
nit: we're going with a flat tflite namespace and descriptive function names.
If you'd prefer we can go with tflite::InitializeTarget instead of tflite::Initialize.
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.
here's some more context on this decision: https://abseil.io/tips/130
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.
Sure
|
||
MICRO_LITE_BENCHMARKS := $(filter-out tensorflow/lite/micro/benchmarks/Makefile.inc, $(MICRO_LITE_BENCHMARKS)) | ||
|
||
EXCLUDED_TESTS := \ |
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.
can we make a bug for these excluded tests and add a TODO(#) here.
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.
Ok, just adding a TODO then without a reference I assume
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.
sorry for not being explicit in my earlier comment.
I was referring to making a github issue and linking to that from here, similar to:
tensorflow/tensorflow/lite/micro/micro_error_reporter.cc
Lines 62 to 65 in beab125
// TODO(#46937): Until we resolve the global variable issue with Renode, we | |
// will be creating a new ErrorReporter object each time. While this is | |
// inefficient, it still allows us to make progress. | |
error_reporter_ = new (micro_error_reporter_buffer) MicroErrorReporter(); |
In this case the github issue should give the error message and exact commands and we can add a note here that we are excluding to get the first integration merged and will come back and fix the issue later.
-I$(CMSIS_PATH)/Device/ARM/$(ARM_CPU)/Include \ | ||
-I$(CMSIS_PATH)/CMSIS/Core/Include | ||
|
||
MICRO_LITE_BENCHMARKS := $(filter-out tensorflow/lite/micro/benchmarks/Makefile.inc, $(MICRO_LITE_BENCHMARKS)) |
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.
a bug for the excluded benchmark?
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.
Ok
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.
similar to the excluded tests, let's make a github issue and add a TODO(#) comment here.
Good info, thanks! Filtering for just the CMSIS kernels might be more maintenance overhead than we want to take on. We do have the ability to run more than a single CI job (which will soon become easier), but let's decide what we want to do after this PR is merged. |
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.
sorry for the back and forth, I should have been more explicit in my previous review.
asking for a few more clarifications here.
CCFLAGS += -D$(ARM_CPU)$(CMSIS_ARM_FEATURES) | ||
|
||
THIRD_PARTY_CC_SRCS += \ | ||
$(wildcard $(ETHOS_U_CORE_PLATFORM)/*.c) |
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'm a bit confused. I see
THIRD_PARTY_CC_SRCS += \
 $(wildcard $(ETHOS_U_CORE_PLATFORM)/*.c)
and
THIRD_PARTY_CC_SRCS += \
 $(ETHOS_U_CORE_PLATFORM)/retarget.c \
 $(ETHOS_U_CORE_PLATFORM)/uart.c`
is this intentional?
|
||
MICRO_LITE_BENCHMARKS := $(filter-out tensorflow/lite/micro/benchmarks/Makefile.inc, $(MICRO_LITE_BENCHMARKS)) | ||
|
||
EXCLUDED_TESTS := \ |
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.
sorry for not being explicit in my earlier comment.
I was referring to making a github issue and linking to that from here, similar to:
tensorflow/tensorflow/lite/micro/micro_error_reporter.cc
Lines 62 to 65 in beab125
// TODO(#46937): Until we resolve the global variable issue with Renode, we | |
// will be creating a new ErrorReporter object each time. While this is | |
// inefficient, it still allows us to make progress. | |
error_reporter_ = new (micro_error_reporter_buffer) MicroErrorReporter(); |
In this case the github issue should give the error message and exact commands and we can add a note here that we are excluding to get the first integration merged and will come back and fix the issue later.
-I$(CMSIS_PATH)/Device/ARM/$(ARM_CPU)/Include \ | ||
-I$(CMSIS_PATH)/CMSIS/Core/Include | ||
|
||
MICRO_LITE_BENCHMARKS := $(filter-out tensorflow/lite/micro/benchmarks/Makefile.inc, $(MICRO_LITE_BENCHMARKS)) |
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.
similar to the excluded tests, let's make a github issue and add a TODO(#) comment here.
didn't see earlier that the bazel build is failing (as part of the TfLite Micro CI). You'll have to add a new target for system_setup, similar to: tensorflow/tensorflow/lite/micro/BUILD Lines 121 to 130 in b57b89f
and add that as a dep to the tests. There's a chance that all the tests will need this additional dependency, which would be very unfortunate. I'll take a look and get back to you. |
…target. This will allow the unit tests to be run on additional targets that need some addiitonal initialization (for example cornstone_300 from tensorflow#46830). This particular change is broken out from the Cornstone PR tensorflow#46830 to be able to have smaller more reviewable PRs. Progress towards tensorflow#46829
I have created #47077 to add InitializeTarget as a separate change (and deal with the bazel dependency issue separate from adding the Cornstone300 target) |
…target. This will allow the unit tests to be run on additional targets that need some addiitonal initialization (for example cornstone_300 from tensorflow#46830). This particular change is broken out from the Cornstone PR tensorflow#46830 to be able to have smaller more reviewable PRs. Progress towards tensorflow#46829
…target. This will allow the unit tests to be run on additional targets that need some addiitonal initialization (for example cornstone_300 from tensorflow#46830). This particular change is broken out from the Cornstone PR tensorflow#46830 to be able to have smaller more reviewable PRs. In the past, we have added state to the DebugLog() and GetCurrentTimeTicks() functions as a way to avoid having an InitializeTarget function. With this change, we are deciding to go with an explicit intitialization step instead. This change has added calls to tflite::InitializeTarget to the tests, benchmarks, and examples and converted the Arduino and SparkfunEdge to make use of this explicit initialization. The changes for the Arduino and SparkfunEdge have not been tested on actual hardware. Progress towards tensorflow#46829
…target. This will allow the unit tests to be run on additional targets that need some addiitonal initialization (for example cornstone_300 from tensorflow#46830). This particular change is broken out from the Cornstone PR tensorflow#46830 to be able to have smaller more reviewable PRs. In the past, we have added state to the DebugLog() and GetCurrentTimeTicks() functions as a way to avoid having an InitializeTarget function. With this change, we are deciding to go with an explicit intitialization step instead. This change has added calls to tflite::InitializeTarget to the tests, benchmarks, and examples and converted the Arduino and SparkfunEdge to make use of this explicit initialization. The changes for the Arduino and SparkfunEdge have not been tested on actual hardware. Progress towards tensorflow#46829
…target. This will allow the unit tests to be run on additional targets that need some addiitonal initialization (for example cornstone_300 from tensorflow#46830). This particular change is broken out from the Cornstone PR tensorflow#46830 to be able to have smaller more reviewable PRs. In the past, we have added state to the DebugLog() and GetCurrentTimeTicks() functions as a way to avoid having an InitializeTarget function. With this change, we are deciding to go with an explicit intitialization step instead. This change has added calls to tflite::InitializeTarget to the tests, benchmarks, and examples and converted the Arduino and SparkfunEdge to make use of this explicit initialization. The changes for the Arduino and SparkfunEdge have not been tested on actual hardware. Progress towards tensorflow#46829
…target. This will allow the unit tests to be run on additional targets that need some addiitonal initialization (for example cornstone_300 from tensorflow#46830). This particular change is broken out from the Cornstone PR tensorflow#46830 to be able to have smaller more reviewable PRs. In the past, we have added state to the DebugLog() and GetCurrentTimeTicks() functions as a way to avoid having an InitializeTarget function. With this change, we are deciding to go with an explicit intitialization step instead. This change has added calls to tflite::InitializeTarget to the tests, benchmarks, and examples and converted the Arduino and SparkfunEdge to make use of this explicit initialization. The changes for the Arduino and SparkfunEdge have not been tested on actual hardware. Progress towards tensorflow#46829
Corstone-300 software.
This is fixing: #46829
The CI script takes about 5 minutes to run for me.