Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Write registers on USRP2 FPGA (Vladimir Negnevitsky)
2. USRP1 Benchmarking/UHD performance issues (Matthew Robert)
3. Re: USRP1 Benchmarking/UHD performance issues (Josh Blum)
4. Re: USRP1 Benchmarking/UHD performance issues (Matthew Robert)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Mar 2011 10:14:34 +1100
From: Vladimir Negnevitsky <[email protected]>
To: Eduardo Lloret Fuentes <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Write registers on USRP2 FPGA
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
I've been working on something similar; on my design I just needed to
bit-bash a few custom modules, so I instantiated some setting_reg
Verilog modules (you can see examples of their use in u2_core.v or
dsp_core_rx.v; I hooked mine up to the settings_bus_crossclock since
my datapath always runs at 100 MHz). I added definitions in a few
places (firmware and verilog) to let the ZPU know about the new
register locations, and then just added a const struct for my custom
registers in the memory map - this was better for me than modifying
the host side of things because it allows me to set parameters to my
modules upon USRP2 boot-up. It is pretty straightforward to extend the
ZPU memory map. Let me know if you want more details - I don't know if
your modules need i2c or bit-bashing, so this method may not work for
you.
I also modified the UHD slightly, adding a few custom methods into
mboard_impl.cpp that essentially act as wrappers for peek32 and poke32
with my register addresses conveniently defined. Since I'm doing
everything in C/C++ I didn't worry about the Python side of things.
May I ask what kind of project you're working on?
Regards,
Vlad
On 18 March 2011 00:10, Eduardo Lloret Fuentes <[email protected]> wrote:
> Hello!
>
> I was successful trying to add my own FPGA code into the original FPGA
> project. I just added a module into the u2_rev3.v and bypass the DSP
> pipeline. So, all the original FPGA code is there and the firmware is
> running. Now, I would like to modify some registers of my own FPGA design.
> Maybe using the I2C or the SPI standards already implemented via ethernet.
>
> I read that for the USRP there is a command, "usrper i2c_write i2c_addr
> <hex-string>" that can be used to modify some existing registers.
>
> Is there anything similar for USRP2?
>
> Is there any other way to modify an existing register (from the original
> code) or a custom register (from my own code) via ethernet?
>
> I would like to clarify that I am using the gnuradio master branch but if
> there is a way to write these registers using the UHD driver it is also
> quite interesting for me.
>
> A lot of thanks in advance.
>
> Eduardo.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 2
Date: Fri, 18 Mar 2011 16:37:54 +1100
From: Matthew Robert <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP1 Benchmarking/UHD performance issues
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi list,
I benchmarked my USRP1 and compared back to back with the legacy benchmark
application. For some reason the legacy benchmarker works all the way up to
32MB/sec wheres the UHD runs into performance issues well before (it becomes
apparent at decimation 16)
Attached are the outputs - Is anyone else experiencing this?
Cheers,
Matt
*@*l~ $ src/gnuradio/gnuradio-examples/python/usrp/usrp_benchmark_usb.py
Testing 2MB/sec... uUuUusb_throughput = 2M
ntotal = 1000000
nright = 999510
runlength = 999510
delta = 490
OK
Testing 4MB/sec... uUuUusb_throughput = 4M
ntotal = 2000000
nright = 1997113
runlength = 1997113
delta = 2887
OK
Testing 8MB/sec... uUusb_throughput = 8M
ntotal = 4000000
nright = 3998474
runlength = 3998474
delta = 1526
OK
Testing 16MB/sec... uUusb_throughput = 16M
ntotal = 8000000
nright = 7993059
runlength = 7993059
delta = 6941
OK
Testing 32MB/sec... uUusb_throughput = 32M
ntotal = 16000000
nright = 15993120
runlength = 15993120
delta = 6880
OK
Max USB/USRP throughput = 32MB/sec
*@*l~ $ sudo src/uhd/host/build/examples/benchmark_rx_rate
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.20110315195256.3a1ad3f
Creating the usrp device with: ...
Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
Using Device: Single USRP:
Device: usrp1 device
Mboard 0: usrp1 mboard - 4b0adcb8
RX DSP 0: usrp1 ddc 2X + hb
RX Channel: 0
RX Dboard: usrp1 dboard (rx unit) - A
RX Subdev: WBX (0x0053)
TX DSP 0: usrp1 duc 2X
TX Channel: 0
TX Dboard: usrp1 dboard (tx unit) - A
TX Subdev: WBX (0x0052)
Testing receive rate 0.500000 Msps (10.000000 second run)
O
Received packets: 1221
Received samples: 5001216
Lost samples: 19326
Lost packets: 5 (approximate)
Sustained receive rate: 0.498075 Msps
Testing receive rate 1.000000 Msps (10.000000 second run)
Received packets: 2442
Received samples: 10002432
Lost samples: 54770
Lost packets: 13 (approximate)
Sustained receive rate: 0.994554 Msps
Testing receive rate 2.000000 Msps (10.000000 second run)
Received packets: 4883
Received samples: 20000768
Lost samples: 301622
Lost packets: 74 (approximate)
Sustained receive rate: 1.970287 Msps
Testing receive rate 4.000000 Msps (10.000000 second run)
Received packets: 9766
Received samples: 40001536
Lost samples: 844243
Lost packets: 206 (approximate)
Sustained receive rate: 3.917324 Msps
Testing receive rate 8.000000 Msps (10.000000 second run)
Received packets: 19531
Received samples: 79998976
Lost samples: 2449747
Lost packets: 598 (approximate)
Sustained receive rate: 7.762301 Msps
Testing receive rate 16.000000 Msps (10.000000 second run)
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Received packets: 19912
Received samples: 81559552
Lost samples: 78528992
Lost packets: 19172 (approximate)
Sustained receive rate: 8.151444 Msps
Decimation must be even and between 4 and 256
Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 32.000000 MSps
Actual sample rate: 16.000000 MSps
Done!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110318/b8a5e27e/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 17 Mar 2011 22:49:10 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP1 Benchmarking/UHD performance issues
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 03/17/2011 10:37 PM, Matthew Robert wrote:
> Hi list,
>
> I benchmarked my USRP1 and compared back to back with the legacy benchmark
> application. For some reason the legacy benchmarker works all the way up to
> 32MB/sec wheres the UHD runs into performance issues well before (it becomes
> apparent at decimation 16)
>
> Attached are the outputs - Is anyone else experiencing this?
> Testing receive rate 16.000000 Msps (10.000000 second run)
> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
> Received packets: 19912
> Received samples: 81559552
> Lost samples: 78528992
> Lost packets: 19172 (approximate)
> Sustained receive rate: 8.151444 Msps
>
>
Unfortunately for the USRP1, the benchmark app uses the timestamps to
calculate sample loss. And because USRP1 has emulated time (vs the other
products), the results you see from benchmark are wildly inaccurate.
http://www.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features
-Josh
------------------------------
Message: 4
Date: Fri, 18 Mar 2011 18:08:05 +1100
From: Matthew Robert <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP1 Benchmarking/UHD performance issues
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi All,
My apologies- I wasn't reading the values right - UHD is performing OK up to
8,000,000 samples/sec which is decimation 8. Everything seems ok!
Cheers,
Matt
On Fri, Mar 18, 2011 at 4:37 PM, Matthew Robert <[email protected]>wrote:
> Hi list,
>
> I benchmarked my USRP1 and compared back to back with the legacy benchmark
> application. For some reason the legacy benchmarker works all the way up to
> 32MB/sec wheres the UHD runs into performance issues well before (it becomes
> apparent at decimation 16)
>
> Attached are the outputs - Is anyone else experiencing this?
>
> Cheers,
> Matt
>
>
> *@*l~ $ src/gnuradio/gnuradio-examples/python/usrp/usrp_benchmark_usb.py
> Testing 2MB/sec... uUuUusb_throughput = 2M
> ntotal = 1000000
> nright = 999510
> runlength = 999510
> delta = 490
> OK
> Testing 4MB/sec... uUuUusb_throughput = 4M
> ntotal = 2000000
> nright = 1997113
> runlength = 1997113
> delta = 2887
> OK
> Testing 8MB/sec... uUusb_throughput = 8M
> ntotal = 4000000
> nright = 3998474
> runlength = 3998474
> delta = 1526
> OK
> Testing 16MB/sec... uUusb_throughput = 16M
> ntotal = 8000000
> nright = 7993059
> runlength = 7993059
> delta = 6941
> OK
> Testing 32MB/sec... uUusb_throughput = 32M
> ntotal = 16000000
> nright = 15993120
> runlength = 15993120
> delta = 6880
> OK
> Max USB/USRP throughput = 32MB/sec
> *@*l~ $ sudo src/uhd/host/build/examples/benchmark_rx_rate
> linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.20110315195256.3a1ad3f
>
>
> Creating the usrp device with: ...
> Loading firmware image: /usr/share/uhd/images/usrp1_fw.ihx... done
> Using Device: Single USRP:
> Device: usrp1 device
> Mboard 0: usrp1 mboard - 4b0adcb8
> RX DSP 0: usrp1 ddc 2X + hb
> RX Channel: 0
> RX Dboard: usrp1 dboard (rx unit) - A
> RX Subdev: WBX (0x0053)
> TX DSP 0: usrp1 duc 2X
> TX Channel: 0
> TX Dboard: usrp1 dboard (tx unit) - A
> TX Subdev: WBX (0x0052)
>
> Testing receive rate 0.500000 Msps (10.000000 second run)
> O
> Received packets: 1221
> Received samples: 5001216
> Lost samples: 19326
> Lost packets: 5 (approximate)
> Sustained receive rate: 0.498075 Msps
>
>
> Testing receive rate 1.000000 Msps (10.000000 second run)
>
> Received packets: 2442
> Received samples: 10002432
> Lost samples: 54770
> Lost packets: 13 (approximate)
> Sustained receive rate: 0.994554 Msps
>
>
> Testing receive rate 2.000000 Msps (10.000000 second run)
>
> Received packets: 4883
> Received samples: 20000768
> Lost samples: 301622
> Lost packets: 74 (approximate)
> Sustained receive rate: 1.970287 Msps
>
>
> Testing receive rate 4.000000 Msps (10.000000 second run)
>
> Received packets: 9766
> Received samples: 40001536
> Lost samples: 844243
> Lost packets: 206 (approximate)
> Sustained receive rate: 3.917324 Msps
>
>
> Testing receive rate 8.000000 Msps (10.000000 second run)
>
> Received packets: 19531
> Received samples: 79998976
> Lost samples: 2449747
> Lost packets: 598 (approximate)
> Sustained receive rate: 7.762301 Msps
>
>
> Testing receive rate 16.000000 Msps (10.000000 second run)
> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
> Received packets: 19912
> Received samples: 81559552
> Lost samples: 78528992
> Lost packets: 19172 (approximate)
> Sustained receive rate: 8.151444 Msps
>
>
> Decimation must be even and between 4 and 256
>
> Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 32.000000 MSps
> Actual sample rate: 16.000000 MSps
>
> Done!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110318/c1a97658/attachment.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 7, Issue 30
*****************************************
