This was the link I meant to paste: https://github.com/EttusResearch/uhd/issues/764
On Mon, Jul 1, 2024 at 2:23 PM Martin Braun <martin.br...@ettus.com> wrote: > Erm, yes -- we managed to ship a version of rfnoc_image_builder in UHD 4.7 > which doesn't render well on dark-themed terminals. Out of all the bugs in > the recent years, I rank this one pretty high on the not critical, but > annoying list. We're tracking it here: > https://github.com/EttusResearch/uhddev/pull/7239 > > --M > > On Tue, Jun 25, 2024 at 12:39 PM Martin Braun <martin.br...@ettus.com> > wrote: > >> 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
