[External] RFC: Separate Project Generation from Makefile

320 views
Skip to first unread message

Pete Warden

unread,
Nov 22, 2020, 9:31:39 PM11/22/20
to SIG Micro, TF Lite Micro
I'm hoping we can make the project generation process more scalable and maintainable so that we can support existing platforms better, and expand to even more, so I've put together an RFC with a refactoring proposal:

https://docs.google.com/document/d/1gfbpBtiivYMenCDIvJb-m5RIV4rKAR5dvdAJC5LLv8o/edit?usp=sharing

Please feel free to comment on the doc with ideas on improving this, thanks!

Pete

Tim 'mithro' Ansell

unread,
Nov 23, 2020, 1:13:17 AM11/23/20
to Pete Warden, SIG Micro, TF Lite Micro
It kind of feels like you are about to recreate the "Generate Your Projects" (https://gyp.gsrc.io/index.md) tool?


--
You received this message because you are subscribed to the Google Groups "SIG Micro" group.
To unsubscribe from this group and stop receiving emails from it, send an email to micro+un...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/micro/CAOLmV955Q%2Br05DOBzAiNiB6A7jJ1cp77%3DfM93LcgqBjKb18zZA%40mail.gmail.com.

Pete Warden

unread,
Nov 23, 2020, 11:23:19 AM11/23/20
to Tim 'mithro' Ansell, SIG Micro, TF Lite Micro
That's true, the original project generation approach was heavily influenced by my experience with gyp. I found it a very handy approach for cross-platform building on the desktop.

Unfortunately I don't think it would be easy to reuse gyp for our platforms, since it is aimed at desktop/mobile IDEs, the input format is a lot more general than we need, and I don't think it will be straightforward for third parties to write their own project generation scripts within the framework. 

Daniel Situnayake

unread,
Nov 23, 2020, 3:21:44 PM11/23/20
to Pete Warden, Tim 'mithro' Ansell, SIG Micro, TF Lite Micro
Thanks for sharing, Pete, this is exciting—I think moving to Python for most of the project generation infrastructure will be helpful.

I wanted to share an insight you may find interesting (but may just as easily be of no use whatsoever). One of the challenges we have at Edge Impulse is that we need to provide a single library of C++ code—including TensorFlow Lite—that can be compiled for multiple different targets.

Some of these devices may have special kernel support within TF Lite. For example, some Arm cores can benefit from CMSIS-NN kernels. Because we want our library to support both Arm and non-Arm cores, we have to include the source for both kernels.

The way we do this right now is:

1. Generate a TF Lite project with reference kernels
2. Generate a TF Lite project with CMSIS-NN kernels
3. Append the contents of each CMSIS-NN kernel into the same file as its reference kernel equivalent
4. Insert a preprocessor conditional that looks at a macro (e.g. 'USE_CMSIS_NN') to determine at compile time which kernel implementation to use
5. In another file, define the USE_CMSIS_NN macro and gate it on something that is provided by the target's compiler (e.g.  "defined(__TARGET_CPU_CORTEX_M0) || defined(__TARGET_CPU_CORTEX_M0PLUS) || defined(__TARGET_CPU_CORTEX_M3) || defined(__TARGET_CPU_CORTEX_M4) || defined(__TARGET_CPU_CORTEX_M7)")

The resulting code (packaged along with dependencies) can then be compiled for whatever platform.

We've found this extremely helpful, although it may be rare that other folks want to be so general purpose. Either way, I thought it might be useful to share. Perhaps it would be nice if there was an option in the build system to create this type of multi-target output if a list of targets is provided instead of a single one?

Warmly,
Dan



--
Daniel Situnayake
Founding TinyML Engineer, Edge Impulse
Reply all
Reply to author
Forward
0 new messages