Hi Martin,
Sorry I called you Marcus earlier, I was probably thinking of Marcus of
GNURadio. Two things:
1. Is it safe to assume that packets on the data plane are not buffered.
Like if there are 64 samples in the packet, that those 64 samples are the
most current 64 samples. For instance, if the DDC is operated at 1 MSps,
those 64 samples are from the last 64us approximately? I understand the
samples are buffered in a FIFO, but the packets go out when they're filled
and aren't buffered any further? If so, then I can probably fix the missed
latency as you said.
2. Another way I thought to handle this would be to put my RFNOC block in
front of the Radio block and assign the GPIO pins to the input
radio_rx_data in rfnoc_block_radio.v. Besides the challenges of getting
this right in the image core YAML and the autogeneration of the rfnoc image
core verilog file, there is the issue of the DDC being downstream. Is
there any way to get the DDC to function as pure decimation, like a "keep 1
of N" function? I thought I could set the center frequency to 0 Hz, but
there may be some anti-aliasing filter that would still get in the way.
Thanks,
Mark
On Fri, Nov 8, 2024 at 1:37 AM Martin Braun <martin.br...@ettus.com> wrote:
> Hey Mark,
>
> that all makes sense, but keep in mind that the DDC comes later in the
> data path than the radio samples, which means the timestamps are "in the
> past" with respect to the actual GPIO events. In theory, we don't even
> guarantee deterministic latency (they could vary by how much in the past
> they are), but in practice, that's not true given you're in the same,
> statically connected data path. That said... if you're putting the GPIO
> values into a FIFO then you can maybe fix the missed latency.
>
> Best of luck,
>
> --M
>
> On Fri, Nov 8, 2024 at 9:29 AM Mark Gannet <mgan...@gmail.com> wrote:
>
>> Hi Marcus,
>>
>> Thank you. You've been very helpful and confirmed my thoughts.
>>
>> Yes it will be important to run the sampling of the GPIO pin at the same
>> rate produced by the DDC. I didn't fully appreciate that the data was
>> packetized which makes this more difficult than I'd thought.
>>
>> Re: your thoughts
>> - if you have a way to violate sampling theorem and faithfully reproduce
>> signals, you won't have to answer any more emails :)
>> - I'm keeping my block in the data path for 2 reasons: 1) I want it to
>> produce data that matches the timestamp and total bytes of the other
>> channel for the collection period and 2) I want to use the control plane to
>> allow the user to select the standard data flow from the DDC if desired
>> without requiring a different fpga image.
>> - Initially I'll probably hardcode the divide of the radio clock. The end
>> goal will be to use the control plane to pass the decimation factor to a
>> counter so that the divide can adjust depending on the sampling rate.
>>
>> Mark
>>
>>
>>
>>
>> On Thu, Nov 7, 2024, 5:06 AM Martin Braun <martin.br...@ettus.com> wrote:
>>
>>> Hey Mark,
>>>
>>> OK, I get it, you're basically sampling a GPIO pin instead of using the
>>> analog data. And of course, you have to stick to the sampling theorem if
>>> you want to do that, and you're seeing what happens if you violate it.
>>>
>>> I'm guessing it's important that you run at a clock that's related to
>>> your radio/data clock, so you can match the GPIO pin levels in time to the
>>> samples you're receiving on the other channel, right?
>>>
>>> Some thoughts:
>>>
>>> - I have no solution for violating the sampling theorem and not getting
>>> punished :)
>>> - In RFNoC, you don't really need to put your RFNoC block in the data
>>> path. You could have a separate source block that just forwards the
>>> GPIO-data.
>>> - And yes, you want that GPIO-sampling to occur with a sensible clock of
>>> your own. You could use radio_clk, or divide that.
>>>
>>> Not sure if this is helpful.
>>>
>>> --M
>>>
>>> On Wed, Nov 6, 2024 at 7:45 PM Mark Gannet <mgan...@gmail.com> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Sorry I should've elaborated on my purpose.
>>>>
>>>> I'm using a device to connect external TTL signals to the RxBasic
>>>> daughterboard GPIO pins on chA of the x310. I'm stealing an analog channel
>>>> on the x310 to capture timing on one channel with the analog input on the
>>>> 2nd channel. This data is recorded on the host PC from the 10 GbE
>>>> interface. I've made an application based on the rx_samples_to_file
>>>> utility that sets the daughterboard RX GPIO banks appropriately and I can
>>>> see the GPIO inputs in the Ethernet capture from my utility in the recorded
>>>> binary files (chA and chB).
>>>>
>>>> Assuming a 1 MSps sample rate from the DDC and 64 samples/packet, the
>>>> rate on the axis rfnoc bus is 15.625 kHz (64 us period). The problems
>>>> arise when the rate on the GPIO pin roughly exceeds half the packet rate on
>>>> the axis data plane. Basically it gets aliased. Here are the lines from
>>>> the HDL file in my block that sits between the DDC and the SEP. I created
>>>> a testbench as well and placed a clock on a GPIO input to see what is
>>>> happening. Also created/loaded an image to x310 and observed in the
>>>> Ethernet output, which confirmed what I see in the testbench.
>>>>
>>>> assign s_out_axis_tdata = { 16'b0, radio_rx_gpio[15:0] };
>>>> assign s_out_axis_tlast = m_in_axis_tlast;
>>>> assign s_out_axis_tvalid = m_in_axis_tvalid;
>>>> assign s_out_axis_tlength = m_in_axis_tlength;
>>>> assign s_out_axis_ttimestamp = m_in_axis_ttimestamp;
>>>> assign s_out_axis_thas_time = m_in_axis_thas_time;
>>>> assign s_out_axis_tlength = m_in_axis_tlength;
>>>> assign s_out_axis_teov = m_in_axis_teov;
>>>> assign s_out_axis_teob = m_in_axis_teob;
>>>> assign m_in_axis_tready = s_out_axis_tready;
>>>>
>>>> assign s_out_axis_tkeep = {NUM_PORTS{1'b1}};
>>>>
>>>> Here are the lines from the image core yaml that show how the block is
>>>> connected.
>>>>
>>>> # # radio0(0) to ep0 - RFA RX
>>>> - { srcblk: radio0, srcport: out_0, dstblk: ddc0, dstport: in_0 }
>>>> - { srcblk: ddc0, srcport: out_0, dstblk: rx_analog_dio_sw0, dstport:
>>>> in_0 }
>>>> - { srcblk: rx_analog_dio_sw0, srcport: out_0, dstblk: ep0, dstport:
>>>> in0 }
>>>>
>>>> As a side note, this worked in UHD 3.9. But that seemed entirely
>>>> different. The DDC was a submodule of the Radio block. The output of the
>>>> DDC was not packetized on the axis protocol at that point. So it was
>>>> straightforward to assign the GPIO pins and then the packetization took
>>>> place later. In UHD 4.x, the data from the DDC is packetized onto the axis
>>>> data plane already.
>>>>
>>>> My thought right now is that I need to clock the GPIO pins into a
>>>> generic FIFO at the DDC rate with my own clock, connect that to the NOC
>>>> shell and let the NOC shell unload the FIFO when the axis data plane is
>>>> ready. Does this seem like a path forward? I'm glossing over a ton of the
>>>> intricacies and making it sound trivial. Feel free to destroy my plan.
>>>>
>>>> Hopefully this makes my intent a little clearer.
>>>>
>>>> Thanks you,
>>>> Mark
>>>>
>>>>
>>>> On Wed, Nov 6, 2024 at 1:07 AM Martin Braun <martin.br...@ettus.com>
>>>> wrote:
>>>>
>>>>> Hey Mark,
>>>>>
>>>>> maybe I'm being dense, but I don't understand what it is that your
>>>>> GPIO pins are supposed to be doing when your system is done. Can you
>>>>> elaborate?
>>>>>
>>>>> --M
>>>>>
>>>>> On Wed, Nov 6, 2024 at 1:56 AM <mgan...@gmail.com> wrote:
>>>>>
>>>>>> Hi everybody!
>>>>>>
>>>>>> I’ve written an RFNOC block that assigns the daughterboard rx GPIO
>>>>>> pins to the tdata signals that are sent to the SEP. I’m using the
>>>>>> axis_data
>>>>>> protocol and the block is placed statically between the DDC and the SEP.
>>>>>> I
>>>>>> use the tvalid and tlast signal from the upstream (DDC) block and the
>>>>>> tready signal from the downstream (SEP) block. I brought the GPIO into
>>>>>> the
>>>>>> block using appropriate YAML files. Small modification outside of RFNOC
>>>>>> were required to get the pins to RFNOC (bus_int.v, x300_core.v,
>>>>>> io_signatures.yml, and x310_bsp.yml).
>>>>>>
>>>>>> The x310 is operated at 1 Msps and there are 64 samples per CHDR
>>>>>> packet on the axis data bus. This means that the packet rate on the bus
>>>>>> is
>>>>>> 1 Msps / 64, or 15.625 kHz. Period is 64 us.
>>>>>>
>>>>>> If I place a signal onto the GPIO pin, everything is fine as long as
>>>>>> the pulse width is greater than 64 us. I can run the radio with
>>>>>> rx_samples_to_file and see the GPIO pins faithfully reproduced in the
>>>>>> Ethernet output collected on a PC.
>>>>>>
>>>>>> At pulse widths less than 64 us, the signal is essentially aliased. I
>>>>>> believe it’s because I’m using the tvalid, tlast, and tready signals from
>>>>>> upstream/downstream blocks with data that’s already on the axis data
>>>>>> plane.
>>>>>> That data bursts through with 64 samples roughly every 64 us and is
>>>>>> clocked
>>>>>> with a 200 MHz master clock. I need to clock in the asynchronous GPIO.
>>>>>>
>>>>>> My question: What is the best way to do this? Generate my own clock
>>>>>> and use a generic FIFO like axi_fifo.v to hold the data until the
>>>>>> upstream
>>>>>> block sends its data and the downstream block is ready to receive?
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Mark
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
