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 <wade.f...@ettus.com> 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 <mamuk...@gmail.com> 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
>> 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 (<wade.f...@ettus.com>)
>> 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 <mamuk...@gmail.com>
>>>> Date: lun, 23 nov 2020 a las 10:05
>>>> Subject: Re: [USRP-users] FPGA RFNoC Radio block with only one channel
>>>> To: Wade Fife <wade.f...@ettus.com>
>>>>
>>>>
>>>> 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 <wade.f...@ettus.com> 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
>>>>
>>>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
