I was able to build successfully with the 'dram' clock as the 'ce' clock for my rfnoc block. But, I didn't get the performance I was expecting. With my rfnoc graph of "Radio->DDC->custom-zero-padded-fft-block", the Radio had overflows when running at 125e6 but worked well when running 62.5e6.
My current thought is that maybe I don't have enough input buffering in my custom rfnoc block. I initially had my payload input and output buffer sizes (defined in the block def yaml) set to 'MTU' which is how the DDC block does it. But, when my build failed (attempting to add 4 of my custom blocks), I changed this from 'MTU' to '32'. Turns out that this didn't help my build succeed, but I did get a successful build after removing all Replay blocks / SEPs. So I am now trying to re-build with the 'MTU' setting with the hope that the increased buffering will allow me to run at 125e6 sample rate. But, apart from more buffering, is there perhaps a different explanation why my custom FFT block clocked at 300 MHz (with 50% insertion of zeros) is not keeping up? On a semi-related topic, I'm wondering if anyone has suggestions regarding my build failures. The build error indicates that I needed more slices than are available (out of 69350 total, 47879 are available, but I needed 49414). If I look at the build report for the default Ettus N310 XG image (see snippet below), it looks like there is not much availability for extra rfnoc blocks (96.44% util%). And, in my experience, this is where my builds usually fail. I am wondering what I can do in the design of my custom blocks (or in the build parameters of the N310) to achieve successful builds - specifically related to this slice utilization. Any suggestions welcome. Thanks. Rob // From build report of default Ettus N310 XG image 2. Slice Logic Distribution --------------------------- +--------------------------------------------+--------+-----------+-------+ | Site Type | Used | Available | Util% | +--------------------------------------------+--------+-----------+-------+ | Slice | 66878 | 69350 | 96.44 | | SLICEL | 40816 | | | | SLICEM | 26062 | | | On Thu, Feb 24, 2022 at 9:25 PM Rob Kossler <rkoss...@nd.edu> wrote: > Thanks for the suggestions Wade. I will first try the low-hanging fruit of > using the 300MHz DRAM clock. Fingers crossed! > Rob > > On Thu, Feb 24, 2022 at 6:43 PM Wade Fife <wade.f...@ettus.com> wrote: > >> Hi Rob, >> >> RFNoC doesn't support generating user clocks for you yet (the range value >> is not currently used). You could use the `dram` clock on N310 and connect >> that to the `ce` inputs of your blocks. That should be about 300 MHz. The >> `rfnoc_chdr` clock is 200 MHz on N310. >> >> If it won't close timing with the dram clock, and you want something >> slower, then you can modify the HDL to add the clock you want. Take a look >> at n3xx_clocking.v. You could probably modify the misc_clock_gen IP block >> to add a clock closer to 260 MHz. You'd then have to route that clock into >> n3xx_core then rfnoc_image_core, and add the new clock to n310_bsp.yml for >> the rfnoc_image_builder to generate code to use it. Adding custom clocks is >> a pretty manual process at the moment. >> >> Wade >> >> On Wed, Feb 23, 2022 at 10:15 PM Rob Kossler <rkoss...@nd.edu> wrote: >> >>> Hi, >>> I have a signal processing block that includes a zero-padded FFT (50% >>> zeros) that I built for the N310. Because of the throttling that occurs >>> during insertion of zeros, I expect that my FFT will need to be clocked at >>> a bit more than twice the max sample rate. So, since I want to operate the >>> N310 at the highest sample rate of 125 MS/s, it seems that my FFT will need >>> to be clocked >= 260 MHz. I'm wondering how to do it. >>> >>> I've looked at the RFNoC specification and my block is already set up to >>> use the "CE" clock for both control & data. In the rfnoc spec, it mentions >>> that I can enter a "range" for my clock in the block definition yaml. But, >>> I also see that in the end, the top N310 yaml will require me to map a >>> _device clock to my block's CE clock port. >>> >>> It's not clear to me how this works. Does it help to provide a range in >>> the block definition yaml? Or, perhaps it is even necessary? How do I >>> specify in the top N310 yaml which device clock will map to my blocks CE >>> clock port? It seems to me that I am missing a step (defining a clock >>> somewhere?). >>> >>> I am pretty much a novice, so I expect that this is the cause of my >>> confusion. I am even struggling to figure out what the current clock rates >>> are (rfnoc_ctrl, rfnoc_chdr, ce, etc) and where they are defined. Any help >>> would be appreciated. >>> Rob >>> _______________________________________________ >>> 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
