Hi, I am using axi_rate_change with my custom noc block and seeing the following error show up at the end-of-burst (i.e., everything seems to work fine until I issue the stop streaming command). As a result, subsequent bursts do not behave since things are left in a bad state.
*[ERROR] [RX FLOW CTRL] *Error unpacking packet: ValueError: Bad CHDR or packet fragment*[ERROR] [STREAMER] *The receive packet handler caught a value exception. My noc graph is the following: Radio => DDC => Myblock => host One thing of note about my MyBlock is that it has long latency as it contains 4 FFT cores (max 4096, but set to 1024) in series along with some other stuff. MyBlock also has capability to bypass the 2nd half of the block (containing 2 of the 4 FFTs). When I exercise this bypass switch, the frequency of this error drops drastically (although not entirely) from near 100% to perhaps 10%. So, my question is: is there any issue with long latency in user IP when using "axi_rate_change" (and if so, is there a way to fix it?)? I reviewed "axi_rate_change" since the error indicates a bad CHDR (which my IP does not touch since it is handled in axi_rate_change). A few remarks: - In the comments at the top, there is a note that says "User code with long pipelines may need to increase HEADER_FIFOSIZE", but this appears to me to be a "stale" comment that was applicable to an old version of this block. Perhaps there previously was a FIFO for the header, but I think the block was re-architected to eliminate the need for this FIFO. - After reviewing the current code in the block, I can't see any problem with user IP having long latency. For very long latency on the order of perhaps 80ms, it seems that the error/warning signals would be corrupted because of a throttle counter overflow, but I can't see how this would impact the streaming operation Any help would be greatly appreciated. Thanks. Rob
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
