Hi Edwin, I have completed some similar blocks. Even though your desired block is very similar in function to keep_one_in_n, you might consider modeling your block instead using the DDC example, which incorporates the axi_rate_change module. And, since this module uses the older settings bus and 128-bit tuser signal, you might consider using the ctrlport_to_settings_bus module and re-building tuser from the sideband signals (as in the DDC example).
The axi_rate_change module will set the output packet size the same as the input packet size, regardless of your values for M and N (note that your defs of M and N are not quite the same as axi_rate_change defs of M and N). Regarding your question about how to mark the end of frames, that is a bit trickier. You could use either EOB or EOV, or you could do things on the UHD side where your block controller knows M and N and can thus know that each Mth sample is an end-of-frame. Rob On Fri, Apr 23, 2021 at 4:18 PM Edwin Harmon <[email protected]> wrote: > I would like to implement a gating function block with RFNoc 4 that passes > M samples from the input to the output unmodified, "drops" the next N > samples, and repeats indefinitely. > > This is obviously a generalization of the keep_one_in_n > <https://github.com/EttusResearch/fpga/blob/UHD-3.15.LTS/usrp3/lib/rfnoc/keep_one_in_n.v> > block, so I am using this as my starting point with vector_mode always > false. I've looked over the verilog code and the yaml configuration file > and have a few questions. > > There is clearly a rate change in the block but nothing in the verilog > code modifies the CHDR context; specifically the timestamp, length, and > burst delimiters. Does the framework somehow automatically make these > modifications to the header? > > I would like to write host code that can use this block without knowing > the values of N and M a priori and also having the ability to dynamically > set their values via register writes. In general M won't be equal to the > payload size, P. For scenarios where M < P, is there a way to send the CHDR > packet before it fills to size P to reduce latency? If not or If M >= P, > would you recommend using context metadata to indicate the starting and > ending samples of a frame? > > Thank you for your time and consideration. > -Ed > > > > _______________________________________________ > 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]
