Fewer than 8 bits per sample FPGA support

GNU Radio
1

So the attached patch changes to round-to-nearest-even.

After thinking a bit, this is wrong: the proper (re-)quantizer is
just the MSBs of the original sample—one wants a mid-riser
quantizer to use the even number of output levels symmetrically.

Revised patch attached (still untested).

Cheers,
Peter M.

2

On Thu, Mar 01, 2007 at 03:16:12AM -0800, Peter M. wrote:

So the attached patch changes to round-to-nearest-even.

After thinking a bit, this is wrong: the proper (re-)quantizer is
just the MSBs of the original sample—one wants a mid-riser
quantizer to use the even number of output levels symmetrically.

Revised patch attached (still untested).

Cheers,
Peter M.

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.

In the 1 bit case, I don’t think it matters if you just take the MSB,
but in
the other cases, I think you want to be able to adjust to account for
gain.

Eric

wire [11:0] rxfifolevel;

  •   store_next <= #1 4'd0;

  •  round_8 = in_val[15:8] + (in_val[15] & |in_val[7:0]);
  • top = ch_3;
  • top = 16’hFFFF;
  •   4'd5 : fifodata_16 = ch_4;

  •   {5'd16,4'd4} : fifodata = ch_3;

  •   {5'd2,4'd1} : fifodata = {ch_0[9:8],ch_1[9:8],ch_2[9:8],ch_3[9:8],ch_4[9:8],ch_5[9:8],ch_6[9:8],ch_7[9:8]};
  .q ( usbdata ),
3

Eric B. 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
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).

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). 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?

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.

Cheers,
Peter M.

4

Il giorno dom, 04/03/2007 alle 01.33 -0800, Peter M. ha scritto:

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.

Great! I’ll try this patch tomorrow. Can you send me the testbench. I
need a testbench for rx_buffer, too. I guess I’ll write it myself.

This is a very interesting feature for the FPGA.
Regards,

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]

5

Eric B. wrote:

The “short” version doesn’t touch the data. You’ll be able to unpack
it youself.

Strange, I had some problem with rx_cfile not seeming to respect
the width parameter. I’ll try it again.

That determines the minimum decimation rate required upstream
from the halfband (4).

I see. Maybe I’ll just forget the halfband too and just subsample by
2—the baseband filters on the MAX2118 may be enough for
reasonable antialiasing.

The test bench would be nice.

Attached.

Cheers,
Peter

6

Il giorno dom, 04/03/2007 alle 22.55 -0800, Peter M. ha scritto:

The test bench would be nice.

Attached.

I tried this test bench, but I guess it doesn’t work. Infact, I test the
bit_pack module obtaining a strange output file like the attached one.

Any suggestion from the list and/or Verilog Guru? :slight_smile:

I use iverilog on my Ubuntu 6.06 workstation.

Regards,

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]

7

On 3/6/07, Davide A. [email protected] wrote:

I tried this test bench, but I guess it doesn’t work. Infact, I test the
bit_pack module obtaining a strange output file like the attached one.

Any suggestion from the list and/or Verilog Guru? :slight_smile:

It looks like you possibly have multiple sources on your signals which
conflict with each other.

Only one process can assign to a wire.

I use iverilog on my Ubuntu 6.06 workstation.

Regards,

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]

Brian

8

On Sun, Mar 04, 2007 at 01:33:08AM -0800, Peter M. wrote:

Except for the 1-bit case, the user is going to have to do some AGC
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 M.

Thanks,
Eric

9

On 3/6/07, Brian P. [email protected] wrote:

It looks like you possibly have multiple sources on your signals which
conflict with each other.

Only one process can assign to a wire.

I take back my previous statement. A quick simulation of the main
module shows no contention.

Here is a screen shot using ModelSim.

Brian

10

On Tue, Mar 06, 2007 at 01:30:49PM +0100, Davide A. wrote:

Any suggestion from the list and/or Verilog Guru? :slight_smile:

I use iverilog on my Ubuntu 6.06 workstation.

Regards,

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]

Davide, and everyone else,

Do not post large messages to the list.

Davide, your message contained 1.3MB of basically content free junk,
and given our 800 members, has generated over 1GB of traffic on the
FSF T1, saturating it for over an hour.

As a result, there’s now a hard cap of 40KB on list postings.

If you’ve got big stuff to share, put it somewhere accessible and
then include a link in your posting.

Eric

11

Il giorno mar, 06/03/2007 alle 11.44 -0800, Eric B. ha scritto:

Davide, and everyone else,

Do not post large messages to the list.

Opsss… sorry! :frowning:

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]

12

On Tue, Mar 13, 2007 at 01:10:53PM +0100, Davide A. wrote:

Upload new firmware!
Using 4 bit sampling
format = 0x248
set_format = False
Using RX d’board A: DBS Rx
USB sample rate 4M

Format setting fail.

I suspect you’re getting caught by the sanity check in the host
library code.

Take a look at usrp_standard.cc, usrp_standard_rx::set_format and
remove the test for rx_format_is_valid.

I think the right way to work around this is to add another field to
the FPGA capability register that indicates whether or not the shifter
is implemented.

Eric

13

Il giorno mar, 13/03/2007 alle 08.08 -0700, Eric B. ha scritto:

I suspect you’re getting caught by the sanity check in the host
library code.

Take a look at usrp_standard.cc, usrp_standard_rx::set_format and
remove the test for rx_format_is_valid.

I added some width to rx_format_is_valid, but I receive a “floating
point exception”, as this:

root@rocker-duo:/home/rocker/Tesi/My Works/GNU Radio
Experiment/rx_cfile# ./usrp_rx_cfile.py -m -f 1.575G -w 1 -R A -d 16 -N
1000 -g 90 -s output.samples.1
Upload new firmware!
Using 1 bit sampling
format = 0x21f
set_format = True
Using RX d’board A: DBS Rx
USB sample rate 4M
Floating point exception

(same script attached in the mail above)

I think the right way to work around this is to add another field to
the FPGA capability register that indicates whether or not the shifter
is implemented.

I can do it. Please give me the right way…

Regards,

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]

14

Il giorno dom, 04/03/2007 alle 22.55 -0800, Peter M. ha scritto:

The “short” version doesn’t touch the data. You’ll be able to
unpack
it youself.

Strange, I had some problem with rx_cfile not seeming to respect
the width parameter. I’ll try it again.

Hi List,
I’m sorry to reuse this old topic, but I’m working on this feature.

I recompile FPGA firmware using Peter’ mod to obtain 1, 2, 4 and 8 bit
width sampling. I’m using this firmware and the script attached to try
it, but seems it doesn’t work. I don’t know if Peter (or someone else)
use correctly this mod.

I receive that:

root@rocker-duo:/home/rocker/Tesi/My Works/GNU Radio
Experiment/rx_cfile# ./usrp_rx_cfile.py -m -f 1.575G -w 4 -R A -d 16 -N
1000 output.samples.4
Upload new firmware!
Using 4 bit sampling
format = 0x248
set_format = False
Using RX d’board A: DBS Rx
USB sample rate 4M

Format setting fail.

New usrp_rx_cfile.py is attached.
Regards,

Davide A.

web: http://www.davideanastasia.com/
email: [email protected]