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
