Hi Felipe, 1) As with any custom RFNoC block, yes it would connect to the crossbar.
2) Yes, your understanding is correct. 3) You would have to define what "high latency" is. The block would certainly add latency to the path. I would expect it to be on the order of 1 packet due to packet gating. Anything you add to split the stream to duplicate the RX data to your custom logic and the host will add the same amount of latency. Splitting the stream within your custom block will use fewer resources than adding a separate block (such as a Split Stream block). 4) The DMA FIFO doesn't need control. The noc_shell and crossbar handle the control. Use it as a simple FIFO. Mostly, the DMA FIFO is used to buffer up TX data to absorb host system "jitter" (random amount of time between data packets from host to device). Regards, Michael On Sat, Oct 14, 2017 at 9:11 AM, Felipe Augusto Pereira de Figueiredo < zz4...@gmail.com> wrote: > Sorry, I've just noticed my last email did not include the USRP mailing > list. > > On Sat, Oct 14, 2017 at 12:30 PM, Felipe Augusto Pereira de Figueiredo < > zz4...@gmail.com> wrote: > >> Dear Michael, >> >> Thanks for your answers! >> >> However, I still have some questions. >> >> 1) Will this new block be connected to the crossbar as the other NoC >> modules? I'm asking it because you mention the block should have 2 input >> ports and 2 output ports, so I'm supposing they are all connected to the >> crossbar and will communicate through DMA. >> >> 2) As I understood, this new block would be placed between DDC and Host >> PC, and also, between DMA FIFO and the DUC block. I mean, the flow would >> be, DDC -> New Block -> Host PC and DMA FIFO -> New Block -> DUC, is my >> understanding correct? >> >> 3) Would the new data flow: DDC -> New Block -> Host PC add very high >> latency to the communication between USRP and Host PC, or it would not >> impact too much? Wouldn't it be better for new block to receive data from >> the DDC without being in the middle between DDC and Host PC? >> >> 4) Is there some trick to control the DMA FIFO reading or is it simple as >> done by other blocks connected to the crossbar? I've never worked with >> those kinds of FIFO... >> >> Thanks again and Kind Regards, >> >> Felipe Augusto >> >> On Fri, Oct 13, 2017 at 9:48 PM, Michael West <michael.w...@ettus.com> >> wrote: >> >>> Hi Felipe, >>> >>> That is absolutely possible to do in RFNoC and not very hard. You >>> simply create a block that has 2 input ports and 2 output ports with one >>> input from the DDC, one input from the DMA FIFO, one output for the RX data >>> back to the host, and one output for data to the DUC. All of your power >>> calculation and control logic sits in the block. User registers can be >>> instantiated to control the threshold and any other dynamic parameters you >>> need. >>> >>> Regards, >>> Michael >>> >>> On Tue, Oct 3, 2017 at 1:42 AM, Felipe Augusto Pereira de Figueiredo via >>> USRP-users <usrp-users@lists.ettus.com> wrote: >>> >>>> Dear All, >>>> >>>> I'm thinking of implementing LBT with RFNoC, however, after an initial >>>> study of the RFNoC framework I realized it would be hard to implement >>>> what I had in mind: >>>> >>>> Initially, I would start with a very basic approach: >>>> 1) Calculate the power received just after the DDC for every received >>>> packet >>>> 2) If the power is greater than a defined threshold I would disable >>>> the DUC from reading new IQ samples from the dmaFIFO. Disabling DUC >>>> would require a new output signal (DDC) and input signal (DUC). >>>> >>>> However, I think the approach with input/output signals would not be >>>> the best one but I don't really have better ideas as I'm quite new to >>>> RFNoC. >>>> >>>> Now comes the reason why I'm writing this email, I'd like to know if >>>> there is a better approach for this LBT implementation with RFNoC. >>>> >>>> Any hint will be very helpful! >>>> >>>> Thanks and Kind Regards, >>>> >>>> Felipe Augusto >>>> >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>> >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
