Hello all, I am having unexpected results when streaming from a custom source block to the DUC block and ultimately the radio. I am working on getting a DUC ILA debug image built, but I have spectrum analyzer screenshots to show. My test setup is samples sent at roughly 100MSPS to the DUC, which is configured for an input rate of 20 MSPS. My block design allows for the downstream block to deassert TREADY, and send more samples when it is reasserted, so I assumed the following: - The DUC block would deassert TREADY which would propagate to my block while it processes samples in its input - The DUC output would be continuous since there is always samples available - My waveform would stretch in time since all samples are sent, but at a lower rate My problem is that I am not seeing any DUC TREADY propagate to my block during the below behavior, which would stop sending if it needed to. So, I am unsure how to control this from my design. I have considered putting a FIFO that would set a fixed distance between samples, but* I would like to understand why the DUC isn't deasserting TREADY like I assumed.* Here is a screenshot of my blocks output in from an ILA debug core image. Only Q is shown since I is redundant: [image: image.png] The s_out_axis_tready, which should be coming from the DUC, is always asserted. My block sends 64 samples, then has a downtime which is shown by the TVALID being deasserted. Ignoring the downtime, this waveform would look like a typical LFM. The total waveform is sent at ~100MSPS, averaged over the valid portions and downtimes. The output of the radio is shown below, with IQ captured on a spectrum analyzer. I will focus only on the blue trace: [image: image.png] I have marked 3 unexpected regions in red circles. It appears that for a period of time, the DUC is not sending the samples shown in the ILA core. Also I see what I concluded to be missing samples, with a jump marked in green. I expected that even if the DUC is not sending my samples which causes downtime in the transmit, that it would pick up "where it left off" serially. Instead it skips an unknown number of samples. The IQ capture shown above repeats with the gaps as shown when I transmit. Any help with this would be great! Thanks, David

- The DUC block would deassert TREADY which would propagate to my
block while it processes samples in its input
- The DUC output would be continuous since there is always samples
available
- My waveform would stretch in time since all samples are sent, but at
a lower rate

On Tue, May 13, 2025 at 10:50 PM David <vitishlsfan21@gmail.com> wrote: > Hello all, > > I am having unexpected results when streaming from a custom source block > to the DUC block and ultimately the radio. I am working on getting a DUC > ILA debug image built, but I have spectrum analyzer screenshots to show. > > My test setup is samples sent at roughly 100MSPS to the DUC, which is > configured for an input rate of 20 MSPS. My block design allows for the > downstream block to deassert TREADY, and send more samples when it is > reasserted, so I assumed the following: > > - The DUC block would deassert TREADY which would propagate to my > block while it processes samples in its input > - The DUC output would be continuous since there is always samples > available > - My waveform would stretch in time since all samples are sent, but at > a lower rate > > My problem is that I am not seeing any DUC TREADY propagate to my block > during the below behavior, which would stop sending if it needed to. So, I > am unsure how to control this from my design. I have considered putting a > FIFO that would set a fixed distance between samples, but* I would like > to understand why the DUC isn't deasserting TREADY like I assumed.* > > Here is a screenshot of my blocks output in from an ILA debug core image. > Only Q is shown since I is redundant: > > [image: image.png] > > > The s_out_axis_tready, which should be coming from the DUC, is always > asserted. My block sends 64 samples, then has a downtime which is shown by > the TVALID being deasserted. Ignoring the downtime, this waveform would > look like a typical LFM. The total waveform is sent at ~100MSPS, averaged > over the valid portions and downtimes. > > The output of the radio is shown below, with IQ captured on a spectrum > analyzer. I will focus only on the blue trace: > > [image: image.png] > > I have marked 3 unexpected regions in red circles. It appears that for a > period of time, the DUC is not sending the samples shown in the ILA core. > Also I see what I concluded to be missing samples, with a jump marked in > green. I expected that even if the DUC is not sending my samples which > causes downtime in the transmit, that it would pick up "where it left off" > serially. Instead it skips an unknown number of samples. The IQ capture > shown above repeats with the gaps as shown when I transmit. > > Any help with this would be great! > Are you getting any asynchronous underrun reports on the host machine? The radio TX state machine is here for the transmit state: https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_radio/radio_tx_core.v#L348 When it detects an underrun, it will report the underrun asynchronously then wait until a tlast is seen, then try again. Do the samples align with where the next sample after a tlast might be? Brian

- The DUC block would deassert TREADY which would propagate to my
block while it processes samples in its input
- The DUC output would be continuous since there is always samples
available
- My waveform would stretch in time since all samples are sent, but
at a lower rate

Brian, Assuming that underrun in the radio_tx_core is a "U" underflow in stdout, I don't get warnings. I ran my application a couple times for 30 seconds without an underflow. *TLDR: I think the way I assert TLAST and EOB is causing my issue, but I don't understand why yet.* My graph is MyBlock -> EP, EP->DUC->Radio. I am using axis-data interface. Two things I noticed when debugging the DUC that are behaviors from my block: 1. the upstream EOB is always high. I assert EOB every 64 samples when I assert TLAST in my block. I dont't fully understand when to assert EOB, but I have considered asserting it at the end of my waveform? 2. the upstream TLAST seems to be asserted much earlier than I anticipated, at ~34 samples instead of 64. Here is a capture of an ILA core on the input and output of the DUC. The s_axis_data_tdata is upconverted to 30MHz: [image: image.png] A couple observations: - m_axis_data_tvalid is always asserted. I take this to mean that there is always data available at the input of the DUC, which I expect - The s_axis_data_tready (radio) is always asserted, which is expected - The m_axis_data_tready (DUC) deasserts, which I expected to see because of the lower sample rate on the input that I set. *I didn't expect that the TREADY pattern would be repetitive, and I thought it would settle at a constant spacing of accepting new samples* - *s_axis_data_tvalid (DUC) deasserts, but I don't know why yet.* My understanding from reading the radio state machine is that this would cause the radio to go back to IDLE and result in the output I am seeing the DUC TVALID deasserts when it raises TLAST, so I am assuming my problem is some combination of how I send TLAST and EOB from my block. I think that the DUC should always assert TVALID since there are always input samples. I captured the full waveform being transferred to the DUC, so I know that all the samples are making it and being read by TVALID and TREADY, at some point: [image: image.png] I also tried throttling the samples out of my block and statically connecting my block to the DUC, which was supposed to create equidistant samples at the input of the DUC at my indented sample rate (20MSPS). Results were the same. Thanks, David On Wed, May 14, 2025 at 6:49 AM Brian Padalino <bpadalino@gmail.com> wrote: > On Tue, May 13, 2025 at 10:50 PM David <vitishlsfan21@gmail.com> wrote: > >> Hello all, >> >> I am having unexpected results when streaming from a custom source block >> to the DUC block and ultimately the radio. I am working on getting a DUC >> ILA debug image built, but I have spectrum analyzer screenshots to show. >> >> My test setup is samples sent at roughly 100MSPS to the DUC, which is >> configured for an input rate of 20 MSPS. My block design allows for the >> downstream block to deassert TREADY, and send more samples when it is >> reasserted, so I assumed the following: >> >> - The DUC block would deassert TREADY which would propagate to my >> block while it processes samples in its input >> - The DUC output would be continuous since there is always samples >> available >> - My waveform would stretch in time since all samples are sent, but >> at a lower rate >> >> My problem is that I am not seeing any DUC TREADY propagate to my block >> during the below behavior, which would stop sending if it needed to. So, I >> am unsure how to control this from my design. I have considered putting a >> FIFO that would set a fixed distance between samples, but* I would like >> to understand why the DUC isn't deasserting TREADY like I assumed.* >> >> Here is a screenshot of my blocks output in from an ILA debug core image. >> Only Q is shown since I is redundant: >> >> [image: image.png] >> >> >> The s_out_axis_tready, which should be coming from the DUC, is always >> asserted. My block sends 64 samples, then has a downtime which is shown by >> the TVALID being deasserted. Ignoring the downtime, this waveform would >> look like a typical LFM. The total waveform is sent at ~100MSPS, averaged >> over the valid portions and downtimes. >> >> The output of the radio is shown below, with IQ captured on a spectrum >> analyzer. I will focus only on the blue trace: >> >> [image: image.png] >> >> I have marked 3 unexpected regions in red circles. It appears that for a >> period of time, the DUC is not sending the samples shown in the ILA core. >> Also I see what I concluded to be missing samples, with a jump marked in >> green. I expected that even if the DUC is not sending my samples which >> causes downtime in the transmit, that it would pick up "where it left off" >> serially. Instead it skips an unknown number of samples. The IQ capture >> shown above repeats with the gaps as shown when I transmit. >> >> Any help with this would be great! >> > > Are you getting any asynchronous underrun reports on the host machine? > > The radio TX state machine is here for the transmit state: > > > https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_radio/radio_tx_core.v#L348 > > When it detects an underrun, it will report the underrun asynchronously > then wait until a tlast is seen, then try again. > > Do the samples align with where the next sample after a tlast might be? > > Brian >

1. the upstream EOB is always high. I assert EOB every 64 samples when
I assert TLAST in my block. I dont't fully understand when to assert EOB,
but I have considered asserting it at the end of my waveform?
2. the upstream TLAST seems to be asserted much earlier than I
anticipated, at ~34 samples instead of 64.

- m_axis_data_tvalid is always asserted. I take this to mean that
there is always data available at the input of the DUC, which I expect
- The s_axis_data_tready (radio) is always asserted, which is expected
- The m_axis_data_tready (DUC) deasserts, which I expected to see
because of the lower sample rate on the input that I set. *I didn't
expect that the TREADY pattern would be repetitive, and I thought it would
settle at a constant spacing of accepting new samples*
- *s_axis_data_tvalid (DUC) deasserts, but I don't know why yet.* My
understanding from reading the radio state machine is that this would cause
the radio to go back to IDLE and result in the output I am seeing

- The DUC block would deassert TREADY which would propagate to my
block while it processes samples in its input
- The DUC output would be continuous since there is always samples
available
- My waveform would stretch in time since all samples are sent, but
at a lower rate

Brian, Issue is resolved, it was how I was asserting EOB from my block, and the corresponding effect in the axi_rate_change state machine in the DUC. Everything looks good now and it is beginning to make sense. Thanks for the help! David On Wed, May 14, 2025 at 8:10 PM David <vitishlsfan21@gmail.com> wrote: > Brian, > > Assuming that underrun in the radio_tx_core is a "U" underflow in stdout, > I don't get warnings. I ran my application a couple times for 30 seconds > without an underflow. > > *TLDR: I think the way I assert TLAST and EOB is causing my issue, but I > don't understand why yet.* > > My graph is MyBlock -> EP, EP->DUC->Radio. I am using axis-data interface. > Two things I noticed when debugging the DUC that are behaviors from my > block: > > 1. the upstream EOB is always high. I assert EOB every 64 samples when > I assert TLAST in my block. I dont't fully understand when to assert EOB, > but I have considered asserting it at the end of my waveform? > 2. the upstream TLAST seems to be asserted much earlier than I > anticipated, at ~34 samples instead of 64. > > Here is a capture of an ILA core on the input and output of the DUC. The > s_axis_data_tdata is upconverted to 30MHz: > > [image: image.png] > > A couple observations: > > - m_axis_data_tvalid is always asserted. I take this to mean that > there is always data available at the input of the DUC, which I expect > - The s_axis_data_tready (radio) is always asserted, which is expected > - The m_axis_data_tready (DUC) deasserts, which I expected to see > because of the lower sample rate on the input that I set. *I didn't > expect that the TREADY pattern would be repetitive, and I thought it would > settle at a constant spacing of accepting new samples* > - *s_axis_data_tvalid (DUC) deasserts, but I don't know why yet.* My > understanding from reading the radio state machine is that this would cause > the radio to go back to IDLE and result in the output I am seeing > > the DUC TVALID deasserts when it raises TLAST, so I am assuming my problem > is some combination of how I send TLAST and EOB from my block. I think that > the DUC should always assert TVALID since there are always input samples. > > I captured the full waveform being transferred to the DUC, so I know that > all the samples are making it and being read by TVALID and TREADY, at some > point: > > [image: image.png] > > I also tried throttling the samples out of my block and statically > connecting my block to the DUC, which was supposed to create equidistant > samples at the input of the DUC at my indented sample rate (20MSPS). > Results were the same. > > Thanks, > > David > > > On Wed, May 14, 2025 at 6:49 AM Brian Padalino <bpadalino@gmail.com> > wrote: > >> On Tue, May 13, 2025 at 10:50 PM David <vitishlsfan21@gmail.com> wrote: >> >>> Hello all, >>> >>> I am having unexpected results when streaming from a custom source block >>> to the DUC block and ultimately the radio. I am working on getting a DUC >>> ILA debug image built, but I have spectrum analyzer screenshots to show. >>> >>> My test setup is samples sent at roughly 100MSPS to the DUC, which is >>> configured for an input rate of 20 MSPS. My block design allows for the >>> downstream block to deassert TREADY, and send more samples when it is >>> reasserted, so I assumed the following: >>> >>> - The DUC block would deassert TREADY which would propagate to my >>> block while it processes samples in its input >>> - The DUC output would be continuous since there is always samples >>> available >>> - My waveform would stretch in time since all samples are sent, but >>> at a lower rate >>> >>> My problem is that I am not seeing any DUC TREADY propagate to my block >>> during the below behavior, which would stop sending if it needed to. So, I >>> am unsure how to control this from my design. I have considered putting a >>> FIFO that would set a fixed distance between samples, but* I would like >>> to understand why the DUC isn't deasserting TREADY like I assumed.* >>> >>> Here is a screenshot of my blocks output in from an ILA debug core >>> image. Only Q is shown since I is redundant: >>> >>> [image: image.png] >>> >>> >>> The s_out_axis_tready, which should be coming from the DUC, is always >>> asserted. My block sends 64 samples, then has a downtime which is shown by >>> the TVALID being deasserted. Ignoring the downtime, this waveform would >>> look like a typical LFM. The total waveform is sent at ~100MSPS, averaged >>> over the valid portions and downtimes. >>> >>> The output of the radio is shown below, with IQ captured on a spectrum >>> analyzer. I will focus only on the blue trace: >>> >>> [image: image.png] >>> >>> I have marked 3 unexpected regions in red circles. It appears that for a >>> period of time, the DUC is not sending the samples shown in the ILA core. >>> Also I see what I concluded to be missing samples, with a jump marked in >>> green. I expected that even if the DUC is not sending my samples which >>> causes downtime in the transmit, that it would pick up "where it left off" >>> serially. Instead it skips an unknown number of samples. The IQ capture >>> shown above repeats with the gaps as shown when I transmit. >>> >>> Any help with this would be great! >>> >> >> Are you getting any asynchronous underrun reports on the host machine? >> >> The radio TX state machine is here for the transmit state: >> >> >> https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/blocks/rfnoc_block_radio/radio_tx_core.v#L348 >> >> When it detects an underrun, it will report the underrun asynchronously >> then wait until a tlast is seen, then try again. >> >> Do the samples align with where the next sample after a tlast might be? >> >> Brian >> >

On Thu, May 15, 2025 at 12:14 PM David <vitishlsfan21@gmail.com> wrote: > Brian, > > Issue is resolved, it was how I was asserting EOB from my block, and the > corresponding effect in the axi_rate_change state machine in the DUC. > Everything looks good now and it is beginning to make sense. > Glad you were able to resolve things relatively quickly. You did a great job explaining the problem and posting relevant information. > > Thanks for the help! > No problem! Brian >