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: The Pin 153 of EP1C12 of USRP (Matt Ettus)
2. Re: Problems with Tx-MIMO (Tor Andre Myrvoll)
3. Re: multiplier block in fpga code (Florian Schlembach)
4. leds are off (Marco)
5. Thread AssertionError and Libc++abi.dylib on Mac
Transmissions (David Greene)
----------------------------------------------------------------------
Message: 1
Date: Sun, 13 Jan 2013 12:00:51 -0800
From: Matt Ettus <[email protected]>
To: rzbaaa <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] The Pin 153 of EP1C12 of USRP
Message-ID:
<CAN=1kn8+h75xbjjpgvgajdxh6pvy9u2z_gkbxzpym9tbr9b...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
It is used as an input to the FPGA. The FX2 is enabling the SPI slave in
the FPGA.
Matt
On Sun, Jan 13, 2013 at 8:12 AM, rzbaaa <[email protected]> wrote:
> The pin-153 of EP1C12 is a dedicated global clock input and does not have
> the IO function. But I found it was used as an SPI Enable signal (SEN_FPGA)
> in the USRP. why? Could it cause any problem?
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130113/e9bdcb47/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 14 Jan 2013 11:49:23 +0100
From: Tor Andre Myrvoll <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problems with Tx-MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
13. jan. 2013 kl. 02:04 skrev Josh Blum <[email protected]>:
>
> I am thinking that it may be the case: the socket constructor from boost
> ASIO sets O_NONBLOCK. Can you check if O_NONBLOCK is set in the mask
> ::fcntl(sock_fd, F_GETFL, 0)?
I inserted the following code into class udp_zero_copy_asio_impl : public
udp_zero_copy:
//create, open, and connect the socket
_socket = socket_sptr(new asio::ip::udp::socket(_io_service));
_socket->open(asio::ip::udp::v4());
_socket->connect(receiver_endpoint);
_sock_fd = _socket->native();
// Inserted code here: Check whether the socket is non-blocking
int sstate = ::fcntl(_sock_fd, F_GETFL, 0);
std::cout << "Socket state:" << sstate << std::endl;
if (sstate & O_NONBLOCK){
std::cout << "Socket state: Non-blocking io on" <<
std::endl;
}
The output is:
[? snip ?]
Creating the usrp device with: addr0=192.168.10.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Socket state:2
Socket state:2
Socket state:2
Socket state:2
Using Device: Single USRP:
[ ... snip ?]
So, as far as I can tell the O_NONBLOCK is not set.
--
- Tor
------------------------------
Message: 3
Date: Mon, 14 Jan 2013 12:00:14 +0100
From: Florian Schlembach <[email protected]>
To: [email protected]
Cc: [email protected], Arun
Pillai <[email protected]>
Subject: Re: [USRP-users] multiplier block in fpga code
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I am actually wondering what the real timing difference is between the
registered version MULT18x18S and the pure combinatorial MULT18x18.
Squaring a value, ISim shows me 1 clock cycle + 0.1ns for the MULT18x18S
and *zero* for the combinatorial MULT18x18 (what isn't realistic in
hardware at all). See the screenshots below (both multiplications start
at 135ns)
MULT18x18S: http://upload-pictures.de/bild.php/23077,screenshotASGUP.png
MULT18x18: http://upload-pictures.de/bild.php/23079,screenshot1XA2HE.png
If I now consider the pipeline code in sdr_lib/ddc_chain.v (lines
155-168, http://pastebin.com/C1nmN4QZ) a wrong result would be written
into prod_reg_i because the actual result of the multiplier is correct
at the clock cycle right after when strobe_mult is high.
Is the simulated delay of MULT18x18S correct at all? Are there timing
differences between MULT18x18? Xilinx document XAPP467 doesn't reveal
the timing difference between both.
On 12/06/2011 11:57 PM, Ian Buckley wrote:
> You've misunderstood the Xilinx docs in this case, the MULT18x18S macro has,
> as Matt said, 1 internal pipeline stage as standard, and the MULT18X18 macro
> is pure combinatorial. I recommend you read XAPP467 in detail.
>
> Use of the * operator to imply a multiplier in verilog is possible, but the
> macro method offers tighter control of the implementation.
>
>
> On Dec 6, 2011, at 2:24 PM, Arun Pillai wrote:
>
>> Thanks. Part of the reason I was confused is that the user guides for the
>> spartan 3 and spartan 3A indicate higher delays (3-4 cycles).
>>
>> Why do the mults have a 1 cycle delay here? (Is that an implicit behavior of
>> the * operator in verilog as implemented by Xilinx)?
>>
>> Is there somewhere in the synth/map/PAR routine log that I can see this?
>>
>> Otherwise, how would I be able to infer the delay of this block?
>>
>> On 12/06/2011 05:16 PM, Matt Ettus wrote:
>>>
>>> The mult18s have a 1 cycle delay.
>>>
>>> Matt
>>>
>>> On Tue, Dec 6, 2011 at 12:31 PM, Arun Pillai <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> What is the delay of the mult 18x18s block? I can't find it
>>> explicitly from the code/models. Is there some place I should be
>>> looking? Or is there some place to easily infer it from the code
>>> (looking at pipectrl in dspengine_16to8.v, it seems that stb_mult is
>>> active for one cycle, which means that the multiplier takes one
>>> cycle). But I am not fully sure - can somebody confirm?
>>>
>>> I am implementing on USRP N210 if that matters, although the code
>>> delays in the sdr block don't seem sensitive to which USRP it is
>>> running on.
>>>
>>> Thanks.
>>>
>>>
>>> _________________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/__mailman/listinfo/usrp-users___lists.ettus.com
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Mon, 14 Jan 2013 13:24:23 +0000
From: Marco <[email protected]>
To: [email protected]
Subject: [USRP-users] leds are off
Message-ID:
<cakoaurxnkklcbwjw+ct_wsna4_v4bylhk7_aqjye+py3nse...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I have just received a usrp n210 and wbx board. I plugged the wbx into the
usrp, connected the rf cable and turned the system on, but the debug leds
are off. Not even the ethernet led are on. The fan is spinning. What might
this be cause?
Cheers,
Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130114/7cab439e/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 14 Jan 2013 11:47:35 -0500
From: David Greene <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Thread AssertionError and Libc++abi.dylib on Mac
Transmissions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hey Folks,
I've installed the latest version of GNURadio (3.6.3) using MacPorts on a
fresh Macbook Pro running 10.8.2 using,
sudo port install gnuradio +full configure.compiler=llvm-gcc-4.2
Installation was flawless and I can receive using my USRP N210 just fine.
The problem comes when I try to transmit on my USRP. I can't pinpoint what's
causing it, but I get the following errors below when I try to transmit
through UHD. No changes to the included example (uhd_const_wave.grc) except
the IP address. Any help is appreciated, I've already tried several fresh
installs using CLANG and/or LLVM-GCC-4.2 and boost is at version 1.51.
Rebooting the USRP and/or the Mac has no effect.
Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.11.00); Boost_105100; UHD_003.005.000-0-unknown
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Ulibc++abi.dylib: terminate called without an active exception
>>> Done
and the next...
Mac OS; GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.11.00); Boost_105100; UHD_003.005.000-0-unknown
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Uthread[thread-per-block[1]: <gr_block gr uhd usrp sink (1)>]:
AssertionError: ::send(_sock_fd, (const char *)_mem, size(), 0) ==
ssize_t(size())
in virtual void udp_zero_copy_asio_msb::release()
at
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
.org_release_tarballs_ports_science_uhd/uhd/work/UHD-Mirror-release_003_005_
000/host/lib/transport/udp_zero_copy.cpp:115
S
>>> Done
This looks related to Tor Andre Myrvoll's post, however I'm using a single
N210:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2013-January/005
955.html
Regards,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130114/520f3433/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 29, Issue 14
******************************************
