Regarding the overflows, that's the kind of thing I would simulate to understand what's happening. My guess is the zero insertion is blocking the flow of data, and the radio overflows because of that. Like you said, a bigger buffer should help.
Hmm, I was just glancing at the code generated by the RFNoC image builder and the way it's setting the buffers doesn't look right, so perhaps you're not getting the buffering you expect. Let me look into that and get back to you. As for fitting, I would start by removing everything you don't need from the YAML description. Do you need all 4 radio channels? Do you need RX and TX? Do you need 4 channels of replay? Do you need the DDC and DUC (if you only want to run at the master clock rate then you don't). Strip out all the blocks you don't need and all their stream endpoints. If it still doesn't fit, then I would look at reducing the endpoint buffer sizes. The default images usually make them as large as we could fit, but you might be able to get away with smaller buffers, which really only affects TX streaming performance. Wade On Fri, Feb 25, 2022 at 4:19 PM Rob Kossler <rkoss...@nd.edu> wrote: > 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
