Closed TSlivede closed 3 years ago
@TSlivede Thank you for submitting this issue! I submitted a fix and removed that TODO, so you shouldn't have to manually specify the ARCH or PART_ID anymore once the fix shows up.
It's not a bad idea to install Kintex-7 support regardless because several testbenches in the repo request that ARCH/PART_ID when running. I usually install Zynq and Kintex support so that I don't run into any issues with parts not being installed. We've also recently added Zynq UltraScale+ RFSoC products, so I've started installing that one as well.
Issue Description
When trying to run the testbench for the example rfnoc module, it was configured for the USRP X310. As I am using the USRP N310, I at first installed Xilinx Vivado with only Zync device support (so I had no device support installed for the FPGA used in the x310). I changed the
UHD_FPGA_DEFAULT_DEVICE
from x310 to n310 in myCMakeLists.txt
, butmake testbenches
still tried to compile for the fpga that is used in the x310. The cause seems to be, that viv_sim_preamble.mak always assigns that part_id as the default. (There is a TODO note above, that suggests, thatPART_ID
should be set from setupenv.sh, but that's currently not the case.) RunningARCH=zynq PART_ID=xc7z100/ffg900/-2 make testbenches
actually tries to build for the correct FPGA as expected.Setup Details
Expected Behavior
I expected, that running
make testbenches
would work for other usrp devices, if that device was selected viaUHD_FPGA_DEFAULT_DEVICE
inCMakeLists.txt
.Actual Behaviour
Running
ARCH=zynq PART_ID=xc7z100/ffg900/-2 make testbenches
seems to work. Forgetting theARCH=zynq
part leads to:Steps to reproduce the problem
Essentially as described in https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0#Creating_Your_Own_OOT_Module but change desired UHD_FPGA_DEFAULT_DEVICE to n310 and set PART_ID to the fpga that is acually used in the usrp n310:
If in the last line you execute just
make testbenches
, the changed setting in CMakeLists.txt is ignored.Additional Information
I'm not able to reproduce it, so I might remember incorrectly, but I think I could previously solve the problem without the
ARCH=zynq
part before make, but I needed to change blocks liketo
(i.e. adding the
sim/.....
line) in cmplx_mul/Makefile.inc (the one within my copy of the example project) and fpga/usrp3/lib/ip/complex_multiplier/Makefile.inc. (For completeness, the otherfpga/usrp3/lib/ip/*/Makefile.inc
files should probably also be changed.)I also changed the
fpga/ip/cmplx_mul/cmplx_mul.xci
so it is configured for the correct fpga. I ran(this is essentially, what
viv_modify_ip
does, but I hardcoded the device in the command) and in vivado sellected "upgrade IP" as it was currently locked because the device was changed.As
ARCH=zynq PART_ID=xc7z100/ffg900/-2 make testbenches
seems to work, the problem is far less bad than I initially assumed (before editing this issue). I think ifviv_sim_preamble.mak
would default to the device matching the lastfpga/usrp3/top/n3xx/setupenv.sh
command (as suggested in the TODO note), then most of my problems would have been avoided.