Regarding the issue of whether Zephyr supports contributions of FPGA-related code #86630
Replies: 6 comments
-
|
Hi @haijun20222! We appreciate you submitting your first issue for our open-source project. 🌟 Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙 |
Beta Was this translation helpful? Give feedback.
-
|
Weird - I tried converting this to a discussion and something strange happened. |
Beta Was this translation helpful? Give feedback.
-
|
I have no idea why I can't seem to convert this to a discussion. In any case
For the majority of Zephyr users, this is sufficient. However, there is a subset of Zephyr users (myself included) who also use Zephyr for codesign (designing and testing both hardware and firmware together). In that case, the build system needs to be aware of any additional tools, build steps, and artifacts needed to build both the RTL and Firmware targets, which goes beyond the scope of what is required for most Zephyr builds. Like many other projects that support an advanced and optional use case for Zephyr development, integration of FPGA / RTL support should be done via a Zephyr module. https://docs.zephyrproject.org/latest/develop/modules.html
https://docs.zephyrproject.org/latest/develop/modules.html#contributing-to-zephyr-modules The section should maybe be titled "Contributing Zephyr Modules" instead of "Contributing to Zephyr Modules" (cc @kartben). @haijun20222 - there are possibly additional technical questions not covered here that may be worthwhile to discuss but it depends on how far along you are with your own efforts. E.g. What kind of tools would ideally be supported and what is the best way to integrate additional tools and build steps in the build system? Typically open source tools would be best to support for the open source community. Tools should be integrated via cmake and python. Additional build steps should be added via cmake dependency. Synthesis of RTL sources should either happen as an intermediate cmake build dependency or as a cmake post-build step, depending on whether codesign generates C sources or header files. Does the Zephyr Project need to run continuous integration with the project and if so, what would the tooling implications be? While FPGA development and codesign of firmware is a great application for Zephyr, it's possible that the Zephyr Project might not want to take on the additional burden of downloading additional tools, etc, or forcing that burden onto all users. Additionally, synthesis and testing of FPGA sources might be beyond the scope of upstream Zephyr testing. It might be the case that such a module can establish a one-way dependency on Zephyr, in which case it becomes more of a downstream user of Zephyr and use a west.yml manifest, for example, that follows the T2 star topology. That downstream module would and should follow best coding practices, rigorous testing methodologies, etc, much like Zephyr. It should run CI etc. Would the Zephyr Project link to the external module? I believe that has been discussed in the past, and if the TSC approves listing a given third-party module, then it could even be listed with the Zephyr Project without the Zephyr Project necessarily running CI for it. Personally, I think that kind of module would be an excellent addition to the community. |
Beta Was this translation helpful? Give feedback.
-
Yup, very weird... |
Beta Was this translation helpful? Give feedback.
-
Same thing happened when I tried to convert #86417 into a discussion, so it's not specific to this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I was going to try it, but I get a |
Beta Was this translation helpful? Give feedback.
-
The code developed in the Zephyr project for supporting FPGA is currently intended to be contributed to the Zephyr community. There are several issues that need to be discussed:
Beta Was this translation helpful? Give feedback.
All reactions