On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users <usrp-users@lists.ettus.com> wrote: > Recently there was a significant change to the noc_block_vector_iir > (specifically the vector_iir): > > > https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187 > > It's a pretty significant re-write of the block, and this behavior has me > asking a few questions: > > 1) Can anyone at Ettus expand on the reason for the major re-write? It > appears that the block itself worked previously so it seems like re-writing > it was a lot of effort to potentially add new bugs to things which weren't > there previously. >
There were several reasons that contributed to the re-writing that block. First off, there was a bug in the delay line implementation that needed to be fixed. Secondly, we wanted to improve the readability and resource utilization of blocks where users hand-write their DSP (as opposed to using third-party AXI-Stream IP). The old approach was to implement a DSP algorithm using basic operations like addition, multiplication, rounding, etc each with AXI-Stream handshaking. This has the following drawbacks: 1) The code is a bit hard to read because the AXI-Stream stuff takes up code real-estate 2) It's hard to let the tools infer DSP primitives automatically because AXI-Stream can get in the way of the standard Xilinx-intended control sets. 3) The AXI-Stream logic takes up more fabric resources. The Vector IIR block is the first block that wraps AXI-Stream around the entire DSP algorithm instead of around basic functions. This is the way we intend to write future blocks with hand-implemented DSP. The change is actually a step forward in terms of stability because the API to the actual DSP kernel is much simpler and intuitive, and is much closer to how FPGA DSP implementation is taught. The simpler API also makes it easy for the Xilinx tools to perform optimization/mapping because AXI-Stream handshaking is not in the way. Don't get me wrong, AXI-Stream is great, we are just changing the granularity at which we implement it. > 2) Why wasn't this re-written block added as a second option for a vectored > IIR implementation? There are 64-bits worth of RFNoC block ID's out there. > I understand if you don't want to support specific RFNoC blocks anymore, and > want to move onto new ones, but can you retire them in a better, more > thought out way? Moving them to a deprecated folder is fine and giving one > or two releases to get people to move away is fine, but please stop gutting > and re-writing something like it hasn't completely changed. There are > people who may want to stick with the old way of doing things (the old > DDC/DUCs are another recent re-write that could have been handled better). > Please give us a chance at trying to maintain stability. > Other than fixing the delay line issue, we did not change the behavior of the block. We also did not change the software or FPGA interface to the block. All that changed was the implementation, and that does not warrant a new block or a deprecated copy. You can argue that if something/anything changes in a piece of functional code, that it is inherently unstable. However, that applies to everything from a one liner bugfix to complete rewrite. That said, if you noticed a bug in the code, then we will absolutely need to and will fix it. In general, RFNoC is still evolving and we are slowly cleaning up interfaces to reach a point where we are confident that it is easy to use and it efficiently supports what our customers want to do. We always try to balance improvements with backwards compatibility, but there are cases where we cannot guarantee compatibility. In those cases we will try to minimize the incompatible changes, and increment the compatibility number to ensure that changes don't go unnoticed to software. None of that was true for this particular block change. > I've tried to emphasize stability previously, and it seems like the host > side tries, almost to a fault, to maintain ABI compatibility and stability, > but the FPGA side seems to have a complete disregard for stability. > > It would be really nice if someone from Ettus could answer the two questions > I posed. > > Thanks, > Brian > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
