[USRP-users] FPGA RFNoC Radio block with only one channel
Hi everyone, I'm using an USRP E320 using the RFNoC image to implement a code that requires too much FPGA resources. I only need to use one of the channels of the USRP so I was wondering if it could be possible to eliminate the logic associated with the other channel to save resources on the FPGA and if there is a 'safe' way to do that. I mean I have seen on the verilog source code, that there is a parameter 'NUM_CHANNELS_PER_RADIO' (e320.v on fpga repository) which configures the channels of the radio, but what happens with the tx_i1, tx_q1, rx_i1 and rx_1q signals that goes to the LVDS interface with the ADC? Can they be left unconnected? Is there another parameter that I must change to use only one channel and eliminate the 'extra' logic? Kind Regards, Maria ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Fwd: FPGA RFNoC Radio block with only one channel
-- Forwarded message - De: Maria Muñoz Date: lun, 23 nov 2020 a las 10:05 Subject: Re: [USRP-users] FPGA RFNoC Radio block with only one channel To: Wade Fife Hi Wade, Thanks for your answer that helps me a lot. I have migrated to UHD 4.0 as you suggested so just a few questions to make sure I have understood how the YAML file and the tool work. I want to have a first image with radio, DUC, DDC and FIFO only using one channel of the radio. As I see on the e320_rfnoc_image_core YML file, the DDC, DUC, radio and a fifo block are instanced. And on the static connections part of the file are all the connections for each channel (I guess this is radio0(0) and radio0(1)). If I want to remove channel 1 for example, I must set num ports to 1 on the instance of the DDC/DUC and then remove the connections associated with the in/out_1. Is that correct? Should I also change num_ports on the yml radio block file? Then, to build the image I must run rfnoc_image_builder with option -y and this modified yml file, that's all? Kind regards, Maria El vie., 20 nov. 2020 16:44, Wade Fife escribió: > Hi Maria, > > I assume you're using UHD 3.15 or earlier, since you mentioned the "fpga > repository". I've never tried what you're suggesting, so I don't know what > challenges you'll run into. I think changing NUM_CHANNELS_PER_RADIO will do > what you want, but it will have some side effects, like removing the GPIO > for that channel. I think it might be safer to just change the NUM_CHANNELS > that gets passed to e320_core, since I think that will remove just the > radio and associated DDC/DUC while leaving all the other board signals > connected. Again, I haven't tried it, so I can't say for sure. > > In general, these kinds of changes need to be considered carefully, since > it leaves signals undriven, which usually means they will be driven to 0 by > default. 0 is often the right value for something that's unused, but not > always. There may also be software implications. > > By the way, these kinds of changes are easier to make in UHD 4.0 since > it's described by a YAML file. So it's easy to say you just want one radio > and to leave out the DDC/DUC, or DRAM FIFO, for example. The required > Verilog is then generated by rfnoc_image_builder. > > Thanks, > > Wade > > On Thu, Nov 19, 2020 at 8:52 AM Maria Muñoz via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi everyone, >> >> I'm using an USRP E320 using the RFNoC image to implement a code that >> requires too much FPGA resources. I only need to use one of the channels of >> the USRP so I was wondering if it could be possible to eliminate the logic >> associated with the other channel to save resources on the FPGA and if >> there is a 'safe' way to do that. >> I mean I have seen on the verilog source code, that there is a parameter >> 'NUM_CHANNELS_PER_RADIO' (e320.v on fpga repository) which configures the >> channels of the radio, but what happens with the tx_i1, tx_q1, rx_i1 and >> rx_1q signals that goes to the LVDS interface with the ADC? Can they be >> left unconnected? Is there another parameter that I must change to use >> only one channel and eliminate the 'extra' logic? >> >> Kind Regards, >> >> Maria >> ___ >> 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] Fwd: FPGA RFNoC Radio block with only one channel
Hi Wade,
Thanks for the answer.
I get an error if I run this command with the modifications made on the
.yml file:
~/rfnoc/src/uhd/host/utils$ ./rfnoc_image_builder.py -y
../../fpga/usrp3/top/e320/e320_rfnoc_image_core.yml -d e320 -t E320_1G -g
*[WAR] Module jsonschema is not installed. Configuration files will not be
validated against their schema.[WAR] Skip schema validation (missing module
jsonschema).[INF] Using FPGA directory
/home/mamuqui/rfnoc/src/uhd/fpga[INF] Selected device e320[INF] Using
io_signatures.yml from ../include/uhd/rfnoc/core.[INF] Using e320_bsp.yml
from ../include/uhd/rfnoc/core.[INF] Adding block description from
replay.yml (../include/uhd/rfnoc/blocks).[INF] Adding block description
from fft_1x64.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from duc.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from null_src_sink.yml (../include/uhd/rfnoc/blocks).[INF]
Adding block description from moving_avg.yml
(../include/uhd/rfnoc/blocks).[INF] Adding block description from
fosphor.yml (../include/uhd/rfnoc/blocks).[INF] Adding block description
from window.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from radio_2x64.yml (../include/uhd/rfnoc/blocks).[INF] Adding
block description from axi_ram_fifo.yml (../include/uhd/rfnoc/blocks).[INF]
Adding block description from ddc.yml (../include/uhd/rfnoc/blocks).[INF]
Adding block description from axi_ram_fifo_4x64.yml
(../include/uhd/rfnoc/blocks).[INF] Adding block description from
keep_one_in_n.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from fir_filter.yml (../include/uhd/rfnoc/blocks).[INF] Adding
block description from vector_iir.yml (../include/uhd/rfnoc/blocks).[INF]
Adding block description from addsub.yml
(../include/uhd/rfnoc/blocks).[INF] Adding block description from
siggen.yml (../include/uhd/rfnoc/blocks).[INF] Adding block description
from split_stream.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from axi_ram_fifo_2x64.yml (../include/uhd/rfnoc/blocks).[INF]
Adding block description from logpwr.yml
(../include/uhd/rfnoc/blocks).[INF] Adding block description from
switchboard.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from radio.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
description from radio_1x64.yml (../include/uhd/rfnoc/blocks).[ERR] 1
Unresolved connection(s)[ERR] (_device_-x300_radio ->
radio0-x300_radio)[INF] (('radio0', 'ctrl_port', 'master'),)[INF]
(('radio0', 'time_keeper', 'listener'),)[INF] (('radio0',
'radio_iface', 'slave'),)[INF] (('fifo0', 'axi_ram',
'master'),)[INF] (('_device_', 'ctrl_port', 'slave'),)[INF]
(('_device_', 'time_keeper', 'broadcaster'),)[INF] (('_device_',
'x300_radio', 'master'),)[INF] (('_device_', 'dram', 'slave'),)*
I attach the modified YAML file.
I guess this can be related to the BSP connection part of the file but I'm
not sure how to change this part to do what I want to do. Is there any
documentation about this part of the yaml file? I have read the "Getting
started with RFNoC in UHD 4.0" (
https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0) but I can't see
what makes this part of the file.
Kind Regards,
Maria
El mié, 25 nov 2020 a las 2:42, Wade Fife () escribió:
> Yes, that's correct. There's a radio_1x64.yml you can use to get a single
> channel radio. You might consider removing the FIFO if you don't need it.
>
> Wade
>
> On Tue, Nov 24, 2020 at 8:46 AM Maria Muñoz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>
>>
>> -- Forwarded message -
>> De: Maria Muñoz
>> Date: lun, 23 nov 2020 a las 10:05
>> Subject: Re: [USRP-users] FPGA RFNoC Radio block with only one channel
>> To: Wade Fife
>>
>>
>> Hi Wade,
>>
>> Thanks for your answer that helps me a lot.
>>
>> I have migrated to UHD 4.0 as you suggested so just a few questions to
>> make sure I have understood how the YAML file and the tool work.
>>
>> I want to have a first image with radio, DUC, DDC and FIFO only using one
>> channel of the radio. As I see on the e320_rfnoc_image_core YML file, the
>> DDC, DUC, radio and a fifo block are instanced. And on the static
>> connections part of the file are all the connections for each channel (I
>> guess this is radio0(0) and radio0(1)). If I want to remove channel 1 for
>> example, I must set num ports to 1 on the instance of the DDC/DUC and then
>> remove the connections associated with
Re: [USRP-users] Fwd: FPGA RFNoC Radio block with only one channel
Hi Wide,
You are right, for radio_1x64, the port is radio_iface. I have change it
and now it works.
Thanks for helping me.
Kind Regards,
Maria.
El mié., 25 nov. 2020 17:06, Wade Fife escribió:
> Hi Maria,
>
> I think you need to change the dstport on line 86 to from x300_radio to
> radio_iface. When there are unresolved connections, the tool outputs the
> list of connections available. The one you want is (('radio0',
> 'radio_iface', 'slave'),). You can also check the port name in the
> radio_1x64.yml file. It's confusing that the port name is different in this
> case. I was recently working on fixing that so that, hopefully, you won't
> have to update the port name for changes like this in the future.
>
> Thanks,
>
> Wade
>
> On Wed, Nov 25, 2020 at 2:42 AM Maria Muñoz wrote:
>
>> Hi Wade,
>>
>> Thanks for the answer.
>>
>> I get an error if I run this command with the modifications made on the
>> .yml file:
>>
>> ~/rfnoc/src/uhd/host/utils$ ./rfnoc_image_builder.py -y
>> ../../fpga/usrp3/top/e320/e320_rfnoc_image_core.yml -d e320 -t E320_1G -g
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *[WAR] Module jsonschema is not installed. Configuration files will not
>> be validated against their schema.[WAR] Skip schema validation (missing
>> module jsonschema).[INF] Using FPGA directory
>> /home/mamuqui/rfnoc/src/uhd/fpga[INF] Selected device e320[INF] Using
>> io_signatures.yml from ../include/uhd/rfnoc/core.[INF] Using e320_bsp.yml
>> from ../include/uhd/rfnoc/core.[INF] Adding block description from
>> replay.yml (../include/uhd/rfnoc/blocks).[INF] Adding block description
>> from fft_1x64.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from duc.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from null_src_sink.yml (../include/uhd/rfnoc/blocks).[INF]
>> Adding block description from moving_avg.yml
>> (../include/uhd/rfnoc/blocks).[INF] Adding block description from
>> fosphor.yml (../include/uhd/rfnoc/blocks).[INF] Adding block description
>> from window.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from radio_2x64.yml (../include/uhd/rfnoc/blocks).[INF] Adding
>> block description from axi_ram_fifo.yml (../include/uhd/rfnoc/blocks).[INF]
>> Adding block description from ddc.yml (../include/uhd/rfnoc/blocks).[INF]
>> Adding block description from axi_ram_fifo_4x64.yml
>> (../include/uhd/rfnoc/blocks).[INF] Adding block description from
>> keep_one_in_n.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from fir_filter.yml (../include/uhd/rfnoc/blocks).[INF] Adding
>> block description from vector_iir.yml (../include/uhd/rfnoc/blocks).[INF]
>> Adding block description from addsub.yml
>> (../include/uhd/rfnoc/blocks).[INF] Adding block description from
>> siggen.yml (../include/uhd/rfnoc/blocks).[INF] Adding block description
>> from split_stream.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from axi_ram_fifo_2x64.yml (../include/uhd/rfnoc/blocks).[INF]
>> Adding block description from logpwr.yml
>> (../include/uhd/rfnoc/blocks).[INF] Adding block description from
>> switchboard.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from radio.yml (../include/uhd/rfnoc/blocks).[INF] Adding block
>> description from radio_1x64.yml (../include/uhd/rfnoc/blocks).[ERR] 1
>> Unresolved connection(s)[ERR] (_device_-x300_radio ->
>> radio0-x300_radio)[INF] (('radio0', 'ctrl_port', 'master'),)[INF]
>> (('radio0', 'time_keeper', 'listener'),)[INF] (('radio0',
>> 'radio_iface', 'slave'),)[INF] (('fifo0', 'axi_ram',
>> 'master'),)[INF] (('_device_', 'ctrl_port', 'slave'),)[INF]
>> (('_device_', 'time_keeper', 'broadcaster'),)[INF] (('_device_',
>> 'x300_radio', 'master'),)[INF] (('_device_', 'dram', 'slave'),)*
>>
>> I attach the modified YAML file.
>> I guess this can be related to the BSP connection part of the file but
>> I'm not sure how to change this part to do what I want to do. Is there any
>> docume
[USRP-users] Wrong name of files found when instaling OOT RFNoC block
Hi all,
I have tried to install a custom OOT RFNoC block created using the
rfnocmodtool.
I've successfully created a module with my custom block, modifying the
verilog file created by the tool (
*rfnoc-test/rfnoc/fpga/rfnoc_block_myblock/rfnoc_block_myblock.v*) to
include the top level of my code.
My code is written in VHDL and has some other VHDL modules instanced in the
top level, so I must include these VHDL files (top level and dependencies)
in the Makefile.srcs included in
*rfnoc-test/rfnoc/fpga/rfnoc_block_myblock/*
I have included these sources files in the same folder as the noc_shell and
block verilog files, so my Makefile.srcs is like this:
*# RFNoC Block Sources# Here, list all the files that are necessary to
synthesize this block. Don't# include testbenches!# Make sure that the
source files are nicely detectable by a regex. Best to put# one on each
line.# The first argument to addprefix is the current path to this
Makefile, so the# path list is always absolute, regardless of from where
we're including or# calling this file. RFNOC_OOT_SRCS needs to be a simply
expanded variable# (not a recursively expanded variable), and we take care
of that in the build# infrastructure.RFNOC_OOT_SRCS += $(addprefix $(dir
$(abspath $(lastword $(MAKEFILE_LIST, \rfnoc_block_myblock.v
\noc_shell_myblock.v \top_level.vhd \file_1.vhd \file_2.vhd \file_3.vhd \)*
To install my block I did the following steps:
1. Create a "build" directory in the rfnoc-test folder
2. cd build
3. cmake -DUHD_FPGA_DIR=~/rfnoc/src/uhd/fpga/ ../
4. make
5. sudo make install
In this last step, make said that there were no "top_level.v" found. It
took the wrong extension of the file, so I looked at the
/rfnoc-test/build/rfnoc/fpga/rfnoc_block_myblock/cmake_install.cmake and
saw that at the end of this file the included sources were named wrong. For
example, the extensions were .v instead of .vhd and some names of files
that have numbers or uppercase letters were incomplete.
I have looked at the CMakelists.txt in the rfnoc-test folder and, in line
212 there is a regular expression to include the sources files, which I
think doesn't include ".vhd" possible extensions or names containing
numbers or uppercases:
*Helper macro to register an RFNoC block directory.# Such a directory must
always have a Makefiles.srcs containing all the# required HDL files for
synthesis, and optionally a Makefile file for running# the testbench.# The
NOTESTBENCH argument can be used to skip the testbench target
generation.macro(RFNOC_REGISTER_BLOCK_DIR)
cmake_parse_arguments(_rfnoc_block "NOTESTBENCH" "" "" ${ARGN})
get_filename_component(_blk_name "${CMAKE_CURRENT_SOURCE_DIR}" NAME)
message(STATUS "Registering RFNoC block: ${_blk_name}")file(READ
${CMAKE_CURRENT_SOURCE_DIR}/Makefile.srcs _makefile_srcs)list(APPEND
_block_src_files "Makefile.srcs")string(REGEX MATCHALL "[a-z_]+\\.v"
_src_files ${_makefile_srcs})foreach(_src_file ${_src_files})
string(STRIP "${_src_file}" _src_file})list(APPEND _block_src_files
"${_src_file}")endforeach()install(FILES ${_block_src_files}
DESTINATION ${PROJECT_DATA_DIR}/fpga/${_blk_name}COMPONENT fpga)
RFNOC_ADD_TB_DIR()endmacro()*
If I change this regex by *"**[a-z_A-Z0-9]+\\.[vhd]+" *it works, and the
module is installed.
Is this a known bug or maybe I have included my sources in a wrong location?
Kind Regards,
Maria
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Generate blocks with more than 1 input/output using rfnocmodtool
Hi all, Is it possible to automatically create an rfnoc_block schema with, for example, 2 inputs and 2 outputs payload stream packets as in the addsub blockdata using rfnocmodtool? I can generate it using rfnoc_create_verilog.py through a block.yml file following the steps in : https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Generating_Your_Block_Using_the_ModTool But I don't know the steps to do that using rfnocmodtool, it always generates a 1 input, 1 output block with axis_pyload_ctxt interface even though the block.yml generated in block folder has axis_data interface: *schema: rfnoc_modtool_argsmodule_name: multinoutversion: 1.0rfnoc_version: 1.0chdr_width: 64noc_id: 0x4321makefile_srcs: "/home/usr/rfnoc/src/gr-ettus/rfnoc-prueba/rfnoc/fpga/rfnoc_block_multinout/Makefile.srcs"* *clocks: - name: rfnoc_chdrfreq: "[]" - name: rfnoc_ctrlfreq: "[]" - name: cefreq: "[]"control: sw_iface: nocscript fpga_iface: ctrlport interface_direction: slave fifo_depth: 32 clk_domain: ce ctrlport:byte_mode: Falsetimed: Falsehas_status: Falsedata: fpga_iface: axis_data clk_domain: ce inputs:in: item_width: 32 nipc: 1 info_fifo_depth: 32 payload_fifo_depth: 32 format: int32 mdata_sig: ~ outputs:out: item_width: 32 nipc: 1 info_fifo_depth: 32 payload_fifo_depth: 32 format: int32* * mdata_sig: ~* Can I modify this file and somehow reload the files generated in the first attempt or is there other way to do what I want? Kind Regards, Maria ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Generate blocks with more than 1 input/output using rfnocmodtool
Hi Jonathon, Thanks for your reply. Ok, I make "rfnocmodtool newmod test" and "rfnocmodtool add multinout" to create module and block folders and then modify the block.yml file and make "python3 ~/rfnoc/src/uhd/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py -c ~/rfnoc/src/gr-ettus/rfnoc-test/rfnoc/blocks/multinout.yml -d ~/rfnoc/src/gr-ettus/rfnoc-test/rfnoc/fpga/rfnoc_block_multinout" and that seems to work. Kind Regards, Maria. El jue, 21 ene 2021 a las 6:36, Jonathon Pendlum (< jonathon.pend...@ettus.com>) escribió: > HI Maria, > > Rfnocmodtool does not support multiple inputs / outputs. You'll need to > edit the generated yaml file and use it with the utility > rfnoc_create_verilog to generate the block and noc shell. See > https://kb.ettus.com/RFNoC_4_Migration_Guide#Generating_a_Custom_Noc_Shell. > To edit the yaml file, you can refer to the RFNoC specification ( > https://files.ettus.com/app_notes/RFNoC_Specification.pdf) or look at an > existing RFNoC block's yaml file that supports multiple ports such as the > FIR filter block (uhd/host/include/uhd/rfnoc/blocks/fir_filter.yml). > > Also, as you've noticed, the generated yaml file has the wrong interface, > "fpga_iface: axis_data" should be "fpga_iface: axis_pyld_ctxt". That is a > known issue that is in the pipeline to be fixed. > > Jonathon > > On Wed, Jan 20, 2021 at 8:18 AM Maria Muñoz via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi all, >> >> Is it possible to automatically create an rfnoc_block schema with, for >> example, 2 inputs and 2 outputs payload stream packets as in the addsub >> blockdata using rfnocmodtool? >> I can generate it using rfnoc_create_verilog.py through a block.yml file >> following the steps in : >> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Generating_Your_Block_Using_the_ModTool >> But I don't know the steps to do that using rfnocmodtool, it always >> generates a 1 input, 1 output block with axis_pyload_ctxt interface even >> though the block.yml generated in block folder has axis_data interface: >> >> >> >> >> >> >> >> >> *schema: rfnoc_modtool_argsmodule_name: multinoutversion: >> 1.0rfnoc_version: 1.0chdr_width: 64noc_id: 0x4321makefile_srcs: >> "/home/usr/rfnoc/src/gr-ettus/rfnoc-prueba/rfnoc/fpga/rfnoc_block_multinout/Makefile.srcs"* >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *clocks: - name: rfnoc_chdrfreq: "[]" - name: rfnoc_ctrlfreq: >> "[]" - name: cefreq: "[]"control: sw_iface: nocscript fpga_iface: >> ctrlport interface_direction: slave fifo_depth: 32 clk_domain: ce >> ctrlport:byte_mode: Falsetimed: Falsehas_status: Falsedata: >> fpga_iface: axis_data clk_domain: ce inputs:in: item_width: 32 >> nipc: 1 info_fifo_depth: 32 payload_fifo_depth: 32 >> format: int32 mdata_sig: ~ outputs:out: item_width: 32 >> nipc: 1 info_fifo_depth: 32 payload_fifo_depth: 32 format: >> int32* >> * mdata_sig: ~* >> >> Can I modify this file and somehow reload the files generated in the >> first attempt or is there other way to do what I want? >> >> Kind Regards, >> >> Maria >> ___ >> 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] Enable AGC in USRP E320 with RFNoC using GNURadio
Hi all, I was wondering if it is possible to enable AGC from the RFNoC radio block in GNURadio. I use UHD 4.0 version and GNURadio 3.8 with gr-ettus. I see that the RFNoC Rx radio block has an enable/disable/default AGC option in the GNURadio block which I assume calls the UHD function "set_rx_agc" ( https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486 ) I have also checked on the FPGA side that there is a pin from FPGA to AD9361 called XCVR_ENA_AGC which is set always to 1 on the top level of the FPGA image (see attached file "e320.v", line 872). This pin, according to https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf is the "Manual Control Input for Automatic Gain Control (AGC)". Must be this pin set to 0 to have AGC working? If not, how can I get AGC working? I've made some tests enabling/disabling this option but I do not see any changes between the waveforms received. Any help would be appreciated. Kind Regards, Maria / // // Copyright 2018 Ettus Research, A National Instruments Company // // SPDX-License-Identifier: LGPL-3.0-or-later // // Module: e320 // Description: // E320 Top Level // / `default_nettype none module e320 ( // 5V Power Enable output wire ENA_PAPWR, // GPIO output wire EN_GPIO_2V5, output wire EN_GPIO_3V3, output wire EN_GPIO_VAR_SUPPLY, inout wire [7:0] GPIO_PREBUFF, inout wire [7:0] GPIO_DIR, output wire GPIO_OE_N, // GPS output wire CLK_GPS_PWR_EN, output wire GPS_INITSURV_N, output wire GPS_RST_N, input wire GPS_ALARM, input wire GPS_LOCK, input wire GPS_PHASELOCK, input wire GPS_SURVEY, input wire GPS_WARMUP, // SFP input wire SFP1_RX_P, input wire SFP1_RX_N, output wire SFP1_TX_P, output wire SFP1_TX_N, input wire SFP1_RXLOS, input wire SFP1_TXFAULT, input wire SFP1_MOD_ABS, // Unused output wire SFP1_RS0, output wire SFP1_RS1, output wire SFP1_TXDISABLE, // MGT Clocks output wire CLK_PLL_SCLK, output wire CLK_PLL_SDATA, output wire CLK_PLL_SLE, input wire CLK_MGT_125M_P, input wire CLK_MGT_125M_N, input wire CLK_MGT_156_25M_P, input wire CLK_MGT_156_25M_N, // PS Connections inout wire [53:0] PS_MIO, inout wirePS_CLK, inout wirePS_SRST_B, inout wirePS_POR_B, inout wireDDR_MODCLK_P, inout wireDDR_MODCLK_N, inout wirePS_DDR3_CKE, inout wirePS_DDR3_RESET_N, inout wire [31:0] PS_DDR3_DQ, inout wire [14:0] PS_DDR3_ADDR, inout wire [3:0] PS_DDR3_DM, inout wire [2:0] PS_DDR3_BA, inout wire [3:0] PS_DDR3_DQS_P, inout wire [3:0] PS_DDR3_DQS_N, inout wirePS_DDR3_ODT, inout wirePS_DDR3_VRN, inout wirePS_DDR3_VRP, inout wirePS_DDR3_WE_N, inout wirePS_DDR3_CS_N, inout wirePS_DDR3_CAS_N, inout wirePS_DDR3_RAS_N, // PL DRAM Interface input wire sys_clk_p, input wire sys_clk_n, // inout wire [31:0] ddr3_dq, inout wire [3:0] ddr3_dqs_n, inout wire [3:0] ddr3_dqs_p, output wire [3:0] ddr3_dm, // output wire [2:0] ddr3_ba, output wire [15:0] ddr3_addr, output wireddr3_ras_n, output wireddr3_cas_n, output wireddr3_we_n, // output wire [0:0] ddr3_cs_n, output wire [0:0] ddr3_cke, output wire [0:0] ddr3_odt, // output wire [0:0] ddr3_ck_p, output wire [0:0] ddr3_ck_n, // output wireddr3_reset_n, // LEDs output wire LED_LINK1, output wire LED_ACT1, // PPS, REFCLK input wire CLK_SYNC_INT, // PPS from GPS input wire CLK_SYNC_INT_RAW, // PPS_RAW from GPS (Unused) input wire CLK_SYNC_EXT, // PPS from external connector input wire CLK_REF_RAW, // FPGA reference clock (GPS or external) output wire CLK_REF_SEL, // Select for GPS or external reference clock input wire CLK_MUX_OUT, // RF clock locked status // RF LVDS Data Interface // // Receive input wire RX_CLK_P, input wire RX_CLK_N, input wire RX_FRAME_P, input wire RX_FRAME_N, input wire [5:0] RX_DATA_P, input wire [5:0] RX_DATA_N, // // TraNSMIT output wire TX_CLK_P, output wire TX_CLK_N, output wire TX_FRAME_P, output wire TX_FRAME_N, output wire [5:0] TX_DATA_P, output wire [5:0] TX_DATA_N, // Switches output wire [2:0] FE1_SEL, output wire [2:0] FE2_SEL, output wire [1:0] RX1_SEL, output wire [1:0] RX2_SEL, output wire [5:0] RX1_BSEL, output wire [5:0] RX2_BSEL, output wire [5:0] TX1_BSEL, output wire [5:0] TX2_BSEL, // SPI input wire XCVR_SPI_MISO, output wire XCVR_SPI_MOSI, output wire XCVR_SPI_CLK, output wire XCVR_SPI_CS_N, // AD9361 output wire XCVR_ENABLE, output wire XCVR_SYNC, output wire XCVR_TXNRX, output wire XCV
Re: [USRP-users] Enable AGC in USRP E320 with RFNoC using GNURadio
Hi Julian,
Thanks for the quick answer.
I think you might be right about the possible bug turning on the AGC from
GRC. I have checked the flow graph generated and there's no set_rx_agc
enable option (I checked the c++ definition block where this option did
appear but I hadn't look at the python generated).
The lines related to the radio in my flowgraph are these:
*self.ettus_rfnoc_rx_radio_0 = ettus.rfnoc_rx_radio(
self.rfnoc_graph,uhd.device_addr(''),-1,
-1)self.ettus_rfnoc_rx_radio_0.set_rate(samp_rate)
self.ettus_rfnoc_rx_radio_0.set_antenna('RX2', 0)
self.ettus_rfnoc_rx_radio_0.set_frequency(cf, 0)
self.ettus_rfnoc_rx_radio_0.set_gain(gain, 0)
self.ettus_rfnoc_rx_radio_0.set_bandwidth(samp_rate, 0)
self.ettus_rfnoc_rx_radio_0.set_dc_offset(True, 0)
self.ettus_rfnoc_rx_radio_0.set_iq_balance(True, 0)*
So, if I understand correctly, I have to put there also something like
"self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)" isn't it?
Kind Regards,
Maria
El mié, 10 mar 2021 a las 9:16, Julian Arnold ()
escribió:
> Maria,
>
> I might not be the right person to answer this, as my experience with
> UHD 4.0 is relatively limited at the moment.
>
> However, I cant tell you that the AGC on B2x0 devices is controlled via
> software (using set_rx_agc()). There is no need to directly modify the
> state of any pins of the FPGA.
>
> I vaguely remember that there was a bug in an earlier version of gr-uhd
> (somewhere in 3.7) that made it difficult to turn on the AGC using GRC.
> That particular one is fixed in gr-uhd. Not sure about gr-ettus, though.
>
> Maybe try using set_rx_agc() manually in you flow-graph (*.py) and see
> if that helps.
>
> Cheers,
> Julian
>
> On 3/9/21 5:11 PM, Maria Muñoz via USRP-users wrote:
> > Hi all,
> >
> > I was wondering if it is possible to enable AGC from the RFNoC radio
> > block in GNURadio. I use UHD 4.0 version and GNURadio 3.8 with gr-ettus.
> >
> > I see that the RFNoC Rx radio block has an enable/disable/default AGC
> > option in the GNURadio block which I assume calls the UHD function
> > "set_rx_agc"
> > (
> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486
> )
> >
> > I have also checked on the FPGA side that there is a pin from FPGA to
> > AD9361 called XCVR_ENA_AGC which is set always to 1 on the top level of
> > the FPGA image (see attached file "e320.v", line 872). This pin,
> > according to
> >
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf
> > is the "Manual Control Input for Automatic Gain Control (AGC)".
> > Must be this pin set to 0 to have AGC working?
> > If not, how can I get AGC working? I've made some tests
> > enabling/disabling this option but I do not see any changes between the
> > waveforms received.
> >
> > Any help would be appreciated.
> >
> > Kind Regards,
> >
> > Maria
> >
> > ___
> > 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] Enable AGC in USRP E320 with RFNoC using GNURadio
Hi Jules,
Thank you, I will try it and let you know as soon as possible.
By the way, I have checked the python generated using the UHD USRP SOURCE
block (instead of the RFNoC radio block) with AGC active and it generates
the set of AGC fine. So, as you said, it is fixed in gr-uhd but it might
still be a bug in gr-ettus.
Thanks again for the help!
Kind Regards,
Maria
El mié, 10 mar 2021 a las 11:25, Julian Arnold ()
escribió:
> Maria,
>
> >> So, if I understand correctly, I have to put there also something like
> >> "self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)" isn't it?
>
> Exactly! Take a look at [1] for the correct syntax.
>
> [1]
>
> https://github.com/EttusResearch/gr-ettus/blob/1038c4ce5135a2803b53554fc4971fe3de747d9a/include/ettus/rfnoc_rx_radio.h#L97
>
> Let me know if that worked out for you.
>
> Cheers,
> Julian
>
>
> On 3/10/21 9:59 AM, Maria Muñoz wrote:
> > Hi Julian,
> >
> > Thanks for the quick answer.
> >
> > I think you might be right about the possible bug turning on the AGC
> > from GRC. I have checked the flow graph generated and there's no
> > set_rx_agc enable option (I checked the c++ definition block where this
> > option did appear but I hadn't look at the python generated).
> >
> > The lines related to the radio in my flowgraph are these:
> >
> > /self.ettus_rfnoc_rx_radio_0 = ettus.rfnoc_rx_radio(
> > self.rfnoc_graph,
> > uhd.device_addr(''),
> > -1,
> > -1)
> > self.ettus_rfnoc_rx_radio_0.set_rate(samp_rate)
> > self.ettus_rfnoc_rx_radio_0.set_antenna('RX2', 0)
> > self.ettus_rfnoc_rx_radio_0.set_frequency(cf, 0)
> > self.ettus_rfnoc_rx_radio_0.set_gain(gain, 0)
> > self.ettus_rfnoc_rx_radio_0.set_bandwidth(samp_rate, 0)
> > self.ettus_rfnoc_rx_radio_0.set_dc_offset(True, 0)
> > self.ettus_rfnoc_rx_radio_0.set_iq_balance(True, 0)/
> >
> > So, if I understand correctly, I have to put there also something like
> > "self.ettus_rfnoc_rx_radio_0.set_rx_agc(enable,0)" isn't it?
> >
> > Kind Regards,
> >
> > Maria
> >
> > El mié, 10 mar 2021 a las 9:16, Julian Arnold ( > <mailto:jul...@elitecoding.org>>) escribió:
> >
> > Maria,
> >
> > I might not be the right person to answer this, as my experience with
> > UHD 4.0 is relatively limited at the moment.
> >
> > However, I cant tell you that the AGC on B2x0 devices is controlled
> via
> > software (using set_rx_agc()). There is no need to directly modify
> the
> > state of any pins of the FPGA.
> >
> > I vaguely remember that there was a bug in an earlier version of
> gr-uhd
> > (somewhere in 3.7) that made it difficult to turn on the AGC using
> GRC.
> > That particular one is fixed in gr-uhd. Not sure about gr-ettus,
> though.
> >
> > Maybe try using set_rx_agc() manually in you flow-graph (*.py) and
> see
> > if that helps.
> >
> > Cheers,
> > Julian
> >
> > On 3/9/21 5:11 PM, Maria Muñoz via USRP-users wrote:
> > > Hi all,
> > >
> > > I was wondering if it is possible to enable AGC from the RFNoC
> radio
> > > block in GNURadio. I use UHD 4.0 version and GNURadio 3.8 with
> > gr-ettus.
> > >
> > > I see that the RFNoC Rx radio block has an enable/disable/default
> > AGC
> > > option in the GNURadio block which I assume calls the UHD function
> > > "set_rx_agc"
> > >
> > (
> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486
> )
> > >
> > > I have also checked on the FPGA side that there is a pin from
> > FPGA to
> > > AD9361 called XCVR_ENA_AGC which is set always to 1 on the top
> > level of
> > > the FPGA image (see attached file "e320.v", line 872). This pin,
> > > according to
> > >
> >
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD9361.pdf
> >
> > > is the "Manual Control Input for Automatic Gain Control (AGC)".
> > > Must be this pin set to 0 to have AGC working?
> > > If not, how can I get AGC working? I've made some tests
> > > enabling/disabling this option but I do not see any changes
> > between the
> > > waveforms received.
> > >
> > > Any help would be appreciated.
> > >
> > > Kind Regards,
> > >
> > > Maria
> > >
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com <mailto: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
