Arm backend: Add ethos_u_minimal_example jupyter notebook

[AdrianLundell]

This example provides a good base understanding of all steps needed to lower and run a Pytorch module through the EthousUBackend. It also works as a starting point for creating scripts for lowering a custom network.

cc @digantdesai @freddan80 @per @zingo @oscarandersson8218

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/9543

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures

As of commit 2a38798 with merge base 043c7a0 ():

NEW FAILURES - The following jobs have failed:

• Lint / lintrunner / linux-job (gh)
  >>> Lint for examples/models/moshi/mimi/test_mimi.py:
• pull / unittest-buck / macos / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 11

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[digantdesai]

couple of high level comments,

• without CI this will be broken
• why not google colab and keep it live?
• how is it going to stay in sync with docs given there is a large-ish overlap

[AdrianLundell]

Good points, here are my thoughts:

• We are going to test this in our internal CI, could definitely be worth it adding it to upstream CI as well.
• What's the added benefit of using google colab? I am not that familiar with it but I haven't had any problems with using a regular notebook.
• I don't think we have a settled "strategy" on documentation, my personal view is that it makes sense to have two types of slightly overlapping documentation, the detailed main docs, and user guides such as this one. Any other docs, README:s etc, should refer to these rather than repeating info. There will be some work needed to keep these two in sync, but an interactive notebook user guide should be easier to keep in sync compared to a doc since it can be tested in CI, in addition to it being a better user experience.

[AdrianLundell]

@digantdesai What do you think about this answer?

[digantdesai]

What's the added benefit of using google colab? I am not that familiar with it but I haven't had any problems with using a regular notebook.

It can be live on the docs page. Checking in a notebook is also fine, it is just an extra step to actually run it.

to have two types of slightly overlapping documentation

It would be nice if they can originate from the same source, preferably a code in CI.

[AdrianLundell]

I see two advantages in leaving it as it is, first it is nice to not be reliant on an external service, and second it works as a sanity check to see that you have set up your environment correctly. I am open to having it on google collab as well but we would probably need to have an internal discussion about it as well.

I see now what you mean with overlapping documentation with Eriks pull request #9712 since that is also a type of user guide, I was thinking about the general docs about executorch concepts s.a quantization/dialects or similarly as the main docs. Since that PR mentions following an official backend-template I assume that that is something we will have to conform to.

Running code in CI and then generating a .md and a jupyter notebook seems like a bit of work to get correct, but it might be worth it if it is something used more broadly? Or if we can run the notebook in ci and generate only the .md using some tool (I just now found https://github.com/jupyter/nbconvert by googling for example), although that will probably not follow the template exactly. Yet another solution could be to run the code from the .md and the notebook in CI which would be a little easier but require double updating. Finally we can of course completely skip the notebook idea, I do think that it adds value compared to only .md however in that it is interactive.

[digantdesai]

I think you have better idea about pros and cons than me on this now. My job here is done. :)

I am Ok with this landing, this is not an easy problem, so hopefully we will converge to a better state.