Re: [USRP-users] X300 FP GPIO with RFNoC API
Hey Ryan,
I have a PR that adds custom I/O support for RFNoC blocks with FPGPIO
support as part of that. It is still being looked at internally at Ettus,
but I'll send you a patch to try it out.
Jonathon
On Fri, Oct 5, 2018, 5:59 AM Ryan Marlow via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Working on a project with custom RFNoC blocks where I need to use the FP
> GPIO. I've searched the mailing lists and seen previously suggested options
> like reconnecting fp gpio to the custom block, or generating timed command
> packets from my block to send to the radio block. Both those options seem
> feasible but what seems to be the most straightforward option is to just
> use the uhd api call: set_gpio_attr. Like in this example:
> https://files.ettus.com/manual/page_gpio_api.html
> I tried instantiating a multi_usrp object in my rfnoc app, but that
> doesn't seem like the right path and produces some unexpected results.
> I noticed that the radio_ctrl API includes that function but all it does
> is
>
>> throw uhd::not_implemented_error("set_gpio_attr was not defined for
>> this radio");
>>
> Is there some other way using the device3/RFNoC api to use the
> set_gpio_attr or some similar function to configure the gpio from software?
> Or more importantly is it even possible when using RFNoC to use those
> software functions?
> Thanks,
> Ryan Marlow
>
> --
> Ryan L. Marlow
> R L Marlow Consulting LLC
> rlmarlow.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
[USRP-users] X300 FP GPIO with RFNoC API
Working on a project with custom RFNoC blocks where I need to use the FP
GPIO. I've searched the mailing lists and seen previously suggested options
like reconnecting fp gpio to the custom block, or generating timed command
packets from my block to send to the radio block. Both those options seem
feasible but what seems to be the most straightforward option is to just
use the uhd api call: set_gpio_attr. Like in this example:
https://files.ettus.com/manual/page_gpio_api.html
I tried instantiating a multi_usrp object in my rfnoc app, but that doesn't
seem like the right path and produces some unexpected results.
I noticed that the radio_ctrl API includes that function but all it does is
> throw uhd::not_implemented_error("set_gpio_attr was not defined for
> this radio");
>
Is there some other way using the device3/RFNoC api to use the
set_gpio_attr or some similar function to configure the gpio from software?
Or more importantly is it even possible when using RFNoC to use those
software functions?
Thanks,
Ryan Marlow
--
Ryan L. Marlow
R L Marlow Consulting LLC
rlmarlow.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Messaging the DDC
Well, I tried to send out a message that was shaped like the callback, but it seems to be getting ignored. The first part was the string "freq", the second part was the frequency. When that didn't work, I added a third part that was the channel (1). I tried dictionaries and tuples, but no luck. Any guesses? - Original Message - Subject: RE: Re: [USRP-users] Messaging the DDC From: "Jason Matusiak" Date: 10/3/18 2:58 pm To: "Marcus Mller" , usrp-users@lists.ettus.com Marcus, Looking a little closer, I am a little confused. I can make the change, and that allows the message block to appear in GRC, but I am thinking that I need to uncomment the argument commands that set the DDS value, right? I don't see how it would work otherwise (Though it can be poked in via a variable, so I am not sure why that would work). - Original Message - Subject: RE: Re: [USRP-users] Messaging the DDC From: "Jason Matusiak" Date: 10/3/18 9:27 am To: "Marcus Mller" , usrp-users@lists.ettus.com Sorry, Marcus, I was out yesterday and then missed these responses. That is great! I'll give it a try today and report back! - Original Message - Subject: Re: [USRP-users] Messaging the DDC From: "Marcus Mller via USRP-users" Date: 9/30/18 4:47 pm To: usrp-users@lists.ettus.com Hi Jason, I was about to write code, but then realized: gr-ettus' Block impl already has what you need, the message port "rfnoc", which'll accept messages in the PMT dict format. You can extract the shape of information you need to send in from the tags in uhd_rfnoc_ddc.xml. I'm attaching what I hope will fix your problem as a patch (use with `git apply` from within gr-ettus). We'll most likely upstream a more general changeset. Best regards, Marcus On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote: > I have a block that outputs a message with a frequency. I would love > to be able to set the frequency adjustment in the RFNoC DDC, but I > don't see a way to do it it automagically. > > I am guessing that there is no way to do it even though it can be set > from a variable slider easily. Is there an option I am missing? > ___ > 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] B200 FPGA usage between 3.9 and 3.13
Hi Sylvain, You are absolutely correct. We are looking at splitting the axi_packet_gate into a buffer and a packet gate. That should effectively reduce the address FIFO to a reasonable size and reduce the resource usage back to reasonable levels. Regards, Michael On Thu, Oct 4, 2018 at 4:10 AM Sylvain Munaut <246...@gmail.com> wrote: > Hi Michael, > > > Thank you for letting us know. That is quite a jump in utilization. We > will take a look when we have some time. > > > > We did recently make recent bug fixes in axi_packet_gate. It looks like > that, and possibly other changes, inadvertently increased resource > utilization more than expected for B200. Our priority is always first to > make sure the FPGA images successfully build with the bug fixes so we can > get those bug fixes out to users as soon as possible. We do try to > minimize resource utilization, but that is a secondary priority. > > AFAICT, it's all due to the new "address FIFO". But that FIFO seems to > be setup to be unreasonably large. > > I mean it can store as many addresses as data words ... while AFAICT > it only has to store one address per packet in the buffer, so reducing > it to say 32 entries should be enough. This way 6 bits can fit in 1 > CLB using 32x2 distrams instead of using block rams. > > Cheers, > > Sylvain > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Software changes for new FPGA registers B205
Hi, Does the UHD Python API support reading any FPGA registers on the B205? Looking at this file as an exhaustive source of what python functions are available/implemented, nothing jumped at me (unless read_register allows that.) https://github.com/EttusResearch/uhd/blob/46ab88b42a5e19bfbac45c5eff5a4ba3a0cfbd84/host/lib/usrp/multi_usrp_python.hpp The eventual goal is to be able to read-back a new/user-defined FPGA register - so I'm thinking if there is an existing implementation/support for reading any FPGA register (radio, top-level, whichever) in python, I can use that as a template. Thanks Chintan On Tue, Sep 4, 2018 at 1:15 PM Martin Braun wrote: > On 09/03/2018 08:21 PM, Chintan Patel via USRP-users wrote: > > Hello, > > > > I have defined a new readback register in the FPGA in the b205_core > > file, adjacent to the lock state register. What is the least invasive > > function call/method in the UHD driver/software to be able to read this > > newly defined register? > > This is how the lock state reg is read: > > https://github.com/EttusResearch/uhd/blob/6013a511370b9452020adfc72d7893f1c3bb2963/host/lib/usrp/b200/b200_impl.cpp#L1325 > > ...and if you want to read your own readback regs on that address space, > you'll need to add code that does something similar. The easiest way is > to then bind that register to a property and you can read it out in your > own software. > > However, we recently added an even-less invasive way of accessing user > regs. However, they would have to live in the user_regs address space. > See the manual for more info: > > http://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga > > -- M > > > > > > Thanks > > C > > > > > > ___ > > 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] B200 FPGA usage between 3.9 and 3.13
Hi Michael, > Thank you for letting us know. That is quite a jump in utilization. We will > take a look when we have some time. > > We did recently make recent bug fixes in axi_packet_gate. It looks like > that, and possibly other changes, inadvertently increased resource > utilization more than expected for B200. Our priority is always first to > make sure the FPGA images successfully build with the bug fixes so we can get > those bug fixes out to users as soon as possible. We do try to minimize > resource utilization, but that is a secondary priority. AFAICT, it's all due to the new "address FIFO". But that FIFO seems to be setup to be unreasonably large. I mean it can store as many addresses as data words ... while AFAICT it only has to store one address per packet in the buffer, so reducing it to say 32 entries should be enough. This way 6 bits can fit in 1 CLB using 32x2 distrams instead of using block rams. Cheers, Sylvain ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Best path forward on N310
If I read the block diagram correctly, the N310 also has 2G of DRAM allocated to the fabric. So with RFNoC you could write a block where you "slowly" load samples to the PL DRAM (from the embeded PS using microsd for instance), then play them in a loop from the PL DRAM. Cheers, Sylvain ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
