Ok, thanks for the clarification. German
On Fri, Dec 22, 2023, 4:55 PM Wade Fife <[email protected]> wrote: > Hi German, > > The critical warning sounds ominous but can be safely ignored. The > licenses are included with Vivado, but Vivado gives the warning anyway. As > long as you have a Vivado license, and a bitstream was generated, the 10 > GbE IP should work fine. > > Wade > > On Thu, Dec 21, 2023 at 11:20 AM German Farinas <[email protected]> > wrote: > >> Update on this. Looking at the build log I found this: >> >> Evaluation cores found in this design: >> IP core 'ten_gig_eth_pcs_pma' (ten_gig_eth_pcs_pma_v6_0_19) was >> generated using a design_linking license. >> >> Resolution: If a new IP Core license was added, in order for the new >> license to be picked up, the current netlist needs to be updated by >> resetting and re-generating the IP output products before bitstream >> generation. >> >> How do I regenerate the IP core? >> >> Best, >> German >> >> On Wed, Dec 20, 2023 at 10:48 PM German Farinas <[email protected]> >> wrote: >> >>> Hello, >>> >>> I ran the example in this guide ( >>> https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0) to add a >>> new FFT RFNoC block. I modify the default yaml file and run the following >>> command: >>> >>> rfnoc_image_builder -y x300_with_fft.yml -t X300_HG -F ../../../ >>> >>> Everything went well and the bitstream file was successfully generated. >>> I uploaded to my USRP X300 with the following command: uhd_image_loader >>> --args "type=x300,addr=192.168.10.2" --fpga-path >>> ./build/usrp_x300_fpga_HG.bin >>> >>> after loading the new image this is the output to the *uhd_usrp_probe >>> --args type=x300* command: >>> >>> RFNoC blocks on this device: >>> | | >>> | | * 0/DDC#0 >>> | | * 0/DDC#1 >>> | | * 0/DUC#0 >>> | | * 0/DUC#1 >>> | | * 0/FFT#0 >>> | | * 0/Radio#0 >>> | | * 0/Radio#1 >>> | | * 0/Replay#0 >>> | _____________________________________________________ >>> | / >>> | | Static connections on this device: >>> | | >>> | | * 0/SEP#0:0==>0/DUC#0:0 >>> | | * 0/DUC#0:0==>0/Radio#0:0 >>> | | * 0/Radio#0:0==>0/DDC#0:0 >>> | | * 0/DDC#0:0==>0/SEP#0:0 >>> | | * 0/Radio#0:1==>0/DDC#0:1 >>> | | * 0/DDC#0:1==>0/SEP#1:0 >>> | | * 0/SEP#2:0==>0/DUC#1:0 >>> | | * 0/DUC#1:0==>0/Radio#1:0 >>> | | * 0/Radio#1:0==>0/DDC#1:0 >>> | | * 0/DDC#1:0==>0/SEP#2:0 >>> | | * 0/Radio#1:1==>0/DDC#1:1 >>> | | * 0/DDC#1:1==>0/SEP#3:0 >>> | | * 0/SEP#4:0==>0/Replay#0:0 >>> | | * 0/Replay#0:0==>0/SEP#4:0 >>> | | * 0/SEP#5:0==>0/Replay#0:1 >>> | | * 0/Replay#0:1==>0/SEP#5:0 >>> | | * 0/SEP#6:0==>0/FFT#0:0 >>> | | * 0/FFT#0:0==>0/SEP#6:0 >>> >>> Everything apparently looks good because the FFT was inserted. However >>> during the last phase of the vivado tools flow, after synthesis, place, >>> route, etc, during the *BUILDER: Writing bitfile *phase it issues the >>> following supposedly critical warning: >>> >>> *CRITICAL WARNING: [Vivado 12-1790] Evaluation License Warning: This >>> design contains one or more evaluation cores that will cease to function >>> after a certain period of time. This design should NOT be used in >>> production systems.* >>> >>> I think it may be the FFT IP core but I am not sure. I have Vivado >>> v2021.1_AR76780 ML with an Enterprise Edition license. The version is 2021 >>> because this is the version supported by Ettus for building FPGA images. My >>> license goes up to 2023.1 limit, but this should not affect me because I am >>> using the 2021 version. I compiled the default images and I don't recall >>> receiving this critical warning. >>> >>> Anyone had the same issue? Any help or explanation to this? Is this >>> something I should worry about ? >>> >>> Best regards, >>> German >>> >>> _______________________________________________ >> USRP-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
