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. UHD support to Ubuntu 17.04 (Carlos Moriana Varo)
2. Re: rfnoc-modtool cores (Jason Matusiak)
3. Re: E310 Rfnoc clocking guidelines/ performance issues
(Samuel Prager)
4. Crimper tool for E310 GPIO connector (Daniel May)
5. Re: rfnoc-modtool cores (EJ Kreinar)
6. Re: E310 transmitting signal using tx_samples_from_file
(Kyeong Su Shin)
7. Re: Exception raised when trying to read FPGA time
(Felipe Augusto Pereira de Figueiredo)
8. Re: Crimper tool for E310 GPIO connector (Sylvain Munaut)
9. Re: Netgear 10GB switch XS728T (Kevin Krieger)
10. Re: writing a register in FPGA from host in X310 (device 3 i
guess) (Samuel Berhanu)
11. Re: writing a register in FPGA from host in X310 (device 3 i
guess) (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Jun 2017 16:02:52 +0000
From: Carlos Moriana Varo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD support to Ubuntu 17.04
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I am trying to install the UHD drivers in Ubuntu 17.04, but I get problems
adding the ppa repository since it seems that the version for this distribution
has not been released yet. Is there any idea of when this will be compatible?
Otherwise I would be forced to downgrade to 16.04...
P Please consider the environment before printing this e-mail.
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170614/7ed69060/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 14 Jun 2017 14:08:38 -0400
From: Jason Matusiak <[email protected]>
To: EJ Kreinar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
EJ,
I am creating a new RFNoC repo and thought I would go through your write
up and see if I can find anything that we missed while you and I were
working offline. The first thing I wondered was, in the
Makefile.OOT.inc, can I have more than one OOT_DIR? I have one in there
right now for my current blocks, but I am not sure how to point to a
different folder without screwing your setup up.
~Jason
On 05/23/2017 10:04 PM, EJ Kreinar wrote:
> Hi Jason and others,
>
> As a follow up, I put together an rfnoc OOT repo that uses Makefiles
> to build Vivado IP and HLS IP: https://github.com/ejk43/rfnoc-ootexample
>
> The simulations should run successfully when uhd-fpga is set up
> correctly (see readme), and also should build the OOT noc_blocks into
> an FPGA image using "make E310_RFNOC" etc etc.
>
> Hope this helps,
> EJ
>
> On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar <[email protected]
> <mailto:[email protected]>> wrote:
>
> Jason,
>
> Sure, I'd say just clone my fpga repo and apply the patch for
> now. Quick instructions:
>
> 1. In your uhd-fpga repo: `git remote add ejk
> https://github.com/ejk43/fpga.git` <https://github.com/ejk43/fpga.git>
> a. This now sets up a remote named "ejk" which points to my fork
> 2. Then: `git fetch ejk new_oot_includes`
> 3. Then you can either checkout this branch (if you have no other
> changes on your uhd-fpga repo), or cherry-pick the commits from
> the new_oot_includes branch.
>
>
> In lieu of an example OOT repo, here's how I set up my "rfnoc"
> folder structure in the OOT repo:
>
> rfnoc:
> + Makefile.inc
> + blocks
> + testbenches
> + fpga-src
> + Makefile.inc
>
> + noc_block_testblock.v
>
> + ip
> + Makefile.inc
> + my_ip
> + my_ip.xci
> + Makefile.inc
>
>
>
> Here's an example top-level Makefile.inc:
>
> RFNOC_MYTEST_DIR := $(OOT_DIR)
> include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
> include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
>
>
>
> Then the fpga-src Makefile.inc:
>
> RFNOC_OOT_SRCS += $(addprefix $(RFNOC_MYTEST_DIR)/fpga-src/, \
> noc_block_testblock.v \
> )
>
>
>
> Then the IP Makefile.inc (modeled after the Makefile.inc in the
> uhd-fpga/usrp3/lib/ip:
>
> include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
>
> LIB_MYTEST_IP_XCI_SRCS = \
> $(LIB_IP_MY_IP_SRCS)
>
> LIB_MYTEST_IP_SYNTH_OUTPUTS = \
> $(LIB_IP_MY_IP_OUTS)
>
> LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
>
>
>
> And finally, the Makefile.inc inside the my_ip directory (modeled
> after the lib/ip/xxx Makefile.inc):
>
> include $(TOOLS_DIR)/make/viv_ip_builder.mak
>
> LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
>
> LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
> my_ip.xci.out \
> synth/my_ip.vhd \
> )
>
> $(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) :
> $(LIB_IP_DIR)/my_ip/my_ip.xci
> $(call
>
> BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_BUILD_DIR),0)
>
>
>
> It's also possible to rejigger the testbench makefiles to build
> the OOT IP for your testbench.
>
> Again, I should pull this into an example OOT repo sometime soon,
> which would make it a bit easier to have an example. Let me know
> if you hit any problems.
>
> EJ
>
> On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> EJ, that looks exactly like what I need to do. Is there a way
> for me to patch in your changes so I can try to use them while
> we wait for Ettus to (dis)approve your PR?
>
> Thanks!
> ~Jason
>
>
>
> On 05/18/2017 04:11 PM, EJ Kreinar wrote:
>> Hi Jason,
>>
>> I currently have a PR in to the fpga repo
>> (https://github.com/EttusResearch/fpga/pull/12
>> <https://github.com/EttusResearch/fpga/pull/12>) that adds
>> support for linking Makefile.inc files in OOT repos. Your OOT
>> Makefile can then build the Xilinx IP and append it to your
>> build as needed. I've been using this approach for some time
>> now with success for both Xilinx IP and HLS designs.
>>
>> I have an action to provide a sample "dummy" OOT repo with
>> the correct Makefiles-- but I havent gotten to it yet,
>> unfortunately-- Was waiting for confirmation if this approach
>> will be supported in-tree in the future. I could put
>> something together soon though if this would help.
>>
>> I'd also be interested in other good solutions, if anyone has
>> an alternate approach :)
>>
>> EJ
>>
>> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> I wanted to create an RFNoC block that utilized some
>> Xilinx cores. Where do I need to put these cores in the
>> rfnoc-modtool project created directory structure, and
>> how do I go about tying that into the Vivado GUI so I can
>> build them up (just use the GUI=1 CL argument and do the
>> save-as project approach?)?
>>
>> _______________________________________________
>> 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>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170614/e163ae27/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 14 Jun 2017 11:24:43 -0700
From: Samuel Prager <[email protected]>
To: "=?utf-8?Q?Prager=2C_Samuel_M_(334E)?="
<[email protected]>, Jonathon Pendlum
<[email protected]>, Ryan Marlow via USRP-users
<[email protected]>, Sam Prager
<[email protected]>
Subject: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance
issues
Message-ID: <57563458-2254-4c83-ad23-a21ac71c2acf@Spark>
Content-Type: text/plain; charset="utf-8"
Hello,
Just replying to see if there are any updates on this issue.
Thanks,
Sam
On Jun 6, 2017, 5:22 PM -0700, Prager, Samuel M (334E)
<[email protected]>, wrote:
>
> Hi Jonathon,
>
>
>
>
>
> Thanks for the response.
>
>
>
>
>
> Issue 1)
>
>
> When you receive a pulse, are you only calling recv() or are you doing
> anything else? This looks like UHD expected the response packet to have a
> sequence number of 0, but the radio replied with a sequence number of 890.
> This could happen if the radio block got reset. You said this code works fine
> when running on the X300 though right?
>
>
>
>
>
>
>
>
> Yes, I am only calling recv() when receiving a pulse. The only time I call
> usrp->clear() is when the blocks are initially connected. Yes, this code
> works on the X300.
>
>
>
>
>
> Additionally, if I do not attempt any settings reg reads, but instead
> immediately call recv() a second time, I receive a few hundred samples before
> getting a timeout due to drops. For each successive pulse, I am using the
> same rx_stream object (persistent and created in the program initialization
> with rx_stream = _usrp->get_rx_stream(stream_args); ). I assume that this
> isn?t an issue.
>
>
>
>
>
> Issue 2)
>
>
> Can you do an external loopback with something simple like a tone? The AD9361
> is a fairly complicated device and starting off with a simpler test case
> might give us a better clue.
>
>
>
>
>
> I will try a simple tone if this problem persists after my first issue is
> resolved. In the mean-time, do you have any estimate of what the signal delay
> time is for a signal to propagate through the rx and tx frontend? I know that
> this is complicated and will change with freq, bw, etc but if you have a
> ballpark estimate, that would be helpful. On the x300, I recall the signal
> propagation delay through external loopback was ~512 ticks @ 200 mhz.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Samuel Prager [mailto:[email protected]]
> Sent: Tuesday, June 06, 2017 9:58 AM
> To: Prager, Samuel M (334E) <[email protected]>
> Subject: Fwd: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance
> issues
>
>
>
>
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Jonathon Pendlum <[email protected]
> (mailto:[email protected])>
> Date: May 18, 2017, 10:28 AM -0700
> To: Samuel Prager <[email protected] (mailto:[email protected])>
> Cc: Ryan Marlow via USRP-users <[email protected]
> (mailto:[email protected])>
> Subject: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance issues
>
>
>
>
> >
> > Hi Sam,
> >
> >
> >
> >
> >
> >
> > >
> > > Issue 1)
> > >
> > > When I run the application, rfnoc appears to initialize correctly and I
> > > can sr_read sr_write. However, after receiving one pulse (4096 samples),
> > > I begin to see errors similar to:
> > >
> > > Error: EnvironmentError: IOError: 0/Radio_0 user_reg_read64() failed:
> > > EnvironmentError: IOError: [0/Radio_0] sr_read64() failed:
> > > EnvironmentError: IOError: Block ctrl (CE_00_Port_10) packet parse error
> > > - EnvironmentError: IOError: Expected packet index: 0 Received index: 890
> > >
> > > If I do not read/write any FPGA registers before sending another pulse, I
> > > see timeouts after a few thousand samples have been received.
> > >
> > > I have tried changing the rate (as low as 1 MHz) and increasing the wait
> > > time between pulses ? neither has any effect. After the first pulse, the
> > > usrp starts to freeze up. I have also tried adding a FIFO block between
> > > the Radio RX and host with no improvement.
> > >
> >
> >
> >
> >
> >
> >
> > When you receive a pulse, are you only calling recv() or are you doing
> > anything else? This looks like UHD expected the response packet to have a
> > sequence number of 0, but the radio replied with a sequence number of 890.
> > This could happen if the radio block got reset. You said this code works
> > fine when running on the X300 though right?
> >
> >
> >
> >
> >
> >
> > >
> > > Issue 2)
> > >
> > > The data I am receiving in the analog loopback configuration is
> > > essentially junk. However, if I set the ?loopback? register in the
> > > radio_core (SR_LOOPBACK = 132), I receive the exact samples that are
> > > being send by the AWG with the correct time coherence, etc. So the tx
> > > samples going out of the radio_core appear to be correct.
> > >
> >
> >
> >
> >
> >
> >
> > Can you do an external loopback with something simple like a tone? The
> > AD9361 is a fairly complicated device and starting off with a simpler test
> > case might give us a better clue.
> >
> >
> >
> >
> >
> >
> > >
> > > Questions:
> > >
> > > Are there additional uhd calls needed to setup the E310 RF frontend
> > > beyond what is necessary for the X300?
> > >
> >
> >
> >
> >
> >
> >
> > Not that I'm aware of.
> >
> >
> >
> >
> >
> >
> > >
> > > I am sort of scratching my head here because I have been using noc_block
> > > on the X300 successfully for a while and the E310 fpga image I built met
> > > timing, etc.
> > >
> > > Are there any obvious culprits for this sort of behavior? My noc_block
> > > uses a timekeeper (and the sync_in and pps signals on the X300). On the
> > > E310, however there is no sync_in signal and the pps generation is
> > > different. Could this be the source of the issues that I am seeing?
> > >
> >
> >
> >
> >
> >
> >
> > I wouldn't completely rule it out, but I doubt it. Have you tried sending
> > the pulse immediately / ignoring the timekeeper?
> >
> >
> >
> >
> >
> >
> > >
> > > What is the proper way to set the gpsdo as the time and clock source for
> > > a device3 based usrp? Is there anything analogous to what is used for
> > > multi_usrp in the sync_to_gps.cpp example?
> > >
> >
> >
> >
> >
> >
> >
> > I believe we expose what you need in the radio block controller
> > (radio_ctrl_impl.cpp). Take a look at
> > https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp
> >
> > (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_rfnoc-2Ddevel_host_examples_rfnoc-5Frx-5Fto-5Ffile.cpp&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=IWOx0Sf14MtR13I1-3EQGbqNozqYYSVIBwXsk5J5trE&s=2v9R6qJ7n2WxD0Iebu7ojXhkAS12red_2SKJaGwsfnQ&e=)
> >
> >
> >
> >
> >
> >
> > >
> > > And lastly, is it possible to use a dma_fifo block directly on the E310?
> > > Or does custom firmware have to be written in order to use the dram
> > > memory on board?
> > >
> >
> >
> >
> >
> >
> >
> > The DmaFIFO block would be compatible, but you need to generate a MIG with
> > an AXI4 interface. Luckily, we already have IP for the MIG that is built
> > when you run the 'E310_dram_test' make target. You could try starting with
> > that.
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170614/f4dafadb/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 14 Jun 2017 17:02:44 -0500
From: Daniel May <[email protected]>
To: [email protected]
Subject: [USRP-users] Crimper tool for E310 GPIO connector
Message-ID:
<CAKazox0oH45XCG=gjk0m1dnrzjjoksdgoqt-z+wrg6rwgmj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I've found the following crimper for the GPIO connector (df20f-10dp-1v) for
the E310.
https://www.digikey.com/product-detail/en/hirose-electric-co-ltd/HT302-DF20B-2830S/H3150-ND/679776
The $1600 price tag is prohibitively expensive for a single-purpose tool
like this. Does anyone know of an alternative/equivalent crimper?
Thanks,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170614/c2948d2b/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 14 Jun 2017 20:43:31 -0400
From: EJ Kreinar <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<CADRnH22hyLjAw1M_ha-5oZis2bnp3wjJ7sV=bzhm_jwgjbo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, this is an admitted hack, I should say.
The assignment to MY_OOT_DIR := OOT_DIR in the
rfnoc-ootexample/rfnoc/Makefile.inc forces the evaluation of OOT_DIR
immediately, and the OOT modules uses MY_OOT_DIR from then on, for example.
I've tested this successfully with multiple different OOT repos.
If you have a suggested improvement that's less hacky though, I'm
definitely interested :)
EJ
On Wed, Jun 14, 2017 at 2:08 PM, Jason Matusiak <
[email protected]> wrote:
> EJ,
> I am creating a new RFNoC repo and thought I would go through your write
> up and see if I can find anything that we missed while you and I were
> working offline. The first thing I wondered was, in the Makefile.OOT.inc,
> can I have more than one OOT_DIR? I have one in there right now for my
> current blocks, but I am not sure how to point to a different folder
> without screwing your setup up.
>
> ~Jason
>
>
> On 05/23/2017 10:04 PM, EJ Kreinar wrote:
>
> Hi Jason and others,
>
> As a follow up, I put together an rfnoc OOT repo that uses Makefiles to
> build Vivado IP and HLS IP: https://github.com/ejk43/rfnoc-ootexample
>
> The simulations should run successfully when uhd-fpga is set up correctly
> (see readme), and also should build the OOT noc_blocks into an FPGA image
> using "make E310_RFNOC" etc etc.
>
> Hope this helps,
> EJ
>
> On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar <[email protected]> wrote:
>
>> Jason,
>>
>> Sure, I'd say just clone my fpga repo and apply the patch for now. Quick
>> instructions:
>>
>> 1. In your uhd-fpga repo: `git remote add ejk
>> https://github.com/ejk43/fpga.git` <https://github.com/ejk43/fpga.git>
>> a. This now sets up a remote named "ejk" which points to my fork
>> 2. Then: `git fetch ejk new_oot_includes`
>> 3. Then you can either checkout this branch (if you have no other changes
>> on your uhd-fpga repo), or cherry-pick the commits from the
>> new_oot_includes branch.
>>
>>
>> In lieu of an example OOT repo, here's how I set up my "rfnoc" folder
>> structure in the OOT repo:
>>
>> rfnoc:
>> + Makefile.inc
>> + blocks
>> + testbenches
>> + fpga-src
>> + Makefile.inc
>>
>> + noc_block_testblock.v
>>
>> + ip
>> + Makefile.inc
>> + my_ip
>> + my_ip.xci
>> + Makefile.inc
>>
>>
>>
>> Here's an example top-level Makefile.inc:
>>
>> RFNOC_MYTEST_DIR := $(OOT_DIR)
>> include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
>> include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
>>
>>
>>
>> Then the fpga-src Makefile.inc:
>>
>> RFNOC_OOT_SRCS += $(addprefix $(RFNOC_MYTEST_DIR)/fpga-src/, \
>> noc_block_testblock.v \
>> )
>>
>>
>>
>> Then the IP Makefile.inc (modeled after the Makefile.inc in the
>> uhd-fpga/usrp3/lib/ip:
>>
>> include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
>>
>> LIB_MYTEST_IP_XCI_SRCS = \
>> $(LIB_IP_MY_IP_SRCS)
>>
>> LIB_MYTEST_IP_SYNTH_OUTPUTS = \
>> $(LIB_IP_MY_IP_OUTS)
>>
>> LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
>>
>>
>>
>> And finally, the Makefile.inc inside the my_ip directory (modeled after
>> the lib/ip/xxx Makefile.inc):
>>
>> include $(TOOLS_DIR)/make/viv_ip_builder.mak
>>
>> LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
>>
>> LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
>> my_ip.xci.out \
>> synth/my_ip.vhd \
>> )
>>
>> $(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) : $(LIB_IP_DIR)/my_ip/my_ip.xci
>> $(call BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_
>> BUILD_DIR),0)
>>
>>
>>
>> It's also possible to rejigger the testbench makefiles to build the OOT
>> IP for your testbench.
>>
>> Again, I should pull this into an example OOT repo sometime soon, which
>> would make it a bit easier to have an example. Let me know if you hit any
>> problems.
>>
>> EJ
>>
>> On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak <
>> [email protected]> wrote:
>>
>>> EJ, that looks exactly like what I need to do. Is there a way for me to
>>> patch in your changes so I can try to use them while we wait for Ettus to
>>> (dis)approve your PR?
>>>
>>> Thanks!
>>> ~Jason
>>>
>>>
>>>
>>> On 05/18/2017 04:11 PM, EJ Kreinar wrote:
>>>
>>> Hi Jason,
>>>
>>> I currently have a PR in to the fpga repo (https://github.com/EttusResea
>>> rch/fpga/pull/12) that adds support for linking Makefile.inc files in
>>> OOT repos. Your OOT Makefile can then build the Xilinx IP and append it to
>>> your build as needed. I've been using this approach for some time now with
>>> success for both Xilinx IP and HLS designs.
>>>
>>> I have an action to provide a sample "dummy" OOT repo with the correct
>>> Makefiles-- but I havent gotten to it yet, unfortunately-- Was waiting for
>>> confirmation if this approach will be supported in-tree in the future. I
>>> could put something together soon though if this would help.
>>>
>>> I'd also be interested in other good solutions, if anyone has an
>>> alternate approach :)
>>>
>>> EJ
>>>
>>> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I wanted to create an RFNoC block that utilized some Xilinx cores.
>>>> Where do I need to put these cores in the rfnoc-modtool project created
>>>> directory structure, and how do I go about tying that into the Vivado GUI
>>>> so I can build them up (just use the GUI=1 CL argument and do the save-as
>>>> project approach?)?
>>>>
>>>> _______________________________________________
>>>> 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/20170614/63e39c23/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 15 Jun 2017 01:21:25 -0700
From: Kyeong Su Shin <[email protected]>
To: olivani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 transmitting signal using
tx_samples_from_file
Message-ID:
<CAGL0V3=L+swGMnjAWgF75s5jC==d9mqbzmkzyqxvbb6offc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Olivani Subbukutty:
Yes, that happens. USRP is not a calibrated equipment; it does not attempt
to correct the changes in the transmission power level which happen when
you tune your radio into different frequencies. The transmission power
(assuming the same 'gain' knob setting) is frequency-dependent, as it can
be seen from the AD9361 chipset datasheet. I expect larger variances than
what is shown on the AD9361 datasheet, as the rest of the RF frontend and
the cabling between your spectrum analyzer and the SDR introduce additional
(frequency-dependent) losses.
Regards,
Kyeong Su Shin
On Wed, Jun 14, 2017 at 6:00 AM, olivani via USRP-users <
[email protected]> wrote:
> Hi ,
>
> I am transmitting a 1MHz complex IQ data signal using tx_samples_from_file.
> When I set the freq to be 1GHz and transmit the data and check it with a
> spectrum analyzer.
> The same data when I change the freq carrier to 3GHz I see a decrease in
> amplitude of the signal .
> I did not change any gain parameter.
> Has any one noticed this before , if so I would like to understand the
> reason behind it.
>
> Thanks and Regards,
> Olivani Subbukutty
>
>
> _______________________________________________
> 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/20170615/45ef42aa/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 15 Jun 2017 10:52:39 +0200
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Ettus Research Support <[email protected]>
Subject: Re: [USRP-users] Exception raised when trying to read FPGA
time
Message-ID:
<ca+abmwjqtryfol6bpdmbr7cqu8ojhs5afw0p2k9wycjghpy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Ettus Support Team,
This is an update the my last email. After some more investigation I could
figure out the reason for the exception is not coming from reading the FPGA
time (uhd_usrp_get_time_now).
The issue we have been facing seems to be related to the UHD driver. We
have an AGC thread that constantly tries to automatically adapt the RX
Gain. For that purpose, the AGC thread changes the RX Gain whenever it is
necessary, however, sometimes the application crashes with the following
exception:
*terminate called after throwing an instance of 'std::length_error'what():
basic_string::_S_create*
I've googled for that exception and the information I've got is that it
happens when trying to create a string bigger than *std::string::max_size()*
.
My code is written in C and I don't use strings except the ones used by the
UHD driver once that code was written in C++.
I have been hunting down the source of the exception and figured out it
might be coming from the UHD library. I used gdb with the following
commands:
*set pagination offcatch throwcommandsbacktracecontinueendrun*
After running my application with GDB I've got the following stack trace
when the exception happens:
------------------------------------------------------------
--------------------------------
Catchpoint 1 (exception thrown), 0x00007ffff2b6d8b0 in __cxa_throw () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#0 0x00007ffff2b6d8b0 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libs
tdc++.so.6
#1 0x00007ffff2bbf3a7 in std::__throw_length_error(char const*) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00007ffff2bc9262 in std::string::_Rep::_S_create(unsigned long,
unsigned long, std::allocator<char> const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff2bc93d6 in std::string::_M_mutate(unsigned long, unsigned
long, unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff36b5e1e in uhd_usrp_set_rx_gain () from
/usr/local/lib/libuhd.so.3
#5 0x00007ffff4ee6a20 in rf_uhd_set_rx_gain (h=0x7cbce0,
gain=631,56964111328125) at /home/zz4fap/imec/scatter/phy/
srslte/lib/rf/rf_uhd_imp.c:507
#6 0x00007ffff4ee52e7 in thread_gain_fcn (h=0x654740 <rf>) at
/home/zz4fap/imec/scatter/phy/srslte/lib/rf/rf_imp.c:72
#7 0x00007ffff4c75184 in start_thread (arg=0x7fffe6ffd700) at
pthread_create.c:312
#8 0x00007ffff4410bed in clone () at ../sysdeps/unix/sysv/linux/x86
_64/clone.S:111
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_S_create
Program received signal SIGABRT, Aborted.
0x00007ffff4349c37 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) quit
A debugging session is active.
------------------------------------------------------------
--------------------------------
As you can see, the exception happens after the application tries to call
the UHD function: "uhd_usrp_set_rx_gain".
I have done some modifications to the UHD code and so far I couldn't spot
the crash anymore. Basically what I've done is to add try/catch statements
to get that exception and try to understand the root cause. You will find
the files I've modified enclosed to this email. Apart from adding try/catch
I've done the following modifications that I think could impact:
1) In file: host/lib/usrp/multi_usrp.cpp I commented out "catch
(uhd::key_error &)" and added a catch for all exceptions
+ } catch (...) {
+ //} catch (uhd::key_error &) {
2) In file: host/lib/usrp/usrp_c.cpp I removed the use of
"UHD_SAFE_C_SAVE_ERROR" and added a try/catch.
- UHD_SAFE_C_SAVE_ERROR(h,
+
+ try {
+ std::string name(gain_name);
+ if(name.empty()){
+ USRP(h)->set_rx_gain(gain, chan);
+ }
+ else{
+ USRP(h)->set_rx_gain(gain, name, chan);
+ }
+ } catch(...) {
+ std::cout << "OMG!!! An exsception" << std::endl;
+ exit(-1);
+ }
+
+return UHD_ERROR_NONE;
+
+/* UHD_SAFE_C_SAVE_ERROR(h,
std::string name(gain_name);
if(name.empty()){
USRP(h)->set_rx_gain(gain, chan);
@@ -952,6 +968,7 @@ uhd_error uhd_usrp_set_rx_gain(
USRP(h)->set_rx_gain(gain, name, chan);
}
)
+*/
That crash was happening very often without my modifications and now, with
these modifications, I haven't been able to reproduce the crash anymore.
Could you help me trying to understand the root cause for that issue,
please? I wouldn't like to keep those changes to the UHD code without
knowing the real reason for crash.
Many Thanks and Kind Regards,
Felipe Augusto
On Tue, Jun 13, 2017 at 11:45 AM, Felipe Augusto Pereira de Figueiredo <
[email protected]> wrote:
> Dear Folks,
>
> I've got a piece of code where I read the FPGA time and use that
> information as a timestamp on a message I send to another application. I'm
> using the following function:
>
> uhd_usrp_get_time_now(handler, 0, secs, frac_secs);
>
> After sometime I've got the following exception:
>
> terminate called after throwing an instance of 'std::length_error' what():
> basic_string::_S_create
>
> I was hard to figure out where that exception was coming from. I've added
> a lot of printfs to my code until I found it was happening when I tried to
> read the FPGA timestamp.
>
> Could you tell me why that happens and how to solve it, please?
>
> I've got a B200 and UHD driver [INFO] [UHDlinux; GNU C++ version 4.8.4;
> Boost_105400; UHD_3.11.0.git-208-g1da86f9c]
>
> Thanks and Kind Regards,
>
> Felipe Augusto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/d011b7a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi_usrp.cpp
Type: text/x-c++src
Size: 82055 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/d011b7a9/attachment-0002.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi_usrp.hpp
Type: text/x-c++hdr
Size: 44370 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/d011b7a9/attachment-0001.hpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp_c.cpp
Type: text/x-c++src
Size: 39056 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/d011b7a9/attachment-0003.cpp>
------------------------------
Message: 8
Date: Thu, 15 Jun 2017 11:05:46 +0200
From: Sylvain Munaut <[email protected]>
To: Daniel May <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Crimper tool for E310 GPIO connector
Message-ID:
<CAHL+j0_e-xcaoLJ8T4soPaHOcRY6Y=WDhMfAvT=kk2-dftw...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
> I've found the following crimper for the GPIO connector (df20f-10dp-1v) for
> the E310.
>
> https://www.digikey.com/product-detail/en/hirose-electric-co-ltd/HT302-DF20B-2830S/H3150-ND/679776
>
> The $1600 price tag is prohibitively expensive for a single-purpose tool
> like this. Does anyone know of an alternative/equivalent crimper?
Farnell / Newark has pre-crimped cables :
http://be.farnell.com/multicomp/cass-0843/cable-assembly-crimp-socket-300mm/dp/2506398
Not cheap but cheaper than 1.6k :p
Cheers,
Sylvain
------------------------------
Message: 9
Date: Thu, 15 Jun 2017 14:28:32 +0000
From: Kevin Krieger <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Netgear 10GB switch XS728T
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Marcus,
Thank you - I was sure that the same subnet was correct but it's good to
have confirmation.
I have done the dissecting previously, and I recall getting a bunch of
"huh what's that?"' messages and then a 'wassup bro' or something but
I'll do it again and let you know what I see. (Hilarious descriptions btw!)
Kevin
On 05/24/2017 08:07 PM, Marcus M?ller via USRP-users wrote:
>
> Hi Kevin, Hi Robin,
>
> the same-subnet configuration is the right one, here. There's no
> routing ambiguity if you have one card that serves the whole switch.
>
> Kevin, this might be much to ask, but: I'd ask you to both install
> wireshark and its development headers (typically, wireshark-dev or
> wireshark-devel) from your operating system's package manager.
>
> Then, get the UHD source code, and
>
> cd /path/to/uhd/tools/dissectors
> mkdir build
> cd build
> cmake -DETTUS_DISSECTOR_NAME=zpu ..
> make -j4 && make install
>
> Ideally, add your user to the group that has access to the raw network
> hardware (in case of my OS, that was the "wireshark" group), log out
> and back in.
>
> If that doesn't work, you have to record as root and analyze as your
> user (the USRP protocol dissectors got installed to your home directory).
>
> Then, record the traffic on your 10G interface, and analyze the
> packets in question as UHD (some/many will be sample packets, i.e. CVITA).
>
> Best regards,
>
> Marcus
>
> On 24.05.2017 20:15, ROBIN TORTORA via USRP-users wrote:
>>
>> The only thing that jumps out to me is they are all on the same subnet...
>>
>>
>> That is something I have typically avoided, but if you say it works
>> in another configuration, that may not be the issue...
>>
>>> On May 24, 2017 at 12:12 PM Kevin Krieger via USRP-users
>>> <[email protected]> wrote:
>>>
>>> Hi all,
>>>
>>> I've got a predicament. Here's some *background* before I describe
>>> my problem:
>>> We purchased a Netgear xs728T 10GB switch in order to network 16
>>> N200 devices, as well as a processing computer (which has a 10G
>>> ethernet card). Our 16 N200 devices are going to be used in a radar
>>> configuration where they are all simultaneously either transmitting
>>> or receiving. They are all receiving coincident 10MHz and 1PPS
>>> signals from 2 octoclocks, which are both fed from a third clock to
>>> ensure coincident clocks. They are connected to the switch via cat6
>>> cables ~7feet in length (this item:
>>> https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136)
>>>
>>> *The problem:*
>>> During testing we've found that the example program tx_bursts, when
>>> run on one USRP at a time with a modest bandwidth, the "Waiting for
>>> async burst ack....failed" message appears about 75% of the time. If
>>> I try to use two or more USRPs at a time, then it appears every time.
>>> The line used for tx_bursts was typically something like
>>> this:./tx_bursts --args="addr0=192.168.10.104" --freq 10e6
>>> --rate=1e6 --channels="0"
>>> for a one usrp test. For a multiple usrp test, I used lines like
>>> this:./tx_bursts
>>> --args="addr0=192.168.10.101,addr1=192.168.10.102,addr2=192.168.10.103,addr3=192.168.10.100,addr4=192.168.10.112,addr5=192.168.10.113,addr6=192.168.10.114"
>>>
>>> --freq 10e6 --rate=1e6 --channels="0,1,2,3,4,5,6"
>>>
>>>
>>> *Some evidence & information:
>>> *We also have a 5 port 1G DLink DGS-1005G. We've tested 4 N200s with
>>> tx_bursts on this switch (same cabling) and it works flawlessly.
>>> We also have tested a second 10G switch, the 8 port XS708E with 7
>>> N200s with tx_bursts and it works flawlessly.
>>>
>>> I have wireshark dumps taken via a third machine that is connected
>>> to mirrored ports on the xs728T switch. I have attached them in case
>>> anyone can tell me if they see something wrong besides the missing acks.
>>> The wireshark filter to use is : ip.src == 192.168.10.104 and ip.dst
>>> == 192.168.10.104 or ip.src == 192.168.10.104 and ip.dst ==
>>> 192.168.10.99
>>>
>>> The xs728t switch information is: Boot version is 1.0.0.0, SW
>>> version is 6.5.1.26 (latest as of testing).
>>> I contacted Netgear support, and they sent us a brand new switch,
>>> which exhibited the same problem.
>>>
>>> I'm wondering if there's anyone out there who has had similar
>>> issues? Is there anything I can do to get more information or get
>>> around this problem?
>>> Can anyone see what the root cause might be in the wireshark captures?
>>>
>>> Any help or pointers are appreciated. Thank you,
>>> Kevin
>>
>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> 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
>
>
>
> _______________________________________________
> 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/20170615/5407389c/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 15 Jun 2017 11:11:40 -0400
From: Samuel Berhanu <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] writing a register in FPGA from host in X310
(device 3 i guess)
Message-ID:
<caeyq4nd2kmvffnvvvbrubndo31joray6ygcyqamt-zcrnr-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Looks like the user_register was scrapped for X310 and that the
implementation has to be done with poke32 function. I tried it with
set_user_registers() function, and the result is:
LookupError: Path not found in tree: /mboards/0/user/regs.
i looked at x300_impl and sure enough there is nothing setting the
registers like what I saw in the Usrp2_impl.cpp and user_set_reg_core200
files. Would be nice if someone can at least confirm this.
On Tue, Jun 13, 2017 at 11:15 AM, Samuel Berhanu <[email protected]>
wrote:
> the previous versions of USRPs look like they had a memory map, called
> SR_USER_REGs or something to that effect. It looks like that doesn't exist
> anymore in the X310, or E310?
>
> it looks like i don't have to hunt down the base for the above register
> (even if it were to exist) so that I can use *set_user_register*( addr,
> data, MBOARDS) from host as mentioned in N210 setting user register base
> is 0 (but is it same for x310)
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/013525.html>
> and FPGA access from host with setting reg, looks like x310 same as N210
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/013560.html>
>
> then my question is,
>
> Would using *set_user_register from host* limit one to where I can locate
> my FPGA code in the device modules already existent in the FPGA (this is a
> pre-rfnoc development code)?
>
> The confusion i have is this (i guess i can build this and find out if it
> works or not) - but more for understanding, it seems to me that there are
> FPGA-module dependent base addresses. how does set_user_register send the
> correct address? is all addresses inherently synthesized from objects that
> generate the commands in host/uhd except set_user_register and hence, it
> doesn't matter where the location of a custom logic is in the FPGA?
>
> thanks
>
> sam
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/279a2426/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 15 Jun 2017 11:53:45 -0400
From: Jason Matusiak <[email protected]>
To: Samuel Berhanu <[email protected]>, [email protected]
Subject: Re: [USRP-users] writing a register in FPGA from host in X310
(device 3 i guess)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Did you take a look at how the RFNOC fosphor and DDC blocks works? I
think that both of them take outside messages that set their registers.
Fosphor is what I used for the basis for my block, though I am writing
it via a message port, but I think it is the same on the FPGA side of
things.
On 06/15/2017 11:11 AM, Samuel Berhanu via USRP-users wrote:
> Looks like the user_register was scrapped for X310 and that the
> implementation has to be done with poke32 function. I tried it with
> set_user_registers() function, and the result is:
>
> LookupError: Path not found in tree: /mboards/0/user/regs.
>
> i looked at x300_impl and sure enough there is nothing setting the
> registers like what I saw in the Usrp2_impl.cpp and
> user_set_reg_core200 files. Would be nice if someone can at least
> confirm this.
>
>
> On Tue, Jun 13, 2017 at 11:15 AM, Samuel Berhanu <[email protected]
> <mailto:[email protected]>> wrote:
>
> the previous versions of USRPs look like they had a memory map,
> called SR_USER_REGs or something to that effect. It looks like
> that doesn't exist anymore in the X310, or E310?
>
> it looks like i don't have to hunt down the base for the above
> register (even if it were to exist) so that I can use
> *set_user_register*( addr, data, MBOARDS) from host as mentioned
> in N210 setting user register base is 0 (but is it same for x310)
>
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/013525.html>
>
> and FPGA access from host with setting reg, looks like x310 same
> as N210
>
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/013560.html>
>
> then my question is,
>
> Would using *set_user_register from host* limit one to where I can
> locate my FPGA code in the device modules already existent in the
> FPGA (this is a pre-rfnoc development code)?
>
> The confusion i have is this (i guess i can build this and find
> out if it works or not) - but more for understanding, it seems to
> me that there are FPGA-module dependent base addresses. how does
> set_user_register send the correct address? is all addresses
> inherently synthesized from objects that generate the commands in
> host/uhd except set_user_register and hence, it doesn't matter
> where the location of a custom logic is in the FPGA?
>
> thanks
>
> sam
>
>
>
>
>
> _______________________________________________
> 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/20170615/cc1752f0/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 82, Issue 15
******************************************
