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: Dual RX acquisition with E310 (Philip Balister)
2. Re: Using Chipscope on the E310 (Jonathon Pendlum)
3. Re: x310 IP build failure (Long, Jeffrey P.)
4. problem kicking off flowgraph automatically on E310
(Jason Matusiak)
5. Re: Time-division duplexing (Santos Campos)
6. About custom FPGA on X310 (liu Jong)
7. Issue with DmaFIFO uhd::lookup_error' (Walter Maguire)
8. Re: Dual RX acquisition with E310 ([email protected])
9. Re: Implementing design on FPGA in X310 (Nives Novkovi?)
10. Understand branch name into git repo ([email protected])
11. Re: Understand branch name into git repo (Jason Matusiak)
12. Re: Understand branch name into git repo (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Sep 2016 09:27:42 -0700
From: Philip Balister <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] Dual RX acquisition with E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 09/27/2016 08:01 AM, alex.dtd--- via USRP-users wrote:
> Hi Marcus,
>
> I'm back with the same problem.
>
> In my previous test, UHD versions on desktop and E310 seems to be different.
> Indeed, UHD version on E310 is 3.9.2-0-unknown (Why "unknown", it's unknown
> :-) )
> I use 3.9.2-0-gf18abe54 on my desktop. So, I cross-compiled the same for E310
> and "link it" using sshfs (cf.
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312 )
Regarding the "unknown" ....
For historical reasons, when uhd builds it insists on inserting the
actual git revision into the version string. But, the OpenEmbedded
recipe for the package on the E310 uses the actual release tarball to
build UHD. So the piece of cmake that runs git to figure out the hash of
the git repo fails because it isn't being run in a git repo.
Philip
>
> I was hoping it could be the solution, but ... in fact, no!
>
> The problem is always here.
>
> I launch programs on E310 using "sshfs":
> 1) "rx_samples_to_file" for individual frontend (i.e., A:A or A:B), it's a
> success.
> 2) My "dualRx_samples_to_file" (source code where you didn't find anything
> wrong), it's failure!
> Datas from 2nd channel (A:B) are good BUT received in buf_ptr[0] instead of
> buf_ptr[1].
> buf_ptr[1] is filled by 0.
>
> I really try to find a solution by myself but I still need help.
>
> Best regards.
>
> Alex
>
>
>
>> Date: Tue, 23 Aug 2016 09:32:59 +0200
>> From: Marcus M?ller <[email protected]>
>> To: [email protected]
>> Subject: Re: [USRP-users] Dual RX acquisition with E310
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Hi Alex,
>>
>> I'd expect the SD card to be about as fast if not faster than the
>> network interface.
>>
>> I wasn't asking you to test the software on the E310 itself because of
>> higher speed, however ? it would have removed the additional complexity
>> of using the network mode!
>>
>> Yes, I've looked through your source code and couldn't find something
>> immediately, especially since you said it worked with X310, that
>> would've surprised me.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 23.08.2016 09:23, alex.dtd--- via USRP-users wrote:
>>> Hi Marcus,
>>>
>>> First of all, thanks for the quick answer.
>>>
>>> No, I don't test it on the E310 itself because the SD card write speed is
>>> too low.
>>>
>>> I agree that network mode for E310 is just for debug but the rate for the
>>> slowest testing dual RX is only 50k/channel <=> 800kB/s ...
>>> As I said in my previous message, I checked "/rx_samples_to_file/" @
>>> ~1Msamples/s <=> 8MB/s. So, it's not the problem!
>>>
>>> The problem should be:
>>> 1) I don't use the UHD library well.
>>> 2) Pb in UHD library.
>>> 3) Pb in E310 firmware.
>>>
>>> Did you have a look on my source code? Something wrong?
>>>
>>> Best regards
>>>
>>> Alex
>>>
>>>
>>> _______________________________________________
>>> 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
>
------------------------------
Message: 2
Date: Tue, 27 Sep 2016 11:32:17 -0500
From: Jonathon Pendlum <[email protected]>
To: "Seger, Edward H" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using Chipscope on the E310
Message-ID:
<CAGdo0uTT7nfKb=prhxq2ti9hxebnyjdyumfdk0kf97xqu_q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ed,
An approach I use when running chipscope is to specify the bitstream I want
to use with --args="fpga=<path to my bitstream>" and to set a breakpoint
(via gdb) before the recv call in benchmark_rate or other utility app I am
using. The breakpoint is useful because radio_clk is not running until the
AD9361 has been setup. In many cases your chipscope instance will be
probing nets using radio_clk and without that clock running Vivado won't be
able to find the ILA.
As for being unable to JTAG after your program exits (even though you
disabled loading the idle image), the daughter board is still powered down
which will disable the AD9361 / radio_clk.
Jonathon
On Tue, Sep 27, 2016 at 7:10 AM, Seger, Edward H via USRP-users <
[email protected]> wrote:
> Has anybody had experience running chipscope on the E310 using the arg
> that Martin pointed out below? It is throwing a bizarre error as I have
> shown below.
>
> The arg "no_reload_fpga" appears to be a key, based on how it is accessed,
> I don't kno what the value should be or if the value matters. I
> experimented with various values with no success.
>
> Another thing I want to bring up is if I comment out the code in
> e300_impl.cpp that reloads the FPGA with the idle bitfile, I still cant use
> chipscope when the utility (rx_samples_to_file) exits. Something after the
> main processing while in recv_to_file() causes the FPGA to stop responding
> to the JTAG requests. What is going on with this? Currently I put a
> while(1) after this while loop and I have access to the chipscope ILA.
>
> Perhaps Jonathon could chime in here....
>
> Thanks for the help
> Ed
>
>
>
>
> Previous communication:
>
>
> Martin,
> There is something really wrong with what I am doing so I need
> more information. I am using 3.9.3, fpga V14. I am using a utility based
> on rx_samples_to_file. I instrumented e300_impl.cpp to show the address
> argument into the class. If I execute with this --args arg:
>
> --args='fpga=/home/root/e300.bit, no_reload_fpga=1'
>
> This is what I get:
>
> Creating the usrp device with: fpga=/home/root/e300.bit,
> no_reload_fpga=1...
>
> Address: Device Address:
> type: e3x0
> node: /dev/axi_fpga
> name:
> serial: xxxxxx
> product: 30674
> fpga: /home/root/e300.bit
> no_reload_fpga: 1
>
> Error: RuntimeError: [ad9361_device_t] BBPLL not locked
>
> The interesting thing is if I replace "no_reload_fpga=1" with
> "blabla=wonk", the utility runs, but loads the FPGA with the idle file.
>
> I see code supporting "no_reload_fpga" in e300_impl.cpp, but that code
> never gets to run because of the error above.
> Am I supplying the argument incorrectly, or is this an actual bug?
>
> Thanks,
> Ed
>
> -----Original Message-----
> From: Martin Braun [mailto:[email protected]]
> Sent: Friday, September 23, 2016 8:02 PM
> To: Seger, Edward H
> Subject: Re: [USRP-users] Using Chipscope on the E310
>
> Commas is the correct way.
>
> --args key1=val1,key2=val2
>
> M
>
> On 09/23/2016 04:33 PM, Seger, Edward H wrote:
> > Martin,
> > Thanks for the suggestions! How do you specify this arg tho? I
> currently use this:
> >
> > --args='fpga=/home/root/e300.bit'
> >
> > I tried a few ways to have 2 args with no success. It does not let me
> > have two --args arguments, commans between args, etc
> >
> > Ed
> >
> >
> >
> > -----Original Message-----
> > From: USRP-users [mailto:[email protected]] On Behalf
> > Of Martin Braun via USRP-users
> > Sent: Friday, September 23, 2016 6:05 PM
> > To: [email protected]
> > Subject: Re: [USRP-users] Using Chipscope on the E310
> >
> > The E310 reloads the FPGA image every time it runs an app. You can
> disable this behaviour with the 'no_reload_fpga' device arg.
> >
> > Another option is to insert breakpoints in your code.
> >
> > Cheers,
> > Martin
> >
> > On 09/23/2016 01:40 PM, Seger, Edward H via USRP-users wrote:
> >> How do you use Chipscope (an ILA) on the E310? I built the E310 fpga
> >> design with the ILA in it using a vivado 2014.4 gui project. When I
> >> load it to the E310 using jtag, it causes the linux to shut down the
> >> E310. If I load the built e300.bit file on the e310s command line,
> >> using rx_samples_to_file, I don't see the ILA when I refresh the
> >> device. The "operational" bit file is only running for a few seconds
> >> using this method. If I set the number of samples too high, it runs
> >> longer but I get a timeout and the idle.bit gets loaded. I tried my
> >> own app where I don't exit until sighup but I still don't see the ILA.
> >> Any ideas?
> >>
> >> Ed
> >>
> >>
> >> _______________________________________________ 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/20160927/f3770a70/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 27 Sep 2016 16:41:28 +0000
From: "Long, Jeffrey P." <[email protected]>
To: EJ Kreinar <[email protected]>
Cc: "[email protected]" <[email protected]>, "Marcus
D. Leech" <[email protected]>
Subject: Re: [USRP-users] x310 IP build failure
Message-ID:
<cy4pr09mb13676598941a2fcd1635a026d9...@cy4pr09mb1367.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
EJ-
Thanks I will play with the docker thing a little. A coworker tells me that it
can be tough in case you need to run the GUI (which I do for other projects)
but I will still play with it.
I can report that the glibc fix in the links you sent does work. They recommend
installing to Xilinx?s library but I could not figure out how to do that so I
did a regular system install and that seems a little scary however everything
seems to work so far. Hopefully that will last me till we move to 2016.X
someday?..
Thanks again,
Jeff
From: EJ Kreinar [mailto:[email protected]]
Sent: Monday, September 26, 2016 6:34 PM
To: Long, Jeffrey P.
Cc: [email protected]; Marcus D. Leech
Subject: RE: [USRP-users] x310 IP build failure
I did not try a glibc rebuild.
Just a thought: I admit there's a bit of a docker learning curve but I would
highly encourage docker over a VM :) I found it to be extremely responsive
(zero bootup time, etc) and it supports running the Vivado GUI without any
problems. Plus, you can link the container into your local rfnoc prefix so all
the build outputs are in-place in your directory. Very convenient
EJ
On Sep 26, 2016 4:46 PM, "Long, Jeffrey P."
<[email protected]<mailto:[email protected]>> wrote:
EJ-
Thanks good to hear I am not nuts but this is a bummer. Yes a VM should work
and I have done this before and will do it again if I have to. Have you tried
the glibc configured with ?disable-lock-elision thing mentioned in those links?
By the way I rolled back to a UHD that builds with 2014.4 and that failed too.
Thanks
Jeff
From: EJ Kreinar [mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, September 26, 2016 4:33 PM
To: Long, Jeffrey P.
Cc: Marcus D. Leech;
[email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] x310 IP build failure
Hi Jeff,
I ran into this same problem on my Ubuntu 16.04 LTS when starting to work with
Xilinx. It seems to be related to more recent Intel processors. I also tried an
installation of Vivado 2016.X and built a demo application for the Zynq as a
sanity check, but the same issue showed up again (I'd be interested to hear if
that solves the problem for you). Here's some hits I found online about the
problem:
https://www.reddit.com/r/FPGA/comments/4olc29/is_anyone_running_vivado_2016x_on_a_recent_ubuntu/
https://forums.xilinx.com/t5/Synthesis/Vivado-crash-on-Ubuntu-16-04/td-p/699642/page/2
I HAVE had success running Xilinx in a Docker container. I currently do all my
FPGA builds from this container. I've attached a tar of the Dockerfile and a
readme, in case it can help you too. This should work with vivado from the
command line or from GUI. I have only tested using the Xilinx license available
for the e310, which is not nodelocked... If you need to build for the X300
series, you may need to handle licensing a bit differently. But at the very
least, you should be able to test and confirm if the Vivado build works OK on
your machine.
Regards,
EJ
On Mon, Sep 26, 2016 at 4:05 PM, Long, Jeffrey P. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Yeah that is usually a waste of time. A quick search right now on libpthread
and 2015.4 yielded similar issues. The canned Xilinx response is update to
2016.X, this fixes the issue. Unfortunately we can?t do that here. They also
won?t even entertain my posts since I am using the very non-standard and
unsupported Ubuntu 16 LTS. I have had this problem before. If you happen to be
so unlucky that your version of vivado crashes then the only thing to do is
roll back or forward in UHD till you find something that works. Switching
around Oss is also an option albeit a pain.
I am going to try the 2015.4 update 2 patch. Do you happen to know if that will
be OK from the setupenv.sh perspective?
Thanks
Jeff
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Monday, September 26, 2016 3:21 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] x310 IP build failure
On 09/26/2016 03:13 PM, Long, Jeffrey P. via USRP-users wrote:
Wondering if anyone has seen this issue or knows what I may have wrong here.
Trying to get familiar with RFNOC and the build process so I have pulled down
the latest git, switched to rfnoc-devel, init?d and updated the submodule. I
have installed vivado 2015.4 and have a full license and am running under
Ubuntu 16 LTS. I sourced the setupenv.sh and then ran make X310_RFNOC_HG. By
the way I also did the disable dash reconfig thing just in case.
It starts the IP generation for the 10 gig and then without any error it fails.
Below is a snippet of the last bits before it dies. I also attached the error
log and the ip build log.
Just as a data point I just did the same exact setup under Ubuntu 12 LTS and it
did not fail so it seems that there is some issue with 16 LTS??
Thanks
Jeff
??
---------------------------------------------------------------------------------
Finished RTL Optimization Phase 2 : Time (s): cpu = 00:00:25 ; elapsed =
00:00:25 . Memory (MB): peak = 1581.988 ; gain = 734.895 ; free physical =
29303 ; free virtual = 63061
---------------------------------------------------------------------------------
Report RTL Partitions:
+-+--------------+------------+----------+
| |RTL Partition |Replication |Instances |
+-+--------------+------------+----------+
+-+--------------+------------+----------+
---------------------------------------------------------------------------------
Start RTL Component Statistics
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
Finished RTL Component Statistics
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
Start RTL Hierarchical Component Statistics
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
Finished RTL Hierarchical Component Statistics
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
Start Part Resource Summary
---------------------------------------------------------------------------------
Parent process (pid 8304) has died. This helper process will now exit
BUILDER: Releasing IP location:
/home/jplong/proj/uhd/fpga-src/usrp3_rfnoc/top/x300/build-ip/xc7k325tffg900-2/ten_gig_eth_pcs_pma
/home/jplong/proj/uhd/fpga-src/usrp3_rfnoc/top/x300/ip/ten_gig_eth_pcs_pma/Makefile.inc:41:
recipe for target
'/home/jplong/proj/uhd/fpga-src/usrp3_rfnoc/top/x300/build-ip/xc7k325tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out'
failed
make[1]: ***
[/home/jplong/proj/uhd/fpga-src/usrp3_rfnoc/top/x300/build-ip/xc7k325tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
Error 139
Makefile:65: recipe for target 'X300_HG' failed
make: *** [X300_HG] Interrupt
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
This looks like a bug in libpthread, possibly tripped-over by the Vivado
library that is next in the stack.
You should probably talk to Xinlinx support about this.
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20160927/37e45437/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 27 Sep 2016 12:46:44 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] problem kicking off flowgraph automatically on
E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I am trying to kick off a flowgraph automatically on my E310, but I've
been having issues for some reason. I setup a link in rc5.d to call a
rc.local script in /etc/init.d/. The rc.local basically just has:
#!/bin/sh
python /home/root/script.py&
If I run that by hand, it seems to get most of the way through setting
up the device, but doesn't get to the "press enter to exit" command at
the end. If I remove the & from the script and run it from hand, it
seems to work, but not when it gets kicked off on boot up.
Is there something I am missing here? Is there an easier way to kick
off a flowgraph on boot on the E310?
------------------------------
Message: 5
Date: Tue, 27 Sep 2016 17:37:21 -0400
From: Santos Campos <[email protected]>
To: Steven Knudsen <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Time-division duplexing
Message-ID:
<CABqE4yNrWH0zMn7m=htynoe-e8uz0ysdj2m-nmrhbihinr2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi, Steven! Thanks for the response.
Yep. As I understand tags, they are just overhead bits in the data of the
stream, correct?
With delay block I was trying to "store" ~10 seconds worth of samples.
In my RX time frame it would be something like: [Rx block]->[Delay] and
[Null source]->[Tx block]
And after 10 seconds I have the paths switch for the Tx time frame: [Delay
block]->[Tx block] and [Rx block]->[Null sink]
This was my naive attempt, and the runtime crashes when trying it.
I implemented a clock (with a 20 second period) and was thinking I could
take advantage of the burst tagger to handle each event like you mentioned
with keys/values. After looking at the example it's probably better handled
within code over grc blocks isn't it? I was hoping to avoid some learning
curve there if I could.
On Mon, Sep 26, 2016 at 11:30 PM, Steven Knudsen <[email protected]> wrote:
> Hi Santos,
>
> In terms of the burst commands, if you have not yet looked at the
> uhd/host/examples/timed_tx_samples.cpp, have a look through it and run
> it. I suggest this assuming that in referring to ?overhead? below, you mean
> once the tags are set in the stream.
>
> If, however, you are referring to how tags are associated with messages,
> then you need to look at pmt dicts. The message meta data comprises zero or
> more key/value dict entries. So, for example, in a MAC, messages can be
> defined that contain the higher-layer PDU as vector data and a tx_time tag
> can be added in the meta data dict. It sounds complicated, but it?s not
> bad. You can test a block (like a MAC), but looking at the output message
> using Message Debug and after converting the message to a stream, use Tag
> Debug.
>
> This may help a little?
>
> Regarding the delay block issue, I am not sure I understand. Are you using
> a delay block between a sink and source? What?s its role?
>
> ta,
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> *Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist
> zu erreichen. - Franz Kafka*
>
> On Sep 26, 2016, at 16:53, Santos Campos via USRP-users <
> [email protected]> wrote:
>
> Hello, all!
>
> I'm having quite a bit of trouble trying to implement a time-division
> duplex in gnuradio and my board.
> It seems that a usrp source and sink don't play well with a huge delay
> block (causes immediate crash). Are there any gnuradio TDD architectures
> floating around? I've tried demuxing the input stream, but I think I could
> be handling all the samples. I also attempted some burst stream tagging,
> but am unsure how to to interpret tags once they're in the overhead.
>
> Any help would be greatly appreciated!
>
> --
> /*
> Santos Campos
> University of Michigan '17 | Computer Engineering
> Virtual EM Inc | Engineering Intern
> santosecampos.com
> */
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
--
/*
Santos Campos
University of Michigan '17 | Computer Engineering
Virtual EM Inc | Engineering Intern
santosecampos.com
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160927/a849ecca/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 28 Sep 2016 11:47:27 +0800
From: liu Jong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] About custom FPGA on X310
Message-ID:
<caeui2n3-3nwhvuj5nb-tri5psk-unqvwwkvdufbn0ew6vrp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
We bought 2 X310,and we plan to develop rfnoc on x310.We saw the
- RFNoC - Getting Started
<https://github.com/EttusResearch/uhd/wiki/RFNoC%3A-Getting-Started>
- RFNoC - Specification
<https://github.com/EttusResearch/uhd/wiki/RFNoC%3A--Specification>
but we still have some questions:
1. How to reflect online data format (OTW) in the implementation of the
FPGA module?
Which module of FPGA or host is responsible for the data format
conversion from otw to CPU?
What are the effects of different OTW formats for the implementation of
FPGA CE?
We now want to implement our own FPGA CE, then how to specify the OTW
format supported by the custom module?
2.When you call the C++ library function to send or receive data, you need
to use method of issue_stream_cmd () , then which FPGA module this method
will eventually be applied to?
Is that OK if we use default control class instead of developing a new
control one?
In what case can we use default class, and in what case must we
implement our own control class?
For example, the CE we developed is similar to null_source module, it
generates data cyclically, and these data will be received by the host.
Is there any difference to other normal module(i.e. FIFO) when we write xml
files?
Does host need control class? Or we only need to use the basic class of
block_ctrl_base?
Is it necessary to specifically implement the method issue_stream_cmd()?
Are there any other aspects that we need to be noticed?
3.Questions about sampling rate of the module Radio.
We use the latest rfnoc branch,logic and software code, and when we use
the following code:
pt_custom_usrp = uhd::usrp::multi_usrp::make(device_addrs[0]);
pt_custom_usrp->set_tx_rate(rate);
We encountered the following print when configuring tx_rate:
Setting TX Rate: 10.000000 Msps...
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 10.000000 MSps
Actual sample rate: 200.000000 MSps
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 10.000000 MSps
Actual sample rate: 200.000000 MSps
We want to know the reason. And how can we use API library function to
achieve our goals?
4.Baseband IQ data interface and radio connection.
We have implemented the CE module to generate the modulated IQ data,
and we need to connect it to the radio, can it be directly connected?
Does the baseband need to follow a certain data format when the IQdata
is sent to the radio, for example, I0Q0I1Q1?
5.Rationality of module connection mode.
As shown below, it is directly connected through internal FPGA pins
from CE A to CE B.
A has two outputs,one is hanging on the Xbar and the other is directly
connected to the input of CE B.
Similarly, CE B also has two ouputs, one is hanging on the Xbar and the
other is directly connected to the output of CE A.
The implementation of CE B function is similar to null source module.In
the host side, we connect CE A to Radio through
the method 'connect'. tx_streamer connects module CE A, while rx_streamer
connects module CE B.
Is this connection mode feasible in the framework of rfnoc? If not, is
there any problem the connection mode will lead to?
Any more, what is your suggestion for the implementaion of this toplogy?
best regards
Jon
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/0a970c41/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b1.png
Type: image/png
Size: 6838 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/0a970c41/attachment-0001.png>
------------------------------
Message: 7
Date: Wed, 28 Sep 2016 14:38:16 +1000
From: Walter Maguire <[email protected]>
To: [email protected]
Subject: [USRP-users] Issue with DmaFIFO uhd::lookup_error'
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all
I am using this commit c41b8330f7d700feeae4819e7f7241fe3fd2bc7b on the
rfnoc-devel branch.
This should be the top of the commits.
If I build the standard FPGA set with this commit all is fine. However,
if I modify file rfnoc_ce_auto_inst_e310.v to have only 3 CEs as shown
below and rebuild the uhd_usrp_probe command fails as shown below.
root@ettus-e3xx-sg1:~# uhd_usrp_probe --init-only
linux; GNU C++ version 4.9.2; Boost_105700;
UHD_004.000.000.rfnoc-devel-641-g8773fb2c
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Initializing core control (global registers)...
-- Performing register loopback test... pass
-- Initializing AD9361 using hard SPI core...OK
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 0 to be stream 0
-- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:10)...O
-- Port 16: Found NoC-Block with ID 12AD100000000000.
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- [E300] Setting up dest map for host ep 1 to be stream 1
-- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:11)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- [RFNoC Factory] Using controller key 'E3XXRadio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] block_ctrl_base::clear()
-- [0/Radio_0] node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] e3xx_radio_ctrl_impl::ctor()
-- Setting time source to internal
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- [0/Radio_0] Creating internal GPIOs...
-- [0/Radio_0] Setting tick rate...
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 2 to be stream 2
-- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:20)...OK
-- Port 32: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
-- [0/FIFO_0] block_ctrl_base::clear()
-- [0/FIFO_0] node_ctrl_base::clear()
-- [0/FIFO_0] block_ctrl_base::_clear()
-- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 3 to be stream 3
-- Setting up NoC-Shell Control for port #0 (SID: 00:03>02:30)...OK
-- Port 48: Found NoC-Block with ID F1F0D00000000000.
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
-- [E300] Setting up dest map for host ep 4 to be stream 4
-- Setting up NoC-Shell Control for port #1 (SID: 00:04>02:31)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
-- [RFNoC Factory] Using controller key 'DmaFIFO' and block name 'DmaFIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0D00000000000 Block ID: 0/DmaFIFO_0
-- [0/DmaFIFO_0] block_ctrl_base::clear()
-- [0/DmaFIFO_0] node_ctrl_base::clear()
-- [0/DmaFIFO_0] block_ctrl_base::_clear()
-- [0/DmaFIFO_0] block_ctrl_base::_clear()
terminate called after throwing an instance of 'uhd::lookup_error'
what(): LookupError: Path not found in tree: /mboards/0/tx_dsps/0
Aborted
The changes to the rfnoc_ce_auto_inst_e310.v file are as follows
localparam NUM_CE = 2; // Must be no more than 14 (2 ports taken by
radio core & PS-PL DMA).
wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
wire [63:0] ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
wire [NUM_CE-1:0] ce_o_tlast, ce_o_tvalid, ce_o_tready,
ce_i_tlast, ce_i_tvalid, ce_i_tready;
wire [63:0] ce_debug[0:NUM_CE-1];
// Flattern CE tdata arrays
genvar k;
generate
for (k = 0; k < NUM_CE; k = k + 1) begin
assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
end
endgenerate
wire ce_clk = radio_clk;
wire ce_rst = radio_rst;
noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.ce_clk(ce_clk), .ce_rst(ce_rst),
.i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]),
.i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
.o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]),
.o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
.debug(ce_debug[0]));
noc_block_axi_dma_fifo inst_noc_block_axi_dma_fifo (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.ce_clk(ce_clk), .ce_rst(ce_rst),
.i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]),
.i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]),
.o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]),
.o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]),
.debug(ce_debug[1]));
I would be grateful for any feedback on this issue.
Regards
Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/27cd53ee/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 28 Sep 2016 08:41:56 +0200 (CEST)
From: [email protected]
To: Philip Balister <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Dual RX acquisition with E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Thanks, Philip
Alex
----- Mail original -----
De: "Philip Balister" <[email protected]>
?: "alex dtd" <[email protected]>, [email protected]
Envoy?: Mardi 27 Septembre 2016 18:27:42
Objet: Re: [USRP-users] Dual RX acquisition with E310
On 09/27/2016 08:01 AM, alex.dtd--- via USRP-users wrote:
> Hi Marcus,
>
> I'm back with the same problem.
>
> In my previous test, UHD versions on desktop and E310 seems to be different.
> Indeed, UHD version on E310 is 3.9.2-0-unknown (Why "unknown", it's unknown
> :-) )
> I use 3.9.2-0-gf18abe54 on my desktop. So, I cross-compiled the same for E310
> and "link it" using sshfs (cf.
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312 )
Regarding the "unknown" ....
For historical reasons, when uhd builds it insists on inserting the
actual git revision into the version string. But, the OpenEmbedded
recipe for the package on the E310 uses the actual release tarball to
build UHD. So the piece of cmake that runs git to figure out the hash of
the git repo fails because it isn't being run in a git repo.
Philip
>
> I was hoping it could be the solution, but ... in fact, no!
>
> The problem is always here.
>
> I launch programs on E310 using "sshfs":
> 1) "rx_samples_to_file" for individual frontend (i.e., A:A or A:B), it's a
> success.
> 2) My "dualRx_samples_to_file" (source code where you didn't find anything
> wrong), it's failure!
> Datas from 2nd channel (A:B) are good BUT received in buf_ptr[0] instead of
> buf_ptr[1].
> buf_ptr[1] is filled by 0.
>
> I really try to find a solution by myself but I still need help.
>
> Best regards.
>
> Alex
>
>
>
>> Date: Tue, 23 Aug 2016 09:32:59 +0200
>> From: Marcus M?ller <[email protected]>
>> To: [email protected]
>> Subject: Re: [USRP-users] Dual RX acquisition with E310
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Hi Alex,
>>
>> I'd expect the SD card to be about as fast if not faster than the
>> network interface.
>>
>> I wasn't asking you to test the software on the E310 itself because of
>> higher speed, however ? it would have removed the additional complexity
>> of using the network mode!
>>
>> Yes, I've looked through your source code and couldn't find something
>> immediately, especially since you said it worked with X310, that
>> would've surprised me.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 23.08.2016 09:23, alex.dtd--- via USRP-users wrote:
>>> Hi Marcus,
>>>
>>> First of all, thanks for the quick answer.
>>>
>>> No, I don't test it on the E310 itself because the SD card write speed is
>>> too low.
>>>
>>> I agree that network mode for E310 is just for debug but the rate for the
>>> slowest testing dual RX is only 50k/channel <=> 800kB/s ...
>>> As I said in my previous message, I checked "/rx_samples_to_file/" @
>>> ~1Msamples/s <=> 8MB/s. So, it's not the problem!
>>>
>>> The problem should be:
>>> 1) I don't use the UHD library well.
>>> 2) Pb in UHD library.
>>> 3) Pb in E310 firmware.
>>>
>>> Did you have a look on my source code? Something wrong?
>>>
>>> Best regards
>>>
>>> Alex
>>>
>>>
>>> _______________________________________________
>>> 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/20160928/230b0187/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 28 Sep 2016 14:56:38 +0200
From: Nives Novkovi? <[email protected]>
To: Sugandha Gupta <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Implementing design on FPGA in X310
Message-ID:
<CALUTkDDaDBqOFtkJxD=xM-LDQ7Nubu8ihqOF=vgzykqaqcv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sugandha,
thank you for your reply. Now for the implementation I need the pin layout
information written in .xdc file, as far as I've seen. But I cannot seem to
find it for X310. I've searched on
https://github.com/EttusResearch/fpga/tree/master/usrp3/top/ , but could
find only information for the E300. Am I looking in the wrong place?
Kind regards,
Nives
2016-09-23 18:59 GMT+02:00 Sugandha Gupta <[email protected]>:
> Hello Nives
>
> You can use RFNoC to add your own functionality to the existing code.
> Checkout the knowledge base article on it.
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> Let me know if you have any questions. Will be happy to help you.
>
> Thanks
> Sugandha
>
>
>
> On Fri, Sep 23, 2016 at 1:57 AM, Nives Novkovi? via USRP-users <
> [email protected]> wrote:
>
>> Hello again,
>>
>> I was wondering about implementing new functionalities on the FPGA in
>> X310. If I would like the FPGA to maintain its current funcionality and I
>> want to add something new but without erasing the pre-existing one, how do
>> I do that? Thank you in advance.
>>
>> Kind regards,
>> Nives
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> Sugandha Gupta
> Staff Software Engineer
> Ettus Research
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/1e5919c7/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 28 Sep 2016 16:43:41 +0200 (CEST)
From: [email protected]
To: [email protected]
Subject: [USRP-users] Understand branch name into git repo
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi everybody,
The UHD git repo contains pairs of branch which are "link" with the same
version.
For example: "release_003_009_005" and "003_009_005_rc1"
What's the difference?
Thanks
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/30d66100/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 28 Sep 2016 11:15:59 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>,
[email protected]
Subject: Re: [USRP-users] Understand branch name into git repo
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> For example: "release_003_009_005" and "003_009_005_rc1"
> What's the difference?
rc1 is a release candidate (think of it as the final test run), and the
release is the actual 003_009_005. Unless you have a need, go with the
release (not the rc).
------------------------------
Message: 12
Date: Wed, 28 Sep 2016 11:17:22 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Understand branch name into git repo
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 09/28/2016 10:43 AM, alex.dtd--- via USRP-users wrote:
> Hi everybody,
>
> The UHD git repo contains pairs of branch which are "link" with the
> same version.
>
> For example: "release_003_009_005" and "003_009_005_rc1"
>
> What's the difference?
>
> Thanks
>
> Alex
>
RC1 is a "Release Candidate", which is then superseded by the actual
release, without the "_rcX" suffix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160928/d6b72d88/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 73, Issue 26
******************************************
