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
