[USRP-users] How to insert VHDL processing module to RFNoC block?
Hi community, I have some problems when trying to add VHDL processing module to RFNoC block. After inserted my VHDL module by the way described in addsub library module, I tried to run "*make rfnoc_block_Demodulation1_tb*" command and the output looks like the image below. [image: image.png] Do I need to change the makefile and makefile.srcs to make it works? I have built my processing module on Vivado with VHDL language, testbench passed in Vivado. All VHDL modules and sub-modules have been copied to rfnoc_block_* directory. Besides that, I'm not clear on the testbench of RFNoC, does the code generated by RFNoC Mod Tool have everything for testbench? Because I'm just familiar with VHDL so it is quite hard for me to write testbench in Verilog. The attached file is my RFNoC block after added VHDL module, please take a look. Thank you so much! Best regards, Tuan // // Copyright 2021 <+YOU OR YOUR COMPANY+>. // // This is free software; you can redistribute it and/or modify // it under the terms of the GNU General Public License as published by // the Free Software Foundation; either version 3, or (at your option) // any later version. // // This software is distributed in the hope that it will be useful, // but WITHOUT ANY WARRANTY; without even the implied warranty of // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the // GNU General Public License for more details. // // You should have received a copy of the GNU General Public License // along with this software; see the file COPYING. If not, write to // the Free Software Foundation, Inc., 51 Franklin Street, // Boston, MA 02110-1301, USA. // // // Module: rfnoc_block_Demodulation1 // // Description: // // This is a skeleton file for a RFNoC block. It passes incoming samples // to the output without any modification. A read/write user register is // instantiated, but left unused. // // Parameters: // // THIS_PORTID : Control crossbar port to which this block is connected // CHDR_W : AXIS-CHDR data bus width // MTU : Maximum transmission unit (i.e., maximum packet size in // CHDR words is 2**MTU). // `default_nettype none module rfnoc_block_Demodulation1 #( parameter [9:0] THIS_PORTID = 10'd0, parameter CHDR_W = 64, parameter [5:0] MTU = 10 )( // RFNoC Framework Clocks and Resets input wire rfnoc_chdr_clk, input wire rfnoc_ctrl_clk, input wire ce_clk, // RFNoC Backend Interface input wire [511:0] rfnoc_core_config, output wire [511:0] rfnoc_core_status, // AXIS-CHDR Input Ports (from framework) input wire [(1)*CHDR_W-1:0] s_rfnoc_chdr_tdata, input wire [(1)-1:0] s_rfnoc_chdr_tlast, input wire [(1)-1:0] s_rfnoc_chdr_tvalid, output wire [(1)-1:0] s_rfnoc_chdr_tready, // AXIS-CHDR Output Ports (to framework) output wire [(1)*CHDR_W-1:0] m_rfnoc_chdr_tdata, output wire [(1)-1:0] m_rfnoc_chdr_tlast, output wire [(1)-1:0] m_rfnoc_chdr_tvalid, input wire [(1)-1:0] m_rfnoc_chdr_tready, // AXIS-Ctrl Input Port (from framework) input wire [31:0]s_rfnoc_ctrl_tdata, input wire s_rfnoc_ctrl_tlast, input wire s_rfnoc_ctrl_tvalid, output wire s_rfnoc_ctrl_tready, // AXIS-Ctrl Output Port (to framework) output wire [31:0]m_rfnoc_ctrl_tdata, output wire m_rfnoc_ctrl_tlast, output wire m_rfnoc_ctrl_tvalid, input wire m_rfnoc_ctrl_tready ); //--- // Signal Declarations //--- // Clocks and Resets wire ctrlport_clk; wire ctrlport_rst; wire axis_data_clk; wire axis_data_rst; // CtrlPort Master wire m_ctrlport_req_wr; wire m_ctrlport_req_rd; wire [19:0]m_ctrlport_req_addr; wire [31:0]m_ctrlport_req_data; regm_ctrlport_resp_ack; reg [31:0]m_ctrlport_resp_data; // Payload Stream to User Logic: in wire [32*1-1:0]m_in_payload_tdata; wire [1-1:0] m_in_payload_tkeep; wire m_in_payload_tlast; wire m_in_payload_tvalid; wire m_in_payload_tready; // Context Stream to User Logic: in wire [CHDR_W-1:0] m_in_context_tdata; wire [3:0] m_in_context_tuser; wire m_in_context_tlast; wire m_in_context_tvalid; wire m_in_context_tready; // Payload Stream from User Logic: out wire [32*1-1:0]s_out_payload_tdata; wire [0:0] s_out_payload_tkeep; wire s_out_payload_tlast; wire s_out_payload_tvalid; wire
[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
[USRP-users] Building FPGA for E320.
Hi, I'm trying to build an FPGA for the E320. I'm new to Ettus products and RFNoC so this is my attempt. I'm working with UHD 4.0.0.0 and have been following the tutorial from the 2020 GNU radio conference, RFNoC 4 Workshop. I've used rfmodtool to create a new OOT folder structure. I've then used "rfmodtool add" to add my own IP block. This creates a default .yml file for the for the X210 in the icores folder. Next I've copied the file e320_rfnoc_image_core.yml from the uhd source directory into the icores of folder of my OOT structure, and renamed "demod_e320_rfnoc_image_core.yml" to match the name of new block. I just wanted at this stage to see if I could build the default image, so I haven't changed anything in this .yml file. It seems that I needed to add the IP core to the OTT to get cmake to pick up any build targets. At this stage I just wanted to check that I'd got everything correctly installed and setup on my machine to build the E320 FPGA. I've then created a build folder and ran cmake, sudo make install and then make demod_e320_rfnoc_image_core to build the bitstream. This ran for some time and looked promising. However it eventually failed with the fatal error: "Fatal Python Error : could not acquire lock for <_io.BufferedWriter name =''> at interpreter shutdown, possibly due to daemon threads Python runtime state: finalizing (tstate=0x270bed0)" I did notice scrolling back through the terminal log a number of critical warnings connected with the SPI. "SPI frequency 166.72 (MHz) should be greater than CPU_1x frequency 166.72 (MHz)". I don't expect that this is connected with the issue I've seen, and may well be normal. Any help on getting an E320 build going would be greatly appreciated, Mark This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] RFNoC/GNURadio with USRP-2974
Hi, We just received a USRP-2974 and would like to start working with RFNoC/GNURadio (rather than LabView). I was hoping that somebody could direct me to a reference for configuring this SDR for RFNoC/GNURadio. There's a lot of material that covers non-embedded USRPs, but my understanding is that there are some additional configuration steps required for this model. Any help would be greatly appreciated. Dominic ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
Hi Cédric,
I don't see anything wrong. Given that you said the FFT block works but
your block doesn't, could it be something related to a c++ block
controller?
Attached is a program I use to test an individual block with the graph
"host => block => host". It might help to see if this works. This
application does not require forwarding of the issue_stream_cmd as is
necessary when your block is used as part of the Rx chain to the radio.
Attached you will find the CPP source and below you will find a command
line that works for me with the Ettus Switchboard block which is just a
"thru" connection.
Rob
rfnoc_block_test --args=addr=192.168.61.2 --block-id Switchboard#0
--nsamps=2048 --tx-stream-args "spp=256" --rx-stream-args "spp=256"
On Tue, Jan 19, 2021 at 12:43 PM Cédric Hannotier via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear all,
>
> I am trying to implement simple RFNoC block in my FPGA image (X310),
> and test it using UHD C++ API.
>
> However, none of my blocks worked when inserted between the DDC and
> rx_stream.
> Both rfnoc-example/gain block (from upstream host/example)
> and bare bones block from rfnocmodtool (passthrough) failed.
>
> The procedure is as follow:
> 1. cd path/of/OOT_Block (gain or passthrough)
> 2. cmake -S . -B build -DUHD_FPGA_DIR=/path/to/uhd/fpga (upstream UHD4)
> 3. cd build; make; make x310_rfnoc_image_core
> 4. viv_jtag_program
> /path/to/uhd/fpga/usrp3/top/x300/build/usrp_x310_fpga_HG.bit (or
> uhd_image_loader + restart USRP).
> 5. cd /path/to/uhd/example/code
> 6. g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd
> 7. ./test --block-id "0/Block#0" --rate 20e6
>
> But it exits with timeout:
>
> """
> Creating the RFNoC graph with args: ...
> [INFO] [UHD] linux; GNU C++ version 10.2.1 20201224; Boost_107400;
> UHD_4.0.0.0-4
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0x4577,
> 0x
> Using radio 0, channel 0
> Looking for source block 0/Radio#0, port 0
> Setting RX Rate: 20.00 Msps...
> DDC block found
> Setting decimation value to 10
> Actual decimation value is 10
> Actual RX Rate: 20.00 Msps...
>
> Setting RX Freq: 0.00 MHz...
> Actual RX Freq: 10.00 MHz...
>
> Setting samples per packet to: 64
> Actual samples per packet = 64
> Using streamer args:
> Press Ctrl + C to stop streaming...
> Issuing stream cmd
> Timeout while streaming
> Issuing stop stream cmd
>
> Done!
> """
>
> It runs OK using "./test --rate 20e6" (without inserting
> any OOT block between DDC and rx_stream).
> It also works using an upstream provided block (eg FFT).
>
> The rfnoc_rx_to_file.cpp is slightly modified from upstream
> (since upstream does not handle argument "block-id").
> The patch is at the end of this mail.
> It should apply nicely by piping this mail to patch or git am/apply.
>
> Does anyone know how to solve this?
>
> diff --git a/host/examples/rfnoc_rx_to_file.cpp
> b/host/examples/rfnoc_rx_to_file.cpp
> index 2d648c10d..64d177d79 100644
> --- a/host/examples/rfnoc_rx_to_file.cpp
> +++ b/host/examples/rfnoc_rx_to_file.cpp
> @@ -479,13 +479,22 @@ int UHD_SAFE_MAIN(int argc, char* argv[])
> //}
>
> // Connect blocks and commit the graph
> -for (auto& edge : chain) {
> -if
> (uhd::rfnoc::block_id_t(edge.dst_blockid).match(uhd::rfnoc::NODE_ID_SEP)) {
> -graph->connect(edge.src_blockid, edge.src_port, rx_stream, 0);
> -} else {
> -graph->connect(
> -edge.src_blockid, edge.src_port, edge.dst_blockid,
> edge.dst_port);
> -}
> +//for (auto& edge : chain) {
> +//if
> (uhd::rfnoc::block_id_t(edge.dst_blockid).match(uhd::rfnoc::NODE_ID_SEP)) {
> +//graph->connect(edge.src_blockid, edge.src_port, rx_stream,
> 0);
> +//} else {
> +//graph->connect(
> +//edge.src_blockid, edge.src_port, edge.dst_blockid,
> edge.dst_port);
> +//}
> +//}
> +auto ddc_ctrl_id = ddc_ctrl->get_block_id();
> +graph->connect(radio_ctrl_id, 0, ddc_ctrl_id, 0);
> +if (!block_id.empty()) {
> + graph->connect(ddc_ctrl_id, 0, block_id, 0);
> + graph->connect(block_id, 0, rx_stream, 0);
> +}
> +else {
> + graph->connect(ddc_ctrl_id, 0, rx_stream, 0);
> }
> graph->commit();
>
>
> --
>
> Cédric Hannotier
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
#include
#include
#include
#include
#include
#include
#include
//#include
#include
#include
#include
#include
namespace po = boost::program_options;
int UHD_SAFE_MAIN(int argc, char *argv[]){
//variables to be set by po
std::string args, block_id, block_args, rx_args, tx_args;
size_t nsamps, block_port;
//set
Re: [USRP-users] No streaming using OOT RFNoC Block in UHD4
By the way, I have created a block controller for every UHD4 RFNOC block
that I have created and I simply compile them in-tree since I don't know
how to make this work OOT. This has the nice advantage that uhd_usrp_probe
can then know about my blocks.
Rob
On Wed, Jan 20, 2021 at 4:46 PM Rob Kossler wrote:
> Hi Cédric,
> I don't see anything wrong. Given that you said the FFT block works but
> your block doesn't, could it be something related to a c++ block
> controller?
>
> Attached is a program I use to test an individual block with the graph
> "host => block => host". It might help to see if this works. This
> application does not require forwarding of the issue_stream_cmd as is
> necessary when your block is used as part of the Rx chain to the radio.
> Attached you will find the CPP source and below you will find a command
> line that works for me with the Ettus Switchboard block which is just a
> "thru" connection.
> Rob
>
> rfnoc_block_test --args=addr=192.168.61.2 --block-id Switchboard#0
> --nsamps=2048 --tx-stream-args "spp=256" --rx-stream-args "spp=256"
>
> On Tue, Jan 19, 2021 at 12:43 PM Cédric Hannotier via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear all,
>>
>> I am trying to implement simple RFNoC block in my FPGA image (X310),
>> and test it using UHD C++ API.
>>
>> However, none of my blocks worked when inserted between the DDC and
>> rx_stream.
>> Both rfnoc-example/gain block (from upstream host/example)
>> and bare bones block from rfnocmodtool (passthrough) failed.
>>
>> The procedure is as follow:
>> 1. cd path/of/OOT_Block (gain or passthrough)
>> 2. cmake -S . -B build -DUHD_FPGA_DIR=/path/to/uhd/fpga (upstream UHD4)
>> 3. cd build; make; make x310_rfnoc_image_core
>> 4. viv_jtag_program
>> /path/to/uhd/fpga/usrp3/top/x300/build/usrp_x310_fpga_HG.bit (or
>> uhd_image_loader + restart USRP).
>> 5. cd /path/to/uhd/example/code
>> 6. g++ -g -o test rfnoc_rx_to_file.cpp -lboost_program_options -luhd
>> 7. ./test --block-id "0/Block#0" --rate 20e6
>>
>> But it exits with timeout:
>>
>> """
>> Creating the RFNoC graph with args: ...
>> [INFO] [UHD] linux; GNU C++ version 10.2.1 20201224; Boost_107400;
>> UHD_4.0.0.0-4
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Maximum frame size: 1472 bytes.
>> [INFO] [X300] Radio 1x clock: 200 MHz
>> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID 0x4577,
>> 0x
>> Using radio 0, channel 0
>> Looking for source block 0/Radio#0, port 0
>> Setting RX Rate: 20.00 Msps...
>> DDC block found
>> Setting decimation value to 10
>> Actual decimation value is 10
>> Actual RX Rate: 20.00 Msps...
>>
>> Setting RX Freq: 0.00 MHz...
>> Actual RX Freq: 10.00 MHz...
>>
>> Setting samples per packet to: 64
>> Actual samples per packet = 64
>> Using streamer args:
>> Press Ctrl + C to stop streaming...
>> Issuing stream cmd
>> Timeout while streaming
>> Issuing stop stream cmd
>>
>> Done!
>> """
>>
>> It runs OK using "./test --rate 20e6" (without inserting
>> any OOT block between DDC and rx_stream).
>> It also works using an upstream provided block (eg FFT).
>>
>> The rfnoc_rx_to_file.cpp is slightly modified from upstream
>> (since upstream does not handle argument "block-id").
>> The patch is at the end of this mail.
>> It should apply nicely by piping this mail to patch or git am/apply.
>>
>> Does anyone know how to solve this?
>>
>> diff --git a/host/examples/rfnoc_rx_to_file.cpp
>> b/host/examples/rfnoc_rx_to_file.cpp
>> index 2d648c10d..64d177d79 100644
>> --- a/host/examples/rfnoc_rx_to_file.cpp
>> +++ b/host/examples/rfnoc_rx_to_file.cpp
>> @@ -479,13 +479,22 @@ int UHD_SAFE_MAIN(int argc, char* argv[])
>> //}
>>
>> // Connect blocks and commit the graph
>> -for (auto& edge : chain) {
>> -if
>> (uhd::rfnoc::block_id_t(edge.dst_blockid).match(uhd::rfnoc::NODE_ID_SEP)) {
>> -graph->connect(edge.src_blockid, edge.src_port, rx_stream,
>> 0);
>> -} else {
>> -graph->connect(
>> -edge.src_blockid, edge.src_port, edge.dst_blockid,
>> edge.dst_port);
>> -}
>> +//for (auto& edge : chain) {
>> +//if
>> (uhd::rfnoc::block_id_t(edge.dst_blockid).match(uhd::rfnoc::NODE_ID_SEP)) {
>> +//graph->connect(edge.src_blockid, edge.src_port, rx_stream,
>> 0);
>> +//} else {
>> +//graph->connect(
>> +//edge.src_blockid, edge.src_port, edge.dst_blockid,
>> edge.dst_port);
>> +//}
>> +//}
>> +auto ddc_ctrl_id = ddc_ctrl->get_block_id();
>> +graph->connect(radio_ctrl_id, 0, ddc_ctrl_id, 0);
>> +if (!block_id.empty()) {
>> + graph->connect(ddc_ctrl_id, 0, block_id, 0);
>> + graph->connect(block_id, 0, rx_stream, 0);
>> +}
>> +else {
>> + graph->connect(ddc_ctrl_id, 0, rx_stream, 0);
>> }
>> graph->commit();
>>
>>
>> --
>>
>> Cédric Hannotier
>>
>> ___
[USRP-users] Overflow / Underflow Questions
We have an application that requires about 640Mbps of transmit and 640Mbps of receive samples bandwidth. We have a high performance Dell laptop hooked to a B205. Questions: 1. Do the different versions of UHD support different throughput rates? 2. Are there maximum sample rates for the B205 that would restrict the throughput reaching the numbers we need. 3. Is there a receive and transmit throughput test that I can use to see what the maximum is for our platform? Thanks K- ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Overflow / Underflow Questions
On 01/20/2021 05:34 PM, Spam Blocker via USRP-users wrote: We have an application that requires about 640Mbps of transmit and 640Mbps of receive samples bandwidth. We have a high performance Dell laptop hooked to a B205. Questions: 1. Do the different versions of UHD support different throughput rates? For the B2xx series, the different UHD versions will show only very minor difference in maximum achievable sample rates. 2. Are there maximum sample rates for the B205 that would restrict the throughput reaching the numbers we need. The maximum sample rate of the B2xx is 56Msps in each direction, which means roughly 56MHz of bandwidth into and out of your application. How that translates into *mbits* of data depends very very very much on your particular application, coding efficiency, modulation efficiency, channel characteristics, Eb/No, etc. That's up to you and your particular application, and whatever your compute platform can deliver. The USRP SDRs don't inherently *know* anything about what you're doing *within* the bandwidth they dutifully transport back and forth. Higher order modulations and coding schemes take more compute power, so that's almost always your limiting factor. 3. Is there a receive and transmit throughput test that I can use to see what the maximum is for our platform? Thanks K- There is the "benchmark_rate" test application that is usually located in: /uhd/examples This will give you an idea of what your computer can move back-and-forth between itself and the USRP, absent any additional load from doing anything "real" with those samples. I would spend some time here: https://kb.ettus.com/Knowledge_Base ___ 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 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
