Re: [Discuss-gnuradio] Fewer than 8 bits per sample FPGA support

[Eric Blossom]

On Sun, Mar 04, 2007 at 01:33:08AM -0800, Peter Monta wrote:
> Eric Blossom wrote:
> 
> >
> >I think that you're really going to want a configurable barrel
> >shifter -- to get the bits where you want them -- then pick them off with
> >round_X or round_X_nearest_even.
> >  
> 
> OK, the attached rx_buffer.v includes a barrel shifter in bit_pack.v;
> I see this was anticipated with the bitwidth and bitshift parameters.
> Except for the 1-bit case, the user is going to have to do some AGC
> anyway, so the exact position of the bits is not too critical so long as
> it's sufficiently out of the noise and sufficient analog gain is available,
> but it doesn't hurt to have full support, I guess.
> 
> I've run the modified FPGA and verified that the USB data rates
> are as expected using test_usrp_standard_rx and various
> widths (1, 2, 4, 8, 16).  A couple of snags:  first, the sanity
> check in rx_format_is_valid() (lib/usrp_standard.cc) has to go;
> second, there seems to be no "raw" support in gr-usrp:  I'd
> prefer that rx_cfile.py just dump exactly what comes over the
> USB bus instead of converting to shorts or floats.

The "short" version doesn't touch the data.  You'll be able to unpack
it youself.  "short"'s probably the wrong name for the interface.  We
should revisit the name.


> The test_usrp_standard_rx app comes close to what I want, but
> it doesn't seem to have daughterboard intelligence, so I can't
> set gain properly.  Finally, it would be good to have support
> for a decimation ratio of 2 (just the halfband filter) and 1
> (no filtering).

Once the daughterboard code is ported to C++, we can back-port it into
test_usrp_standard_{tx,rx}.

Because of the lack of h/w multipliers, and our desire to minimize
resource usage in the halfband filter, it's implemented with a single
synthesized multiplier, and it takes 8 clocks to generate each output
from the 31-tap half-band filter (It's symmetric, and the center tap
is one).  That determines the minimum decimation rate required upstream
from the halfband (4).

If you're willing to remove some stuff from the FPGA (leaving e.g,
0 tx, 2 rx), you might have room to reimplment the half-band.

> I'd eventually like to dump to disk 2-bit samples at 32 Ms/s complex
> using two dbs_rx cards, which should just fit within the 32 MByte/sec
> USB limit.  This is for a dual-frequency GPS application (L1/L2C at first,
> but the USRP provides enough bandwidth for the wider P/Y-code signals
> as well).

Should fit.

> I'm hoping the dbs_rx's close-in phase noise is low enough
> to allow a small carrier-loop bandwidth---are there any measurements
> I can look at?

Check with Matt.

> Please let me know if anything else is needed for the patch.
> There's a testbench for bit_pack.v I can send along if you like.
> One possible issue is synchronization, to make sure that the
> channels are properly distributed within the 16 bits after
> changing width.

The test bench would be nice.

> Cheers,
> Peter Monta

Thanks,
Eric