I missed that, thanks for the heads up. I replaced the two chdr_deframer_2clk functions with the old chdr_deframer, but that didn't seem to fix things for me. Guess I will have to do a deep dive into the block with chipscope and try to see how things flow. My gut is really telling me it has something to do with how the block is setup at start-up time and the changes that occurred, I just am not sure what changes to clear_tx_seqnum would cause these issues. Did you end up having to modify the axi_wrapper to get your stuff back to working temporarily? --------- Original Message --------- Subject: Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior From: "Brian Padalino" <bpadal...@gmail.com> Date: 6/28/18 3:35 pm Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Hey Jason, On Thu, Jun 28, 2018 at 3:31 PM Jason Matusiak via USRP-users <usrp-users@lists.ettus.com> wrote: I know this is an older thread, but I too am struggling to bring a block that someone else designed for us in 2015.4 to work in 2017.4. I dug around but I don't see any of our custom blocks using clear_tx_seqnum in their sub-modules or their config registers. They do use the config registers quite a bit to set things up, so I am thinking that it might be related to this. Is there a list of other changes that might have happened in RFNoC so I can comb through it? I am guessing I am getting tripped up on something like this, but it would help to narrow down the places to look. There was an addition of bus_clk and bus_rst to the axi_wrapper that is a major change as well between 2015.4 and 2017.4. Did you catch that one? Brian
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
