> 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 Monta
on 01.03.2007 12:17
on 01.03.2007 16:43
On Thu, Mar 01, 2007 at 03:16:12AM -0800, Peter Monta 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 Monta 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 ),
on 04.03.2007 10:34
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 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 Monta
on 04.03.2007 12:45
Il giorno dom, 04/03/2007 alle 01.33 -0800, Peter Monta 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 Anastasia web: http://www.davideanastasia.com/ email: s242248@studenti.ing.unipi.it
on 04.03.2007 18:59
On Sun, Mar 04, 2007 at 01:33:08AM -0800, Peter Monta 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 Monta Thanks, Eric
on 05.03.2007 07:56
Eric Blossom 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
on 06.03.2007 17:27
Il giorno dom, 04/03/2007 alle 22.55 -0800, Peter Monta 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? :) I use iverilog on my Ubuntu 6.06 workstation. Regards, -- Davide Anastasia web: http://www.davideanastasia.com/ email: s242248@studenti.ing.unipi.it
on 06.03.2007 17:46
On 3/6/07, Davide Anastasia <s242248@studenti.ing.unipi.it> 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? :) 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 Anastasia > > web: http://www.davideanastasia.com/ > email: s242248@studenti.ing.unipi.it Brian
on 06.03.2007 18:00
On 3/6/07, Brian Padalino <bpadalino@gmail.com> 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
on 06.03.2007 20:42
On Tue, Mar 06, 2007 at 01:30:49PM +0100, Davide Anastasia wrote: > Any suggestion from the list and/or Verilog Guru? :) > > I use iverilog on my Ubuntu 6.06 workstation. > > Regards, > -- > Davide Anastasia > > web: http://www.davideanastasia.com/ > email: s242248@studenti.ing.unipi.it 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
on 06.03.2007 21:13
Il giorno mar, 06/03/2007 alle 11.44 -0800, Eric Blossom ha scritto: > Davide, and everyone else, > > Do not post large messages to the list. Opsss... sorry! :( -- Davide Anastasia web: http://www.davideanastasia.com/ email: s242248@studenti.ing.unipi.it
on 13.03.2007 13:12
Il giorno dom, 04/03/2007 alle 22.55 -0800, Peter Monta 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 Anastasia web: http://www.davideanastasia.com/ email: s242248@studenti.ing.unipi.it
on 13.03.2007 16:04
On Tue, Mar 13, 2007 at 01:10:53PM +0100, Davide Anastasia 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
on 14.03.2007 10:20
Il giorno mar, 13/03/2007 alle 08.08 -0700, Eric Blossom 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 Anastasia web: http://www.davideanastasia.com/ email: s242248@studenti.ing.unipi.it