[Discuss-gnuradio] Re: Bug due to halfband and Why are the resets removed

[Martin Dvh]

Eric Blossom wrote:
> On Thu, Dec 08, 2005 at 04:54:16PM +0100, Martin Dvh wrote:
> 
>>The new halfbandfilter stuff broke the debug_counter.
>>I think this minipatch is the solution.
>>I found this because I also use a counter in the fpga and it broke when I 
>>updated my sourcetree.
> 
> 
> Thanks!
> 
> 
>>I also wonder why all the resets are removed.
>>Are all the registers reset in another way now?
> 
> 
> They weren't *all* removed.  Just the ones that were causing a problem.
> The right answer is to add yet another reset signal that handles all
> the rest, and just toggle that one after the FPGA is loaded.  It's a
> little bit complicated since the FX2 code has some knowledge of those
> particular registers.
> 
> Currently we are running with two resets:  tx_dsp_reset and rx_dsp_reset.
> These are designated to reset the appropriate half of the signal
> processing chain in the FPGA.  This includes the corresponding FIFO.
> 
> In the past, they were also resetting the control registers (FR_*) that were
> also sort of associated with that half of the signal processing.  That
> was the behavior that was wrong.  Just because you wanted to reset the
> FIFO, didn't mean that you wanted to completely hose all of the rest
> of the configuration.
>  We also had a problem where one of the resets was
> resetting the register that contained the resets...  That was why
> initializing the Rx was hosing the Tx, or vice-versa (don't recall
> which way it went.)
Yes, I found this when I tried to use rx_dsp_reset for the synchronisation.
> 
> In the mean while, the registers that matter to me are getting zeroed
> from the host code.
Could you give a quick pointer to where you do this, (I am lazy)

>  In your case, you may still want to still reset
> your register with tx_dsp_reset and/or rx_dsp_reset.  Depends on your needs.
So, rx_dsp_reset is still sent?
On opening the usrp, or on starting the stream?

greetings,
Martin