Thanks Wade, then I'll check my clock domain crossings, guess I need a fifo between them.
Kind Regards, Maria El mar., 14 jun. 2022 20:47, Wade Fife <wade.f...@ettus.com> escribió: > Hi Maria, > > In the timing paths, take a look at the source clock and destination > clock. Are they the same clock? If not, then maybe you haven't handled the > clock domain crossings correctly. If you lowered the clock frequency, the > number of failing paths should go down, but if there are clock crossings > being analyzed by the tool then the number can go up. > > The constraint file for the clock generator IP isn't usually needed > because we create all the base clocks and Vivado will automatically infer > the derived clocks generated by the clock wizard IP. You should be able to > look at the clock report to confirm that all the clocks are being > constrained the way you expect. > > Wade > > On Tue, Jun 14, 2022 at 12:27 PM Maria Muñoz <mamuk...@gmail.com> wrote: > >> Hi again Wade, >> >> After making some synthesis with and without the clock wizard ip, I have >> observed that there is higher timing paths for those which use the ip >> rather than the ones which don't. >> I am lowing the clock for the design so I would expect the opposite >> behaviour. Alongside with the verilog files generated in Vivado, there is a >> constraint file for the clocking wizard which I think I should include. >> Do you include this file on the rfnoc framework when using this ip? Where >> should I include this file? >> >> Kind Regards, >> >> Maria >> >> El lun., 6 jun. 2022 21:50, Wade Fife <wade.f...@ettus.com> escribió: >> >>> You're right. It really depends on the IP. Some are very complicated >>> (hundreds of files) and it makes sense to try to use the XCI and let Vivado >>> do the work of figuring out all the dependencies. For the clk_wiz, I think >>> it makes more sense to just reference the .v files generated by Vivado, or >>> just copy/paste the generated code you need and paste it into your design. >>> >>> Wade >>> >>> On Mon, Jun 6, 2022 at 9:40 AM Maria Muñoz <mamuk...@gmail.com> wrote: >>> >>>> Hi all, >>>> >>>> Thanks for your answers. >>>> >>>> Wade, you are correct, I am trying to instance a clock wizard for an >>>> x310 project. In my VHDL/Verilog Makefile.srcs, I have included the >>>> clk_wiz_0.v and clk_wiz_0_clk_wiz.v files as you said and, for now, >>>> synthesis is not complaining, so it seems to work (I guess I do not have to >>>> include the "vh" files that Vivado use, do I?) >>>> I had tried to do this in the past with other IP but there were so many >>>> missing sources... So I will also check the other way you propose to >>>> include the .xci source. >>>> Again many thanks for your answer! >>>> >>>> Kind Regards, >>>> Maria >>>> >>>> El lun, 6 jun 2022 a las 15:45, Wade Fife (<wade.f...@ettus.com>) >>>> escribió: >>>> >>>>> Hi Maria, >>>>> >>>>> Which IP are you trying to include? And is it failing when trying to >>>>> simulate or only when building the FPGA? Some IP are easier to include >>>>> than >>>>> others. From your examples, it looked like you were trying to include the >>>>> clock wizard. For that IP I usually just copy the MMCM or PLL code that >>>>> Vivado generates rather than including the XCI, since the generated code >>>>> is >>>>> mostly just a single primitive, but I think referencing the XCI should >>>>> also >>>>> work. >>>>> >>>>> So this is not the only way to do it, but the example we have for how >>>>> to include IP in an OOT block is here: >>>>> >>>>> https://github.com/EttusResearch/uhd/tree/master/host/examples/rfnoc-example/fpga/ip/cmplx_mul >>>>> >>>>> To use this IP example, you need to include these lines in your OOT >>>>> block's makefile (which is used for simulation): >>>>> >>>>> https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/host/examples/rfnoc-example/fpga/rfnoc_block_gain/Makefile#L28 >>>>> >>>>> https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/host/examples/rfnoc-example/fpga/rfnoc_block_gain/Makefile#L29 >>>>> >>>>> And add it to the Makefile.srcs for your block: >>>>> >>>>> https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/host/examples/rfnoc-example/fpga/Makefile.srcs#L15 >>>>> >>>>> https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/host/examples/rfnoc-example/fpga/Makefile.srcs#L16 >>>>> >>>>> Note also how it gets added to LIB_IP_XCI_SRCS. This is already >>>>> include in the examles FPGA (X310): >>>>> >>>>> https://github.com/EttusResearch/uhd/blob/5333d3d12ffc21229ec4203a9ea1c7f68d82e57f/fpga/usrp3/top/x300/Makefile.x300.inc#L109 >>>>> >>>>> Make sure that line exists for the FPGA you are trying to build. But >>>>> it looked like you were building an x300 variant, so it should be there. >>>>> >>>>> Wade >>>>> >>>>> >>>>> On Mon, Jun 6, 2022 at 3:21 AM sp h <stackprogra...@gmail.com> wrote: >>>>> >>>>>> Ok, I'll take a look. I had a question for creating your custom RFNOC >>>>>> block do you use rfnocmodtool creator? >>>>>> I think for using an IP core from Xilinx in your >>>>>> rfnoc_rfnocblock_blockname.v, you should see a folder in the UHD driver? >>>>>> I worked with x300 series RFNOC block, In a folder on this path >>>>>> (/home/sp/Documents/uhd-4.2.0.0/fpga/usrp3/lib >>>>>> ) exist a folder as name ip.. >>>>>> IP cores that we need should be defined in the UHD driver folder... >>>>>> Your IP list should be added to this folder and changed makefiles >>>>>> carefully!!!! >>>>>> >>>>>> Before you complete your development may be useful this info that we >>>>>> follow... >>>>>> 1)Do you make the default UHD FPGA image successfully? Does it work? >>>>>> For me, the default UHD FPGA that I make bitstream myself works fine. >>>>>> >>>>>> 2)But !!! When I want to change RFNOC blocks for example Added an FFT >>>>>> block, Radiocores, DDC, and DUC work but >>>>>> for FFT and new blocks that I added it does not work. >>>>>> It generates OOOOO I described it in the below link >>>>>> >>>>>> https://lists.ettus.com/empathy/thread/VJB7A53C6X77JN7DPP3ATASYO4MAH7GH >>>>>> >>>>>> 3)When I created a custom RFNOC block, Testbench and generate >>>>>> bitstream is ok but for working RFNOC block in GNURadio I faced with >>>>>> error >>>>>> section 2. Generate OOOOOO in Gnuradio >>>>>> >>>>>> >>>>>> [image: Screenshot from 2022-06-06 12-34-22.png] >>>>>> >>>>>> For using IP core directly I think you are not familiar with >>>>>> noc_shell and RFNOC module structure... >>>>>> >>>>>> On Sun, Jun 5, 2022 at 10:12 PM Maria Muñoz <mamuk...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for the answer. >>>>>>> I think that what I'm trying to do should be possible since the >>>>>>> addsub example has an option for a hls instance. Maybe I have not >>>>>>> explain >>>>>>> myself well. >>>>>>> I have a top level module which includes several .vhd sources >>>>>>> alongside with an ip from xilinx. I can instance this top level entity >>>>>>> in >>>>>>> the rfnoc_rfnocblock_blockname.v and I can synthesize it if my top_level >>>>>>> hasn't include any ip core. But when I have this IP instanced inside my >>>>>>> top_level, the makefile chain can't read or regenerate the ip core from >>>>>>> the >>>>>>> source file (which is an .xci file). >>>>>>> What I do not know is how to add the .xci source to the Makefiles so >>>>>>> the vivado scripts (which are called when I do "rfnoc_image_builder") >>>>>>> synthesize it. >>>>>>> >>>>>>> Kind Regards, >>>>>>> Maria >>>>>>> >>>>>>> >>>>>>> El dom., 5 jun. 2022 18:50, sp h <stackprogra...@gmail.com> >>>>>>> escribió: >>>>>>> >>>>>>>> Hi, You should not expect that integrate or add Xilinx IP core >>>>>>>> directly to RFNOC blocks, Even If you be a master in Verilog... >>>>>>>> If you see the UHD source code you will realize that UHD is an >>>>>>>> RFNOC framework for USRP ... >>>>>>>> For working with the RFNOC UHD framework you should know more >>>>>>>> details: >>>>>>>> 1)Please see this link >>>>>>>> https://files.ettus.com/app_notes/RFNoC_Specification.pdf >>>>>>>> 2)Any RFNOC block has two files, noc_shell_blockname.v and >>>>>>>> rfnoc_block_blockname.v these two file are very important >>>>>>>> the first file is a low-level definition for the RFNOC block and >>>>>>>> the second file is the high-level definition for the block. I mention >>>>>>>> that >>>>>>>> we should use IP core in the second file ... >>>>>>>> And more details that you should study UHD source code till getting >>>>>>>> them... >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 3, 2022 at 6:03 PM Rob Kossler <rkoss...@nd.edu> wrote: >>>>>>>> >>>>>>>>> Hi Maria, >>>>>>>>> I apologize but I am not very experienced with these matters. I am >>>>>>>>> able to copy the rfnoc-example folder to an OOT location and build it >>>>>>>>> and I >>>>>>>>> know it has both OOT and in-tree IP options. In the past I have >>>>>>>>> successfully run the 'make <testbench>' and also built an image such >>>>>>>>> as >>>>>>>>> "make <x300_core>". But, outside of that, I don't really know what I'm >>>>>>>>> doing.... >>>>>>>>> Rob >>>>>>>>> >>>>>>>>> On Fri, Jun 3, 2022 at 9:05 AM Maria Muñoz <mamuk...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Rob, >>>>>>>>>> >>>>>>>>>> I try to put these lines in the makefile.srcs inside >>>>>>>>>> my_block/fpga folder as in the rfnoc example: >>>>>>>>>> >>>>>>>>>> #RFNOC_OOT_SRCS += $(abspath $(addprefix ${RFNOC_EXAMPLE_DIR}, >>>>>>>>>> #my_other_module.v \ >>>>>>>>>> #ip/my_ip_core/my_ip_core.xci \ >>>>>>>>>> #)) >>>>>>>>>> >>>>>>>>>> I add my .xci IP to this folder and give the name of the IP as a >>>>>>>>>> rfnoc_oot_src. I can compile the block but when I try to perform >>>>>>>>>> synthesis >>>>>>>>>> it gives me this error: >>>>>>>>>> >>>>>>>>>> ERROR: [DRC INBB-3] Black Box Instances: Cell >>>>>>>>>> 'x300_core/bus_int_i/rfnoc_sandbox_i/b_3/top_i/my_clk' of type >>>>>>>>>> 'clk_wiz_0' >>>>>>>>>> has undefined contents and is considered a black box. The contents >>>>>>>>>> of this >>>>>>>>>> cell must be defined for opt_design to complete successfully. >>>>>>>>>> ERROR: [Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design >>>>>>>>>> not run. >>>>>>>>>> ERROR: [Common 17-39] 'opt_design' failed due to earlier errors. >>>>>>>>>> >>>>>>>>>> So I think I am missing something. I do not see anything else >>>>>>>>>> related to IP core. Is there something else I have to do? >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Maria >>>>>>>>>> >>>>>>>>>> El mié, 1 jun 2022 a las 17:48, Rob Kossler (<rkoss...@nd.edu>) >>>>>>>>>> escribió: >>>>>>>>>> >>>>>>>>>>> Hi Maria, >>>>>>>>>>> The rfnoc-example folder within the UHD tree shows an example of >>>>>>>>>>> how to add an out-of-tree IP block. Did you look at this yet? >>>>>>>>>>> Rob >>>>>>>>>>> >>>>>>>>>>> On Wed, Jun 1, 2022 at 5:12 AM Maria Muñoz <mamuk...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I'm trying to synthesize a design that includes a vivado ip >>>>>>>>>>>> core inside. >>>>>>>>>>>> Normally, I add my .vhd/.v source files to the Makefile.srcs >>>>>>>>>>>> inside my block like this: >>>>>>>>>>>> >>>>>>>>>>>> RFNOC_OOT_SRCS += $(addprefix $(dir $(abspath $(lastword >>>>>>>>>>>> $(MAKEFILE_LIST)))), \ >>>>>>>>>>>> source1.vhd \ >>>>>>>>>>>> source2.v \ >>>>>>>>>>>> source3.v \ >>>>>>>>>>>> ) >>>>>>>>>>>> >>>>>>>>>>>> But adding the .xci file of my IP core does not work. >>>>>>>>>>>> >>>>>>>>>>>> What is the process to include this file in the makefile chain >>>>>>>>>>>> to compile it? >>>>>>>>>>>> >>>>>>>>>>>> Kind Regards, >>>>>>>>>>>> >>>>>>>>>>>> Maria. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>>>>> To unsubscribe send an email to >>>>>>>>>>>> usrp-users-le...@lists.ettus.com >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>> >>>>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
