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
