That was my initial understanding of the use of clk_domain field in the block YAML.
I was thrown off by the FAQ for some reason, and I got to thinking the data rate from the noc shell may be locked. Thank you for taking the time to clear that up for me. -Rylee From: Wade Fife <wade.f...@ettus.com> Date: Friday, July 1, 2022 at 7:56 PM To: Mattingly, Rylee <rmattin...@ou.edu> Cc: USRP-users@lists.ettus.com <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] rfnoc_chdr Clock on X3xx Radios When you create an RFNoC block, the noc_shell gets created for you and you can specify what clock you want the data on and the NIPC. In the case of the DDC, the data to/from the noc_shell should be on ce_clk. The noc_shell handles for you the conversion between ce_clk and rfnoc_chdr_clk, and between the requested NIPC and the CHDR bus width. The streamer does not know the NIPC but your block can be designed to handle an odd number of samples per packet. TKEEP is the signal that indicates if the last clock cycle has an odd number of samples. It also may be possible to write your application so that the block only sends/receives a multiple of the NIPC, which can allow you to simplify the FPGA logic in some cases. But I would avoid that if you can. Wade On Fri, Jul 1, 2022, 9:48 AM Mattingly, Rylee <rmattin...@ou.edu<mailto:rmattin...@ou.edu>> wrote: Hi Wade, This makes sense to me intuitively, especially with the processing clock. I am mostly concerned about the ability of the data bus to actually pipe that much data, which would be alleviated by a NIPC = 2. In the DDC, the data seems to come in from the NOC shell using the rfnoc_chdr_clk, but uses local parameters to define item_w = 32 and NIPC = 1. Being localparams, it is my understanding that they can’t be modified externally. Although the raw input signal s_rfnoc_chdr_tdata is 64 bits, the s_axis_data_tdata is only defined with num_ports*item_w. So does the DDC use the num_ports parameter in place of NIPC? Similarly the FFT block uses local parameters for NIPC but explicitly uses the CHDR_W to set the axis_tdata width. Again it doesn’t seem to use NIPC but perhaps that is just implied. So I guess my question boils down to: Should custom RFNoC blocks that expect to operate at 200 MS/s expect a NIPC of 2 from the upstream blocks. Does the streamers understand if it is expecting 2 samples per clock or 1 sample per clock? Rylee From: Wade Fife <wade.f...@ettus.com<mailto:wade.f...@ettus.com>> Date: Friday, July 1, 2022 at 9:19 AM To: Mattingly, Rylee <rmattin...@ou.edu<mailto:rmattin...@ou.edu>> Cc: USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] rfnoc_chdr Clock on X3xx Radios Hi Rylee, Some blocks do use NIPC = 1, but those blocks need to use a faster clock for the internal processing. For example, on X310, the DDC and DUC use a separate CE clock that is connected to 214.286 MHz. The radio block uses radio_clk for this purpose. For the parts of the logic that use the 187.5 MHz clock, we use a 64-bit bus that holds 2 samples per cycle (NIPC = 2). The numbers vary somewhat between products and blocks, but that's the general idea. Wade On Fri, Jul 1, 2022 at 8:55 AM Mattingly, Rylee <rmattin...@ou.edu<mailto:rmattin...@ou.edu>> wrote: Hello all, I am looking at the RFNoC FAQ page<https://urldefense.com/v3/__https:/kb.ettus.com/RFNoC_Frequently_Asked_Questions__;!!GNU8KkXDZlD12Q!9vhvYI4lgCniKu9k5boH12kRtHf4dVelsbI2c47vAy3m0Nn4CwRMG8YOcTzk46v8Y2IThfEbqgsGjITcig$> and it lists the rfnoc_chdr clock as 187.5 MHz. Now this is plenty fast to pipe around packets and sequential headers for the 184.32 MS/s sample rate but how does this support the 200 MHz master clock/200MS/s sample rate? This seems like a NIPC > 1 would be needed, but my understanding is that all blocks use NIPC = 1 by default. Thank you, Rylee Mattingly The University of Oklahoma Graduate Research Assistant _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto: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
