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. 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. 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
