Re: [USRP-users] Passing arguments to an RFNOC block

2019-03-01 Thread Paul Boven via USRP-users

Hi again,

After way too much time spent trying to debug my issues, and renaming 
all the variables, I wasn't getting anywhere. Then I discovered xmllint 
which pointed out a few (!) more xml errors in a completely different 
section of the rfnocblock XML file. After fixing this, I've got the 
resampler part working.


Regards, Paul Boven.

On 28/02/2019 10:30, Paul Boven via USRP-users wrote:

Hi Jonathon,

Thanks for looking at the block, and spotting the mistake.
Unfortunately that doesn't stop the swig part from failing, so I'll keep 
digging further.


Regards, Paul Boven.

On 28/02/2019 04:19, Jonathon Pendlum wrote:

Hi Paul,

Your Nocscript has an error on line 47, you are a missing a comma: 
LE($config 1) should be LE($config, 1). That may not be the source of 
your issue, but try fixing that first.


Jonathon

On Thu, Feb 28, 2019 at 1:14 AM Paul Boven via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


    Hi everyone,

    As part of the VLBI[1] backend that I'm making in RFNOC, my first 
step

    is to make a rational resampler. It takes the 100MS/s signal from a
    TwinRX, and reduces it to 80MS/s. This can be done with a 5:4
    resampler.
    In order to make this work, I'm using the axi_rate_change block.

    Although the block works in simulation, I keep running into problems
    with the GRC integration, in particular SWIG throwing run-time 
errors.


    The problem seems to be in the way that the arguments (N, M, config)
    are
    passed around, but studying other blocks like the DDC block hasn't
    provided the clues for me to get past this hurdle.

    The resampler itself does work, which I tested by having it emit 
zeroes

    instead of the 'deleted' samples, and using a 'keen 1 in N' in GRC
    itself.

    At the moment, the block exits in VLBI_swig.py in set_arg:
    return _VLBI_swig_resamplerd5x4_sptr_set_arg(self, *args)
    RuntimeError: SyntaxError: Parsing Stopped at: $N, 5)

    If you're familiar with RFNOC, can you please have a look at:

    http://www.jive.nl/~boven/rfnoc-VLBI

    It contains the source, and also a compiled bitfile for the X310 for
    your convenience (but use at your own risk, of course).

    Regards, Paul Boven.

    [1] Very Long Baseline Interferometry

    ___
    USRP-users mailing list
    USRP-users@lists.ettus.com 
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] Hardware clocks, X310

2019-03-01 Thread Cherif Diouf via USRP-users
Ian and Jason,

So if I understand Although if it possible to work with different clock 
domains, and while some examples are available for such scenario,
it would be preferable to keep  working with the same 200 MHz reference and 
only switch to another frequency only when it is  really needed.

Many thanks for the info.
Cherif



From: Ian Buckley 
Sent: donderdag 28 februari 2019 17:36
To: Cherif Diouf 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Hardware clocks, X310

Cherif,
1) Changing the radio clock frequency is not simple and would leave you an 
immense amount of knock on problems to address.
2) ADC and DAC are tightly coupled to the radio clk, they run on low jitter 
versions of the same clock.
3) Absolutely, and that is the beauty of streaming style packet buses like the 
AXI4 stream protocol that the X310 is built around. It's a relatively easy task 
to cross this type of bus into a different clock domain, do work on the 
payload, and cross it back. The modular RTL code supplied by Ettus already 
contains all the functional blocks you would need to do this.

So saying that it's always a good thing to minimize the number of clock domains 
in a design as it adds significant overhead and complexity, not to mention a 
verification burden. Evaluate hard if you really need another frequency, 
especially when its an integer fraction of a clock that already exists. 200MHz 
is not a hard frequency to attain in Virtex-7 with well designed logic.
-Ian


From: Jason Matusiak 
Sent: donderdag 28 februari 2019 17:38
To: usrp-users@lists.ettus.com; Cherif Diouf 
Subject: Re: Hardware clocks, X310

Cherif.  I will attempt to take a stab at a few of your questions.  Don't take 
my answers as 100% right

1 - All the blocks run at the same rate, but I am pretty sure you can implement 
an MMCM within your block to lower the rate for your needs and then back up to 
the crossbar rate.  Don't quote me, but I feel like I had this conversation 
with someone a few years back on the mailing list.
2 - The ADC/DAC are tied to the master clock rate (in the case of the X310, 
either 186.32MHz, or 200MHz)
3 - I don't believe so unless you do what I mentioned in the first comment.

All that said, I believe a lot of stuff can be tweaked under the hood, but it 
is hard to say what that will break, and it isn't exactly supported.


From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
on behalf of Cherif Diouf via USRP-users 
mailto:usrp-users@lists.ettus.com>>
Sent: Thursday, February 28, 2019 10:05 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Hardware clocks, X310


Hello guys,



I am a researcher working with the X310 USRP. I have a couple of questions 
regarding the Hardware clocks.

The bus_clock and radio_clk are by default respectively set at 166 MHz and 200 
MHz.

And if I am right the crossbar clock ce_clk is also at 200 MHz. Is there a 
solution to bring it down to ce_clk = 50 MHz, in that case

1)  Does it mean that all the Kintex XC410T blocks will run at 50 MHz ? Is 
this safe?

2)   What about the ADC and DAC and their sampling clock?

3)  Finally can we have different RFnoc blocks running at different clock 
frequencies and still have the  crossbar  running at a given clock frequency?



Best Regards

Cherif
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


[USRP-users] Problems getting started with N310 (Could not find MAC address for IP address 192.168.20.1)

2019-03-01 Thread Janos Buttgereit via USRP-users
Hi,

I’m about to port an application that was working with a setup of two X300 
devices to a new N310 device.

For a first step the N310 should simply be used to stream four RF channels to a 
host. However before using it for streaming I wanted to perform some simple 
operations like getting the device tree through the uhd_usrp_probe command, 
which fails at the moment. I installed a current version of the SD card image a 
few days ago and my host is running an UHD version compiled from the tip of the 
UHD repo a few days ago. I suspect this is a network config error, however I’m 
not sure and sadly I’m no networking expert.

A brief overview of my setup:
A host PC, running Ubuntu equipped with a 2x10Gbit Ethernet card and two usual 
Gbit Ethernernet cards. One 1Gbit ethernet port is used for internet 
connection, the other one is connected to a Wifi Router, running a DHCP server 
in the address space 192.167.1.x. The N310 is connected to this router, the 
DHCP server assigns the address 192.167.1.100 to the N310. Pinging the device 
works as well as establishing an SSH connection to it. The two SFP ports are 
connected to the 10Gbit card of the host, on the host side those ports have the 
IP address 192.168.10.1 and 192.168.20.1. I loaded an XG FPGA image to use both 
SFP ports at 10Gbit speed and they respond to pings. To summarize, this is the 
current network config as reported by the system:

sdr@NTLabDSP:~$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp4s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 00:0a:f7:81:d5:26 brd ff:ff:ff:ff:ff:ff
inet 192.167.1.102/24 brd 192.167.1.255 scope global dynamic enp4s0
   valid_lft 4745sec preferred_lft 4745sec
inet6 fe80::2ddf:29cd:ab15:aa68/64 scope link 
   valid_lft forever preferred_lft forever
3: eno1:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 98:90:96:c6:92:3c brd ff:ff:ff:ff:ff:ff
inet 10.211.21.102/23 brd 10.211.21.255 scope global dynamic eno1
   valid_lft 3812sec preferred_lft 3812sec
inet6 2a02:c6a0:3071:53fc:f1:1e14:9cf0:3521/128 scope global dynamic 
   valid_lft 904sec preferred_lft 604sec
inet6 fe80::58d:8415:1a20:604e/64 scope link 
   valid_lft forever preferred_lft forever
4: enp5s0f0:  mtu 8000 qdisc mq state UP group 
default qlen 1000
link/ether 00:1b:21:bc:19:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 scope global enp5s0f0
   valid_lft forever preferred_lft forever
inet6 fe80::21b:21ff:febc:1996/64 scope link 
   valid_lft forever preferred_lft forever
5: enp5s0f1:  mtu 8000 qdisc mq state UP group 
default qlen 1000
link/ether 00:1b:21:bc:19:97 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.1/24 scope global enp5s0f1
   valid_lft forever preferred_lft forever
inet6 fe80::21b:21ff:febc:1997/64 scope link 
   valid_lft forever preferred_lft forever

This host setup used to work flawlessly with the two X300 units.

Now when trying to run uhd_usrp_probe I think I got that I need to specify all 
three addresses, the primary and secondary address of the SFP ports that handle 
streaming as well as the management port address. So I pass those three 
parameters as args to uhd_usrp_probe. However when doing so, I get the error 
"Could not find MAC address for IP address 192.168.20.1“ which seems a bit 
weird to me, as to my knowledge a MAC address is a hardware property of the 
network interface and therefore cannot be misconfigured. So is this a network 
configuration error or am I doing something different wrong? For the sake of 
completeness, here is the complete output of uhd_usrp_probe:

sdr@NTLabDSP:~$ uhd_usrp_probe 
--args="addr=192.168.10.2,second_addr=192.168.20.2,mgmt_addr=192.167.1.100"
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.15.0.git-13-g52138314
[INFO] [MPMD] Initializing 1 device(s) in parallel with args: 
mgmt_addr=192.167.1.100,type=n3xx,product=n310,serial=316CD18,claimed=False,addr=192.168.10.2,second_addr=192.168.20.2
[INFO] [MPM.PeriphManager] init() called with device args 
`product=n310,mgmt_addr=192.167.1.100,second_addr=192.168.20.2,clock_source=internal,time_source=internal'.
[ERROR] [RPC] Could not find MAC address for IP address 192.168.20.1
[ERROR] [MPMD] Failure during block enumeration: RuntimeError: Error during RPC 
call to `commit_xport'. Error message: Could not find MAC address for IP 
address 192.168.20.1
[ERROR] [MPM.RPCServer] Uncaught exception in method commit_xport :Could not 
find MAC address for IP address 192.168.20.1 
 Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/usrp_mpm/rpc_server.py", line 182, in 
new_claimed_function
return function(*args)
  File "/us

Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Jason Matusiak via USRP-users
Probably not the approved way, but I made an FFT 2048 block a while back.  I 
didn't much with packet sizes or anything, I just sucked in two 1024 packets, 
did the FFT, and then sent two 1024 packets back out.  It seemed to work fine.  
The only issue is that you have to remember downstream that you need 2 vectors 
in a row to get your data.


From: USRP-users  on behalf of Rob Kossler 
via USRP-users 
Sent: Thursday, February 28, 2019 4:08 PM
To: usrp-users
Subject: [USRP-users] RFNoC FFT size > 1024

Hi,
I would like to implement an RFNoC FFT that can work for lengths > 1024.  
Here's what I think I know:

  *   Current size for CE-to-CE packets is restricted to 8000 bytes (2000 
samples)
  *   Current RFNoC FFT size is tied to packet size and thus 1024 is the max 
FFT size that can fit in a packet

After reviewing previous posts and Xilinx FFT IP core documentation, it seems 
that all I need to do is add packet resize logic at the input and output of the 
block.  Specifically, I am thinking of using "packet_resizer.v" at both input 
and output (but only modifying tuser in the output instance).

Questions

  *   Is this a good approach?
  *   Anything special that I need to take care of?
  *   Does the selection of FFT architecture (pipelined, radix-4, etc) have any 
relevance concerning this issue?

Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Rob Kossler via USRP-users
Turns out there was a surprisingly simple modification to allow FFTs longer
than 1024.  The axi_wrapper will automatically resize packets for you if
you configure it to do so.  All I had to do was set RESIZE_OUTPUT_PACKET(1)
(and keep SIMPLE_MODE(1)) which caused the output packets to be resized to
match the input packet size.  I was able to then run 2048 and 4096 pt FFTs
successfully (& producing the expected results) and I could use any packet
size I wanted going in and out of the overall noc block.

I did not even have to resize the packets going into the FFT because the
FFT doesn't care about input packet size with the caveat that it generates
various "bad size" events if it detects mismatches.  Since I am not
monitoring such events, it doesn't really matter. And, if I did care about
these bad size events, the fix is simply to add RESIZE_INPUT_PACKET(1) and
set the desired resize value (i.e., the FFT length) using the axi_wrapper
"m_axis_pkt_len_t*" inputs.

With such a simple fix, it seems that Ettus should permanently change
noc_block_fft.v to incorporate this.  Another change would be to modify
this block so that MAX_FFT_SIZE_LOG2 is 12 rather than its current setting
of 11 in order to match the axi_fft IP core set for a max FFT of 4096.

Rob

On Fri, Mar 1, 2019 at 11:24 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Probably not the approved way, but I made an FFT 2048 block a while back.
> I didn't much with packet sizes or anything, I just sucked in two 1024
> packets, did the FFT, and then sent two 1024 packets back out.  It seemed
> to work fine.  The only issue is that you have to remember downstream that
> you need 2 vectors in a row to get your data.
>
> --
> *From:* USRP-users  on behalf of Rob
> Kossler via USRP-users 
> *Sent:* Thursday, February 28, 2019 4:08 PM
> *To:* usrp-users
> *Subject:* [USRP-users] RFNoC FFT size > 1024
>
> Hi,
> I would like to implement an RFNoC FFT that can work for lengths > 1024.
> Here's what I think I know:
>
>- Current size for CE-to-CE packets is restricted to 8000 bytes (2000
>samples)
>- Current RFNoC FFT size is tied to packet size and thus 1024 is the
>max FFT size that can fit in a packet
>
> After reviewing previous posts and Xilinx FFT IP core documentation, it
> seems that all I need to do is add packet resize logic at the input and
> output of the block.  Specifically, I am thinking of using
> "packet_resizer.v" at both input and output (but only modifying tuser in
> the output instance).
>
> Questions
>
>- Is this a good approach?
>- Anything special that I need to take care of?
>- Does the selection of FFT architecture (pipelined, radix-4, etc)
>have any relevance concerning this issue?
>
> Rob
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Jonathon Pendlum via USRP-users
Hi Rob,

I'm glad you found those options useful. Unfortunately, there are a number
of corner cases that those options do not handle. You can run into
synchronization issues when overflows and dropped packets occur. In the
overflow case, if one occurs while the FFT is being filled then the next
FFT output will be incorrect. In the dropped packet case, the received FFT
frames could end up shifted between two FFT frames. The dropped packet case
is by the far worse of the two. The block also does not handle the packet
header correctly when FFTs are split between multiple packets. For example,
EOBs will not cause the FFT core to reset, so the next burst could have an
incorrect FFT output at the beginning. Most of these issues can be worked
around or even ignored, but I think for general usage the block will need
to be updated to handle them properly.

Jonathon




On Sat, Mar 2, 2019 at 2:41 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Turns out there was a surprisingly simple modification to allow FFTs
> longer than 1024.  The axi_wrapper will automatically resize packets for
> you if you configure it to do so.  All I had to do was set
> RESIZE_OUTPUT_PACKET(1) (and keep SIMPLE_MODE(1)) which caused the output
> packets to be resized to match the input packet size.  I was able to then
> run 2048 and 4096 pt FFTs successfully (& producing the expected results)
> and I could use any packet size I wanted going in and out of the overall
> noc block.
>
> I did not even have to resize the packets going into the FFT because the
> FFT doesn't care about input packet size with the caveat that it generates
> various "bad size" events if it detects mismatches.  Since I am not
> monitoring such events, it doesn't really matter. And, if I did care about
> these bad size events, the fix is simply to add RESIZE_INPUT_PACKET(1) and
> set the desired resize value (i.e., the FFT length) using the axi_wrapper
> "m_axis_pkt_len_t*" inputs.
>
> With such a simple fix, it seems that Ettus should permanently change
> noc_block_fft.v to incorporate this.  Another change would be to modify
> this block so that MAX_FFT_SIZE_LOG2 is 12 rather than its current setting
> of 11 in order to match the axi_fft IP core set for a max FFT of 4096.
>
> Rob
>
> On Fri, Mar 1, 2019 at 11:24 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> Probably not the approved way, but I made an FFT 2048 block a while
>> back.  I didn't much with packet sizes or anything, I just sucked in two
>> 1024 packets, did the FFT, and then sent two 1024 packets back out.  It
>> seemed to work fine.  The only issue is that you have to remember
>> downstream that you need 2 vectors in a row to get your data.
>>
>> --
>> *From:* USRP-users  on behalf of Rob
>> Kossler via USRP-users 
>> *Sent:* Thursday, February 28, 2019 4:08 PM
>> *To:* usrp-users
>> *Subject:* [USRP-users] RFNoC FFT size > 1024
>>
>> Hi,
>> I would like to implement an RFNoC FFT that can work for lengths > 1024.
>> Here's what I think I know:
>>
>>- Current size for CE-to-CE packets is restricted to 8000 bytes (2000
>>samples)
>>- Current RFNoC FFT size is tied to packet size and thus 1024 is the
>>max FFT size that can fit in a packet
>>
>> After reviewing previous posts and Xilinx FFT IP core documentation, it
>> seems that all I need to do is add packet resize logic at the input and
>> output of the block.  Specifically, I am thinking of using
>> "packet_resizer.v" at both input and output (but only modifying tuser in
>> the output instance).
>>
>> Questions
>>
>>- Is this a good approach?
>>- Anything special that I need to take care of?
>>- Does the selection of FFT architecture (pipelined, radix-4, etc)
>>have any relevance concerning this issue?
>>
>> Rob
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


Re: [USRP-users] RFNoC FFT size > 1024

2019-03-01 Thread Sylvain Munaut via USRP-users
> but I think for general usage the block will need to be updated to handle 
> them properly.

Just my 2ct, but I think RFNoC globally would benefit from a way to
handle larger vector size split across packets.Even in some limited
form, like for instance some config register that would say that
packets always go in pair, or group of 4 and then using the sequence
number LSB as the sync or something like that.Cheers,   Sylvain
On Sat, Mar 2, 2019 at 1:28 AM Jonathon Pendlum via USRP-users
 wrote:

Cheers,

  Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com