Hi all, As you may have seen from the 4.7-RC1 release announcements, we have a bunch of updates to the RFNoC image builder. I would like to provide some context around those.
First, we are not yet ready to ship a new version of RFNoC modtool. With the deprecation of gr-ettus as the way to ship that tool, we have a bunch of work ahead of us to integrate a new modtool into UHD, and we're not there yet. However, the image builder has had some major improvements. Many of those are simply usability improvements: You'll notice the logging output looks different, and we have tried to improve the error messages. This is, to a large extent, done by allowing custom checks within block descriptor YAMLs as well as BSP YAMLs. For example, if you leave important bus connections unconnected in an RFNoC image core file, then you will now get a warning, and must confirm that you know what you're doing if you want the image builder to proceed to build a bitfile. One thing you'll notice is that you now must use the image builder to build FPGA bitfiles, and can no longer directly build bitfiles by running commands like "make X410_X4_400". This may be annoying for people who like to build the stock images, but it makes many things simpler: Now, there is a single way (i.e., calling rfnoc_image_builder) that will make bitfiles. Besides, we no longer have to check in intermediate build artifacts (e.g., the image core auto-generated Verilog) into git, which can cause conflicts or confusion. Side note: If you don't like having install all of UHD, because you just need the image builder, run `cmake -DENABLE_LIBUHD=OFF -DENABLE_PYMOD_UTILS=ON` to just install the image builder and some other Python-based utilities. Probably the biggest new feature is the fact that in the X4x0 series, transport adapters are now part of the image core. That means that you must choose which transports you want to use in the YAML file, instead of by specifying a build target. For example, if you wanted the 10GbE version of the X410, or the 100 GbE version, you would either build the X410_X4_400 or X410_CG_400 target. Now, there is only one target (X410) but you modify the YAML file to choose a single 10 GbE, quadruple 10 GbE, or 100 GbE per QSFP port (of course, you may also leave them unconnected). The main reason this is useful is because it allows you to put custom blocks or transport adapters that use the QSFP ports into your designs. Note that on other devices than X4x0 devices, the previous behaviour is still in place. For example, on X310, you can't define the transport adapters through the YAML files. There is a downside to this feature: If you use a pre-4.7 image core file (which does not specify transport adapters), then you would end up with a bitfile that can't communicate with the outside. You may have guessed it: We added more checks to make it hard for that to happen, the image builder would give you a very obvious warning in that case. Another interesting feature is the ability to add custom Verilog modules. These also require a YAML file to describe them, but can be used to consume or write to IO ports, generate custom clocks, or whatever else you want to do. Some other random features: - Better use of parameters, which can be referenced in YAML files. For example, you can create an IO port with variable width, and make the width a parameter. - Better inclusion/exclusion of build files based on what you need (e.g., if you build a bitfile without DDC, then no DDC IP will be included) - Define IO signatures in any module. If you write a block with custom IO signatures, just include the IO signatures in the block YAML. - Custom paths for build, IP, and output. This means you don't have to write anything inside the RFNoC source tree. - The "build" directory stores all artifacts that get auto-generated during build time. For debugging, you may manually edit these files and use the --reuse option on rfnoc_image_builder to make sure your manual changes don't get overwritten. - Use inheritance to share info between similar image core files. - Separate edge files are no longer used. One item that might trigger some questions is the new "secure image core" feature. This is a response to a feature request to allow mixing proprietary and open-source blocks. Note that we are not going to use that as part of standard bitfiles: All blocks that get shipped with UHD will remain open-source and modifiable (well, as much as possible, we do use Vivado and AMD/Xilinx IP). There may be blocks in the future (not part of UHD) that make use of these secure cores. Going Forward ============ These improvements to rfnoc_image_builder are a first step to making the whole RFNoC image building process more user-friendly and less wading through code examples and trial-and-error. Part of this process will also be a renewed modtool (and also, work on the blocktool), but that's further down the line. The reason we started working on things in this order is what we perceive as the priority in how people engage in using RFNoC: There are more people interested in building custom bitfiles with standard blocks (e.g., adding an FFT, adding a filter) than there are people writing their own blocks -- but even those who do write their own blocks need to use the image builder. I'll leave it at that. This is a good place to ask questions about these updates -- I'll try and cover them! Cheers, Martin
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
