Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream
Cool! I'll point out that your new build actually got past the old failure point you noted before, which was immediately after attempting to interact with the SplitStream RFNOC block! ``` [INFO] [0/SplitStream_0] Initializing block control (NOC ID: 0x5757) [ERROR] [UHD] Exception caught in safe-call. [...etc...] ``` I second Nick's thought. Try adding a FIFO after the second split-stream port. Though on further inspection, I actually doubt this particular application would work at all, since it looks like you're trying to push 56 MHz through the RFNoC FPGA->ARM transport and then through ZMQ. The E310 definitely cannot handle that sort of load, and you might get undefined behavior in RFNOC fosphor because the underflow will propagate back to the RFNoC Radio and momentarily stop the RF stream before restarting... EJ On Thu, Nov 14, 2019 at 6:05 PM Nick Foster wrote: > I also haven't tested to see if this is a gr-ettus limitation or a UHD > limitation. > > On Thu, Nov 14, 2019 at 3:04 PM Nick Foster wrote: > >> You can't have heterogenous output destinations on RFNoC blocks -- i.e., >> you can't send one output to the host and one output to another RFNoC block. >> >> I'm not sure why this limitation exists as there is no architectural >> reason I can see. >> >> Nick >> >> On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart >> wrote: >> >>> Greetings EJ, >>> >>> So went and dug out the E312 b/c I couldn't wait and unfortunately that >>> didn't resolve the issue I was experiencing. I cherry picked the new >>> split_stream block, I am using the same flow graph as provided before, but >>> when it goes to run on the E312 I get the following error. >>> >>> Traceback (most recent call last): >>> File "rfnoc_fosphor_radio_network_usrp.py", line 281, in >>> main() >>> File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main >>> tb.start() >>> File >>> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", >>> line 109, in start >>> top_block_start_unlocked(self._impl, max_noutput_items) >>> File >>> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", >>> line 3671, in top_block_start_unlocked >>> return _runtime_swig.top_block_start_unlocked(*args, **kwargs) >>> RuntimeError: uhd_rfnoc_SplitStream(9): missing connection from output >>> port 0 >>> >>> Looks like something is missing from the split stream. I assume it needs >>> to be fixed in the verilog. >>> >>> I attached a screenshot of the new, cleaned up GNU radio file. I had to >>> remove a FIFO and switch to using a throttle b/c I wasn't able to get it >>> all to fit in the bit file. >>> >>> Regards, >>> Jon >>> >>> On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart < >>> jlockhar...@gmail.com> wrote: >>> Greetings EJ, Thanks for the info. I haven't had time to grab the new block as my dev box is packed for moving this weekend. I will get it downloaded and try it as soon as I can. Regards, Jon On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar wrote: > Hi there, > > Just want to chime in since I recently went through the upgrade > process to UHD-3.14... > > Can you confirm you're using uhd-3.14? If so, this is actually a > split stream fpga bug caused by the commit Jon referred to, not the "not > enough bandwidth" problem. > > Fortunately, rather than referring the old commit, the bug seems to > have been fixed in October on the master branch: https:// > github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9 > (but not yet ported onto 3.14) > > I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up > for me. > > I assume this will eventually make it to the UHD-3.14 branch? But if > not the cherry pick works fine > > EJ > > > On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Jonathon, >> >> I will give that a try and see if it works. >> >> >> Nick, >> >> If the revert on Split_Stream fails, I will try switching from ce_clk >> to bus_clk and give that a try. >> >> >> Regards, >> Jon >> >> On Fri, Nov 8, 2019 at 1:52 PM Nick Foster >> wrote: >> >>> Jonathon (Pendlum), correct me if I'm wrong, but I think this is the >>> usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem. >>> >>> Jonathan (Lockhart), if I'm right, then in your >>> rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the >>> noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix >>> the >>> problem. >>> >>> Nick >>> >>> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum < >>> jonathon.pend...@ettus.com> wrote: >>> Hi Jon, Can you try reverting commit
Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream
I also haven't tested to see if this is a gr-ettus limitation or a UHD limitation. On Thu, Nov 14, 2019 at 3:04 PM Nick Foster wrote: > You can't have heterogenous output destinations on RFNoC blocks -- i.e., > you can't send one output to the host and one output to another RFNoC block. > > I'm not sure why this limitation exists as there is no architectural > reason I can see. > > Nick > > On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart > wrote: > >> Greetings EJ, >> >> So went and dug out the E312 b/c I couldn't wait and unfortunately that >> didn't resolve the issue I was experiencing. I cherry picked the new >> split_stream block, I am using the same flow graph as provided before, but >> when it goes to run on the E312 I get the following error. >> >> Traceback (most recent call last): >> File "rfnoc_fosphor_radio_network_usrp.py", line 281, in >> main() >> File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main >> tb.start() >> File >> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", >> line 109, in start >> top_block_start_unlocked(self._impl, max_noutput_items) >> File >> "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", >> line 3671, in top_block_start_unlocked >> return _runtime_swig.top_block_start_unlocked(*args, **kwargs) >> RuntimeError: uhd_rfnoc_SplitStream(9): missing connection from output >> port 0 >> >> Looks like something is missing from the split stream. I assume it needs >> to be fixed in the verilog. >> >> I attached a screenshot of the new, cleaned up GNU radio file. I had to >> remove a FIFO and switch to using a throttle b/c I wasn't able to get it >> all to fit in the bit file. >> >> Regards, >> Jon >> >> On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart >> wrote: >> >>> Greetings EJ, >>> >>> Thanks for the info. I haven't had time to grab the new block as my dev >>> box is packed for moving this weekend. I will get it downloaded and try it >>> as soon as I can. >>> >>> Regards, >>> Jon >>> >>> On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar wrote: >>> Hi there, Just want to chime in since I recently went through the upgrade process to UHD-3.14... Can you confirm you're using uhd-3.14? If so, this is actually a split stream fpga bug caused by the commit Jon referred to, not the "not enough bandwidth" problem. Fortunately, rather than referring the old commit, the bug seems to have been fixed in October on the master branch: https:// github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9 (but not yet ported onto 3.14) I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for me. I assume this will eventually make it to the UHD-3.14 branch? But if not the cherry pick works fine EJ On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users < usrp-users@lists.ettus.com> wrote: > Jonathon, > > I will give that a try and see if it works. > > > Nick, > > If the revert on Split_Stream fails, I will try switching from ce_clk > to bus_clk and give that a try. > > > Regards, > Jon > > On Fri, Nov 8, 2019 at 1:52 PM Nick Foster > wrote: > >> Jonathon (Pendlum), correct me if I'm wrong, but I think this is the >> usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem. >> >> Jonathan (Lockhart), if I'm right, then in your >> rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the >> noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix the >> problem. >> >> Nick >> >> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum < >> jonathon.pend...@ettus.com> wrote: >> >>> Hi Jon, >>> >>> Can you try reverting commit e39334fe on the fpga repo and >>> rebuilding your bitstream? Let me know if that makes a difference or >>> not. >>> >>> Jonathon >>> >>> On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Greetings Nick, Here is the screenshot of my GR flow graph, though it shouldn't matter as the Split_Stream RFNoC Block I believe is a failure of the python or Verilog but the solutions in the link I sent in my previous email did not resolve the issue. [image: Screenshot from 2019-11-08 10-06-50.png] Regards, Jon On Thu, Nov 7, 2019 at 5:33 PM Nick Foster wrote: > Can you be more specific about what your flowgraph looks like? > > On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Greetings, >> >> I
Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream
You can't have heterogenous output destinations on RFNoC blocks -- i.e., you can't send one output to the host and one output to another RFNoC block. I'm not sure why this limitation exists as there is no architectural reason I can see. Nick On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart wrote: > Greetings EJ, > > So went and dug out the E312 b/c I couldn't wait and unfortunately that > didn't resolve the issue I was experiencing. I cherry picked the new > split_stream block, I am using the same flow graph as provided before, but > when it goes to run on the E312 I get the following error. > > Traceback (most recent call last): > File "rfnoc_fosphor_radio_network_usrp.py", line 281, in > main() > File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main > tb.start() > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", > line 109, in start > top_block_start_unlocked(self._impl, max_noutput_items) > File > "/home/root/localinstall/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", > line 3671, in top_block_start_unlocked > return _runtime_swig.top_block_start_unlocked(*args, **kwargs) > RuntimeError: uhd_rfnoc_SplitStream(9): missing connection from output > port 0 > > Looks like something is missing from the split stream. I assume it needs > to be fixed in the verilog. > > I attached a screenshot of the new, cleaned up GNU radio file. I had to > remove a FIFO and switch to using a throttle b/c I wasn't able to get it > all to fit in the bit file. > > Regards, > Jon > > On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart > wrote: > >> Greetings EJ, >> >> Thanks for the info. I haven't had time to grab the new block as my dev >> box is packed for moving this weekend. I will get it downloaded and try it >> as soon as I can. >> >> Regards, >> Jon >> >> On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar wrote: >> >>> Hi there, >>> >>> Just want to chime in since I recently went through the upgrade process >>> to UHD-3.14... >>> >>> Can you confirm you're using uhd-3.14? If so, this is actually a split >>> stream fpga bug caused by the commit Jon referred to, not the "not enough >>> bandwidth" problem. >>> >>> Fortunately, rather than referring the old commit, the bug seems to have >>> been fixed in October on the master branch: https:// >>> github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9 >>> (but not yet ported onto 3.14) >>> >>> I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for >>> me. >>> >>> I assume this will eventually make it to the UHD-3.14 branch? But if not >>> the cherry pick works fine >>> >>> EJ >>> >>> >>> On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Jonathon, I will give that a try and see if it works. Nick, If the revert on Split_Stream fails, I will try switching from ce_clk to bus_clk and give that a try. Regards, Jon On Fri, Nov 8, 2019 at 1:52 PM Nick Foster wrote: > Jonathon (Pendlum), correct me if I'm wrong, but I think this is the > usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem. > > Jonathan (Lockhart), if I'm right, then in your > rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the > noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix the > problem. > > Nick > > On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum < > jonathon.pend...@ettus.com> wrote: > >> Hi Jon, >> >> Can you try reverting commit e39334fe on the fpga repo and rebuilding >> your bitstream? Let me know if that makes a difference or not. >> >> Jonathon >> >> On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Greetings Nick, >>> >>> Here is the screenshot of my GR flow graph, though it shouldn't >>> matter as the Split_Stream RFNoC Block I believe is a failure of the >>> python >>> or Verilog but the solutions in the link I sent in my previous email did >>> not resolve the issue. >>> >>> [image: Screenshot from 2019-11-08 10-06-50.png] >>> >>> Regards, >>> Jon >>> >>> On Thu, Nov 7, 2019 at 5:33 PM Nick Foster >>> wrote: >>> Can you be more specific about what your flowgraph looks like? On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users < usrp-users@lists.ettus.com> wrote: > Greetings, > > I was wondering if anyone had encountered the following error and > had a way to fix it? > > [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700; > UHD_3.14.1.HEAD-0-g0347a6d8 > [INFO] [E300] Loading FPGA image: > /home/root/localinstall/e300.bit... >
Re: [USRP-users] Issues with RFNoC Component Test Bench
Greetings Brian,
Update: the noc_block_split_stream does work in the radio. However, it has
to be going to another hardware component first, like a FIFO, before it can
be passed to software blocks on the arm or the ZMQ to port to a host
machine. It was very interesting. I know in one of the troubleshooting
documents they recommended that, but it does appear to be necessary for
some blocks.
Regards,
Jon
On Thu, Nov 14, 2019 at 10:48 AM Jonathan Lockhart
wrote:
> Greetings Brian,
>
> I was having some issues with the build process, as the build script
> couldn't find the gain.v block file even though I was pointing the script
> to it. I saw that ejk github has some .inc files, so I added those and it
> seemed to clear up the issue. *crosses fingers* The bit file was building
> when I left for word this morning.
>
> Regards,
> Jon
>
> On Wed, Nov 13, 2019 at 12:32 PM Jonathan Lockhart
> wrote:
>
>> Greetings Brian,
>>
>> Thanks for the link. Yeah my Vivado always complains about the tcl cache
>> being unavailable unless I run as sudo. I think its b/c I installed it with
>> sudo, as otherwise it wouldn't make the /opt/Xilinx directory. It seems to
>> work either way regardless if it uses the official tcl cache or a local one.
>>
>> Anyways, that example worked out great. Now the sim could find the FPGA
>> repo and it tested on the 7020. I making a note of that so I can be sure to
>> incorporate those changes in the future for other blocks will build.
>>
>> Regards,
>> Jon
>>
>> On Wed, Nov 13, 2019 at 11:21 AM Brian Padalino
>> wrote:
>>
>>> Hey Jon,
>>>
>>> On Wed, Nov 13, 2019 at 11:17 AM Jonathan Lockhart <
>>> jlockhar...@gmail.com> wrote:
>>>
Greetings Brian,
I had noticed that the script was set to use the X300 after I sent the
email. I switched in the CMakeList.txt file to use the e300 repo, which is
using the Zynq-7020, which is included in the webpack version of Vivado. I
unfortunately got the same error prior to the change, included below.
ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
noc_block_gain_tb
Setting up a 64-bit FPGA build environment for the USRP-E3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
Environment successfully initialized.
BUILDER: Checking tools...
* GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
* Python 2.7.15+
* Vivado v2017.4.1 (64-bit)
** Vivado v2017.4.1 (64-bit)
SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
CRITICAL WARNING: [Common 17-741] No write access right to the local
Tcl store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
XilinxTclStore is reverted to the installation area. If you want to use
local Tcl Store, please change the access right and relaunch Vivado.
source
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
>>>
>>> This seems bad in general. Maybe because you ran it as sudo before and
>>> now non-sudo?
>>>
>>>
# set simulator $::env(VIV_SIMULATOR)
# set design_srcs $::env(VIV_DESIGN_SRCS)
# set sim_srcs$::env(VIV_SIM_SRCS)
# set inc_srcs$::env(VIV_INC_SRCS)
# set sim_top $::env(VIV_SIM_TOP)
# set part_name $::env(VIV_PART_NAME)
# set sim_runtime $::env(VIV_SIM_RUNTIME)
# set sim_fast$::env(VIV_SIM_FAST)
# set vivado_mode $::env(VIV_MODE)
# set working_dir [pwd]
# set sim_fileset "sim_1"
# set project_name "[string tolower $simulator]_proj"
# if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
# set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
# if [expr [file isdirectory $sim_complibdir] == 0] {
# set sim_complibdir ""
# }
# } else {
# set sim_complibdir ""
# }
# if [expr ([string equal $simulator "XSim"] == 0) && ([string length
$sim_complibdir] == 0)] {
# puts "BUILDER: \[ERROR\]: Could not resolve the location for the
compiled simulation libraries."
# puts " Please build libraries for chosen
simulator and set the env or"
# puts " makefile variable SIM_COMPLIBDIR to point
to the location."
# exit 1
# }
# puts "BUILDER: Creating Vivado simulation project part $part_name"
BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
# create_project -part $part_name -force $project_name/$project_name
WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
ERROR: [Coretcl 2-106] Specified part could not be found.
INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
/home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
recipe for
Re: [USRP-users] Issues with RFNoC Component Test Bench
Greetings Brian,
I was having some issues with the build process, as the build script
couldn't find the gain.v block file even though I was pointing the script
to it. I saw that ejk github has some .inc files, so I added those and it
seemed to clear up the issue. *crosses fingers* The bit file was building
when I left for word this morning.
Regards,
Jon
On Wed, Nov 13, 2019 at 12:32 PM Jonathan Lockhart
wrote:
> Greetings Brian,
>
> Thanks for the link. Yeah my Vivado always complains about the tcl cache
> being unavailable unless I run as sudo. I think its b/c I installed it with
> sudo, as otherwise it wouldn't make the /opt/Xilinx directory. It seems to
> work either way regardless if it uses the official tcl cache or a local one.
>
> Anyways, that example worked out great. Now the sim could find the FPGA
> repo and it tested on the 7020. I making a note of that so I can be sure to
> incorporate those changes in the future for other blocks will build.
>
> Regards,
> Jon
>
> On Wed, Nov 13, 2019 at 11:21 AM Brian Padalino
> wrote:
>
>> Hey Jon,
>>
>> On Wed, Nov 13, 2019 at 11:17 AM Jonathan Lockhart
>> wrote:
>>
>>> Greetings Brian,
>>>
>>> I had noticed that the script was set to use the X300 after I sent the
>>> email. I switched in the CMakeList.txt file to use the e300 repo, which is
>>> using the Zynq-7020, which is included in the webpack version of Vivado. I
>>> unfortunately got the same error prior to the change, included below.
>>>
>>> ettus_sdr@ettus-VirtualBox:~/rfnoc/src/rfnoc-tutorial/build$ make
>>> noc_block_gain_tb
>>> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
>>> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>>>
>>> Environment successfully initialized.
>>> BUILDER: Checking tools...
>>> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
>>> * Python 2.7.15+
>>> * Vivado v2017.4.1 (64-bit)
>>>
>>> ** Vivado v2017.4.1 (64-bit)
>>> SW Build 2117270 on Tue Jan 30 15:31:13 MST 2018
>>> IP Build 2095745 on Tue Jan 30 17:13:15 MST 2018
>>> ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.
>>>
>>> CRITICAL WARNING: [Common 17-741] No write access right to the local Tcl
>>> store at '/home/ettus_sdr/.Xilinx/Vivado/2017.4/XilinxTclStore'.
>>> XilinxTclStore is reverted to the installation area. If you want to use
>>> local Tcl Store, please change the access right and relaunch Vivado.
>>> source
>>> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/tools/scripts/viv_sim_project.tcl
>>>
>>
>> This seems bad in general. Maybe because you ran it as sudo before and
>> now non-sudo?
>>
>>
>>> # set simulator $::env(VIV_SIMULATOR)
>>> # set design_srcs $::env(VIV_DESIGN_SRCS)
>>> # set sim_srcs$::env(VIV_SIM_SRCS)
>>> # set inc_srcs$::env(VIV_INC_SRCS)
>>> # set sim_top $::env(VIV_SIM_TOP)
>>> # set part_name $::env(VIV_PART_NAME)
>>> # set sim_runtime $::env(VIV_SIM_RUNTIME)
>>> # set sim_fast$::env(VIV_SIM_FAST)
>>> # set vivado_mode $::env(VIV_MODE)
>>> # set working_dir [pwd]
>>> # set sim_fileset "sim_1"
>>> # set project_name "[string tolower $simulator]_proj"
>>> # if [info exists ::env(VIV_SIM_COMPLIBDIR) ] {
>>> # set sim_complibdir $::env(VIV_SIM_COMPLIBDIR)
>>> # if [expr [file isdirectory $sim_complibdir] == 0] {
>>> # set sim_complibdir ""
>>> # }
>>> # } else {
>>> # set sim_complibdir ""
>>> # }
>>> # if [expr ([string equal $simulator "XSim"] == 0) && ([string length
>>> $sim_complibdir] == 0)] {
>>> # puts "BUILDER: \[ERROR\]: Could not resolve the location for the
>>> compiled simulation libraries."
>>> # puts " Please build libraries for chosen
>>> simulator and set the env or"
>>> # puts " makefile variable SIM_COMPLIBDIR to point
>>> to the location."
>>> # exit 1
>>> # }
>>> # puts "BUILDER: Creating Vivado simulation project part $part_name"
>>> BUILDER: Creating Vivado simulation project part xc7k410tffg900-2
>>> # create_project -part $part_name -force $project_name/$project_name
>>> WARNING: [Device 21-436] No parts matched 'xc7k410tffg900-2'
>>> ERROR: [Coretcl 2-106] Specified part could not be found.
>>> INFO: [Common 17-206] Exiting Vivado at Wed Nov 13 11:07:09 2019...
>>> /home/ettus_sdr/rfnoc/src/uhd/fpga-src/usrp3/top/../tools/make/viv_simulator.mak:51:
>>> recipe for target 'xsim' failed
>>> make[4]: *** [xsim] Error 1
>>> CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
>>> 'CMakeFiles/noc_block_gain_tb' failed
>>> make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 2
>>> CMakeFiles/Makefile2:131: recipe for target
>>> 'CMakeFiles/noc_block_gain_tb.dir/all' failed
>>> make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
>>> CMakeFiles/Makefile2:138: recipe for target
>>> 'CMakeFiles/noc_block_gain_tb.dir/rule' failed
>>> make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
>>> Makefile:201: recipe for target 'noc_block_gain_tb' failed
