Hi Martin, Thank you for your reply. Sorry for the delayed update. So I tried a few combinations to see what works- - Derived clocks from ce_clk (266Mhz), implementation failed in the routing step. I introduced clocking wizard IP inside the noc_shell module to derive the 2 clocks I wanted. There were timing violations for the higher clock that connected to my block. - Derived clocks from rfnoc_chdr_clk (200Mhz). Same as the previous one. One thing I noticed was there were some high fanout logics, so I thought maybe I will generate clocks similar to ce_clk from the clk200.
So finally with changes in x4xx.sv, x4xx_core.v and x410_bsp.yml files I was able to get 2 new clocks and connected it to my block. With this I was able to generate the bitfile, but I have not tested it yet. I also noticed that the fanouts decreased drastically with this change. I am currently writing the controller code for the blocks so that I can connect it in GNU Radio. Thanks for the help! I was able to understand the configuration file a bit better with the example you shared. -J On Mon, 28 Jul 2025 at 15:53, Martin Braun <[email protected]> wrote: > Hey Jons, > > if you're generating and using a custom clock within your RFNoC block, > then there is nothing from RFNoC that you need. Unless you're exporting > your clock, you don't need to declare it anywhere. > > However, you *do* need to follow all the Vivado/Digital design guidelines > for adding clocks (i.e., stuff that is unrelated to RFNoC specifically). If > you need to inject custom constraints, you can do that from your block > YAML. Just add .xdc files in the same directory where your HDL is, and > refer to them in the YAML like we do here: > https://github.com/EttusResearch/rfnoc-oot-blocks/blob/main/rfnoc/blocks/aurora.yml > > --M > > On Sun, Jul 27, 2025 at 7:28 PM Jons <[email protected]> wrote: > >> Hi all, >> I am trying to add a custom RFNoC block and my block runs on different >> clocks(not the default ones). So I followed the instructions from the FAQ >> page in RFNoC wiki of deriving clocks from the available clocks - >> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_a_clock_with_a_different_frequency.3F >> But when I add the parameters in block YAML, it added new ports to my >> *rfnoc_block_myblock* module, which is not what I expected. My intention >> was to derive 2 clocks from the rfnoc_chdr_clk and use it inside my block. >> For this I added the clock IP module (instantiated) in the >> noc_shell_myblock, because this is where the CDC FIFOs are there. So, with >> this method the generated clock just stays inside my block and won't be >> available outside to it. Maybe the steps described in the FAQ might not be >> the right way to go about with my requirement? I am not sure. >> >> Also, I tried not adding the YAML parameters of the clocks for my block. >> This worked to the point where the implementation of the entire design >> failed with WNS of -0.8ns on the new derived clock I added. I also got a >> few Critical warnings for the clocks I added, not sure if it is related >> somehow or if I can ignore it - >> >> >> >> *TIMING-4#1 Critical WarningInvalid primary clock redefinition on a clock >> tree Invalid clock redefinition on a clock tree. The primary clock >> x4xx_core_i/rfnoc_image_core_i/b_myblock_3/noc_shell_myblock_i/clk_wiz_chdr_200_125_inst/inst/clk_in_chdr >> is defined downstream of clock clk200 and overrides its insertion delay >> and/or waveform definition. * >> >> I followed this thread ( >> https://www.mail-archive.com/usrp-users%40lists.ettus.com/msg14663.html) >> to add IPs of my clock module that I generated with with Vivado IP catalog >> and copied the *.xci, .v* and other generated files into the >> path/to/module/rfnoc/fpga/myblock/ip/ and changed the Makefile and block >> YAML definitions like the example given in the example Gain block. >> >> I checked the timing summary report and I found that the violation >> happens in the derived clock that connects to one of my blocks. I was able >> to build the IP by itself when I was testing it for viability. >> >> Any tips or leads in adding custom derived clocks to the design would be >> super helpful and thank you all for maintaining such a nice community!! >> -J >> >> _______________________________________________ >> 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] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
