Device3: Fix block control flushing

- Factor out the _start_drain helper function, which starts flushing
data out of the block. We should always be disabling flow control after
we write to the flushing registers.
- Always attempt to flush when calling the _flush function. Previously,
we would check if data appeared to be moving when _flush was called,
and only write to the flush registers if data was moving. However, if
data is stuck for some reason (for example, the block ran out of flow
control credits), this check will give us a false positive, and we
won't flush. Instead, we need to always begin the flushing process,
then check those counters, and return once the counters stop changing.

Note: we need to start flushing before disabling flow control so that
the flushed data isn't flooded onto the crossbar.

Co-authored-by: michael-west <michael.west@ettus.com>
Co-authored-by: Sugandha Gupta <sugandha.gupta@ettus.com>

1 files changed, 3 insertions, 0 deletions

diff --git a/host/include/uhd/rfnoc/block_ctrl_base.hpp b/host/include/uhd/rfnoc/block_ctrl_base.hpp
index 0405ed8b7..b3c9c53d6 100644
--- a/host/include/uhd/rfnoc/block_ctrl_base.hpp
+++ b/host/include/uhd/rfnoc/block_ctrl_base.hpp
@@ -401,6 +401,9 @@ private:
     //! Helper to create a lambda to read tick rate
     double get_command_tick_rate(const size_t port);
 
+    //! Helper to start flushing for this block
+    void _start_drain(const size_t port = 0);
+
     //! Helper to flush any in-flight packets for this block
     bool _flush(const size_t port = 0);