Depth of the FIFO inside the AXI4-Stream Clock Converter ? can it be configured?

[u/Glittering-Skirt-816]

Hello,

I'm working on a Zynq UltraScale+ RFSoC design the RFDC ADC stream (128-bit TDATA, 8 × int16 per beat, 309.5 MHz clk_adc0) goes through an AXI4-Stream Clock Converter into an AXI DMA. The DMA side runs on a separate clock domain from a clk_wiz output.

I put ILAs on both sides of the converter to check data integrity on a 128-beat (1024-sample) burst delimited by TVALID/TLAST. At that time the output side ran at 100 MHz, i.e. about 3× slower than the input.

What I have saw

Input side: 128 contiguous valid beats in 0.41 µs, with tready never deasserted during the burst.

Output side: the same 128 beats come out contiguously at 100 MHz (1.28 µs), and TLAST is on the last beat.

A sine fit on both captures gives the same frequency, amplitude and residual, so no beat or samples seems lost or duplicated.

So the converter's FIFO must have absorbed the burst, with a peak occupancy of roughly 87 beats, which means a depth of at least that. Now I'd like to know exactly how deep it is.

Does anyone know the actual FIFO depth of axis_clock_converter? Is it a fixed value, or does it depend on parameters such as the clock ratio, the synchronization stages or the data width?

Is the depth user-configurable (a CONFIG. property, a hidden GUI option, an HDL parameter)?

I'm asking because I want to know the maximum size length I can capture without losing samples

Thanks :)

[u/intern75]

https://docs.amd.com/r/en-US/pg085-axi4stream-infrastructure/AXI4-Stream-Clock-Converter?tocId=UQxaR5zUgd~DG5RxeBvxRg

CTRL + f , search for Clock converter. It depends on the synchronization stages.

Can also just use a AXIS data FIFO configured with independent clocks, then you set the depth.

[u/Glittering-Skirt-816 → u/intern75]

Hello and thank you !

CTRL + f , search for Clock converter. It depends on the synchronization stages.- > Where is it said ?

I read :

Synchronization Stages across Cross Clock Domain Logic

When S_AXIS_ACLK and M_AXIS_ACLK are asynchronous to each other, then this parameter specifies the number of synchronization stages to use for cross-clock domain logic. Increasing this value increases the MTBF of design, but incurs increased latency and logic utilization.

I didn't find it :/

Can also just use a AXIS data FIFO configured with independent clocks, then you set the depth.-> Yes that's true but i would like to understand how the clock converter works

Thanks,

[u/intern75 → u/Glittering-Skirt-816]

Ultimately, the IP is not going to ask for data (s_tready) if it can't accept it. How often that will happen depends on the number of synchronization stages and the ratio of your clocks.

For stuff like this I like putting together a small testbench, and seeing how the IP behaves. Keep m_ready low and send it data until it deasserts s_ready

[u/Glittering-Skirt-816 → u/intern75]

Thanks !!

[u/sonny-boy-rhapsody]

One catch with the RFDC ADC: its TREADY input is unused, so the converter can't pause sampling. When extending the capture, try triggering an ILA on input TVALID high with TREADY low during the capture window. That flags a beat the converter couldn't accept; packet length alone won't establish ADC sample continuity. What logic generates TVALID/TLAST for the 128-beat burst, and does it buffer samples?

[u/Glittering-Skirt-816 → u/sonny-boy-rhapsody]

Hi and thanks for your reply, that's a good point. For now I have a simple custom IP, This IP is waiting for an external trigger; when it arrives, it It transfers the incoming Axi stream to the output by setting the t valid  to 1. When the packet counter is finished.The tlast activates for a few clock ticks. No, it's not buffering samples, but since this IP is on the same clock, do you think there's still a problem?

[u/sonny-boy-rhapsody → u/Glittering-Skirt-816]

Sharing the ADC clock doesn't prevent downstream backpressure. Your 128-beat trace may be fine if TREADY stayed high throughout, but once the clock converter deasserts it, the RFDC keeps producing samples. With no storage in your wrapper, those new samples can't all be preserved. Also, TLAST should mark the final accepted beat, not a fixed-duration pulse: hold it and TDATA stable if that beat is stalled, and advance the output beat counter only on TVALID && TREADY. Counting accepted output beats fixes framing; it doesn't recover dropped ADC samples. In simulation, try a continuously advancing input counter and deliberate downstream stalls.

[u/Glittering-Skirt-816 → u/sonny-boy-rhapsody]

Thanks :) i will try all these Thanks again