I have designed a FIR Fractional Rate Converter Filter by using FIR Compiler. The purpose of the design convert 20MHz(20M samples) to 20.48MHz(20.48M samples) and to reach valid data continuity in the output. However, there is problem with the input. The IP expects valid data in each 1 clock cycle and gives valid output data in every clock cycle. I use an Asynchronous Fifo to change 20MHz to 20.48MHz in the output. In some cases the Fifo can't supply valid data to the input as expected and s_axis_tready is always high. So, this situtation breaks valid data continuity at the output port. How can I solve this problem ?
Filter Options and Channel Spesifications
Filter Type --> Interpolation
Rate Change Type --> Fixed Fractional
Interpolation Rate Value --> 128
Decimation Rate Value --> 125
Input Sampling Frequency --> 20MHz
Clock Frequency --> 20.48MHz
Clock Cycles Per Input --> 1 !!(How can I supply with 20 MHz ? The main clock is 20.48Mhz, and s_axis_tready is always high.)
Clock Cycles Per Output --> 1
Try let the filter control its input read from fifo. I assume it has that sort of ready signal.
I am having a problem in understanding the decimation ratio of 128:125 and "link" it to your frequencies: Where is the asynchronous point about that?
Typically this conversion is done via a CIC using 4:4:4 twice and a 5:5:5 which is fully snychronous to the input clock. Doing this the data is fully continous and only has to be transferred into the new domain using e.g. some registers to separate clock edges.
Regarding AXI there might by such a clock edge mismatch so it should be made sure that the master does not start to provide data directly at power up when first the slave says "ready" but sample the ready once or twice and use this signal as a global enable for this master. This makes sure there is always data in the input buffer of the slave.
If there is an issue, add a FIFO in between.
This has nothing to do with clock transfer. It is about sample rate conversion. A polyphase structure can do that on one system clock. You don't necessarily need fifo.
You seem on a spree of posting all around dsp/fpga/blogs, all in one day including ancient threads. Sorry but I see this as noise added to already noisy forums.
I do not think there is an issue with the conversion itself. I only mentioned this as a side aspect.
As stated the unexpected gaps are the issue.
The question is, were does this reading clock comes from an when does it make the slave expecting data. Typically in an asynchronous system the bandwidth of the master has to be higher in order to compensate gaps which occour when not using time slots and tuhs ensure that there is always data to be driven into the slave.
In that special case, when both clock frequencies are precisely the same, there should not be an issue, except from low level timing issues when the handshaking is performed with combinatorical logic at the master's or the slave's side. So a FIFO (possibly a register in the master or the slave ) will solve this issue or a dedicated AXI-fifo in between the two components is required to manage that.
The AXI-Fifo automatically decouples the access introducing one or two CCs delay, which should not be an issue. Alternatively the master in this case will have to handle it with an e.g. double buffer which is alternativelay written.
I recently had exactly this issue with a AXI-driven HBM-memory operating on the same frequency as the master. Building it the way with combi - handshake was not possible due to timing issues at 450MHz.
Well since the TO already seems to have FIFO, there can only be a filling issue since the bandwidth is clean. Therefore I recommended to start the FIFO readout first when at least 1 + 1 data is present and not to apply a tight timing by using eg "not empty".