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. RFNoC AXI Wrapper (Muhammad, Siraj)
2. Re: RFNoC AXI Wrapper (Jonathon Pendlum)
3. Re: RFNoC AXI Wrapper (Muhammad, Siraj)
4. sensors values access when string representation in gnu radio
(LEMENAGER Claude)
5. Re: writing a register in FPGA from host in X310 (device 3 i
guess) (Samuel Berhanu)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Jun 2017 19:18:12 +0000
From: "Muhammad, Siraj" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC AXI Wrapper
Message-ID:
<by1pr03mb1338efcfc6355f16bcd4c902cd...@by1pr03mb1338.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi All!
I am studying the FPGA portion of a custom RFNoC block. I did follow the
example of a gain block in the tutorial and I am trying to experiment with the
code and I have a few question.
1- When simulating a custom block I noticed that the data coming from the
AXI wrapper is interleaved by zeros. I just want to know why is that and is it
always the case?
2- In the HDL testbench SPP is defined as the number of samples per packet.
Later on in the code, only half were pushed into a packet. Does this have
something to do with my previous question? Accounting for the interleaved zeros?
3- How is the number of samples per packet determined when code is
compiled? For example, if I set the FFT block to 1024 bins, does this make the
SPP = 1024?
Thank you!
Siraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/35228587/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 15 Jun 2017 14:24:03 -0700
From: Jonathon Pendlum <[email protected]>
To: "Muhammad, Siraj" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC AXI Wrapper
Message-ID:
<CAGdo0uTs0j=ULFE8FA7aOGd02PywOAqmFi=C=m1fh40+zdu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
> 1- When simulating a custom block I noticed that the data coming from
> the AXI wrapper is interleaved by zeros. I just want to know why is that
> and is it always the case?
>
That is expected. "send_payload.push_back(64'(i));" is sending 2 samples
(SC16 samples are 32 bits) where one will always be 0 and the other is just
the index.
> 2- In the HDL testbench SPP is defined as the number of samples per
> packet. Later on in the code, only half were pushed into a packet. Does
> this have something to do with my previous question? Accounting for the
> interleaved zeros?
>
See above how it is 2 samples at a time.
> 3- How is the number of samples per packet determined when code is
> compiled? For example, if I set the FFT block to 1024 bins, does this make
> the SPP = 1024?
>
SPP depends on if your block cares about packet size or not. Most blocks
don't care about SPP, so it those cases it can be whatever you want. The
FFT block is a special case, it needs SPP to be equal to the FFT size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/a00f491d/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 15 Jun 2017 21:27:28 +0000
From: "Muhammad, Siraj" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC AXI Wrapper
Message-ID:
<by1pr03mb13389df8229d04e7d3553d6ecd...@by1pr03mb1338.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Thank you very much!
Siraj
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Thursday, June 15, 2017 4:24 PM
To: Muhammad, Siraj <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC AXI Wrapper
1- When simulating a custom block I noticed that the data coming from the
AXI wrapper is interleaved by zeros. I just want to know why is that and is it
always the case?
That is expected. "send_payload.push_back(64'(i));" is sending 2 samples (SC16
samples are 32 bits) where one will always be 0 and the other is just the index.
2- In the HDL testbench SPP is defined as the number of samples per packet.
Later on in the code, only half were pushed into a packet. Does this have
something to do with my previous question? Accounting for the interleaved zeros?
See above how it is 2 samples at a time.
3- How is the number of samples per packet determined when code is
compiled? For example, if I set the FFT block to 1024 bins, does this make the
SPP = 1024?
SPP depends on if your block cares about packet size or not. Most blocks don't
care about SPP, so it those cases it can be whatever you want. The FFT block is
a special case, it needs SPP to be equal to the FFT size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170615/ca43cb82/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 16 Jun 2017 16:46:06 +0200
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] sensors values access when string representation
in gnu radio
Message-ID:
<59957d668d245c4eb38e8f85c054e90112dab24...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
Developing a control box under gnu radio, the sensor_value_t type seems not
defined in.
I have seen usage of boost bind() to recover lock (get_mboard_sensor()) in
USRP_SINK impl but what when I want to obtain gpgga message (e.g. to set the
system time or issue timed commands)
Thanks for support
Claude Lem?nager
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170616/76813551/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 16 Jun 2017 11:21:16 -0400
From: Samuel Berhanu <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] writing a register in FPGA from host in X310
(device 3 i guess)
Message-ID:
<CAEyq4Ndh702HUc=dv2ppbd7po3_6fmliwuzpvxwlrv37h-f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
i am working on the pre-rfnoc development. if it were the post-rfnoc
development, the fosphor example would be a great guide b/c it looks like
off of the axi_wrapper base address, there is space available for user
registers.
I could potentially use the x300_reg.hpp. i was going to try to implement
that in, but now, i am not sure about using multi-usrp since x300_impl
(which is under device/device3 inheritance) is what those register
addresses are refered in
so, potentially, i am guessing i would have to create a device without
using multi-usrp?
On Thu, Jun 15, 2017 at 11:53 AM, Jason Matusiak <
[email protected]> wrote:
> 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]>
> 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
> [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/20170616/8e1beb0f/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 16
******************************************
