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
