02-17-2016 01:40 PM
In simulation the slave side TR signal generally appears high most of the time... generally. There are long stretches of time while the slave TV signal is indicating new data that the slave TR signal stays high. This is with the simulation test bench created with the core. I modified the clocks in the test bench to somewhat match my real world senario and still the TR signal generally stays valid most of the time.
In my actual hardware I see TR generally low most of the time time and only active for perhaps one or two TV signals then goes inactive again. I know we have to live with the interface but why such disparity between simulation and hardware?
Currently I'm ignoring the TR signal and just continuously stuffing new data to the interface even though TR is low. I now the transaction isn't accepted because TR is low when I raise TV. Is there a section in the FIR filter docs that give some guideline of how deep the fifo is on the input side of the AXI bus. I'm assuming I'll need to buffer up the input side and throttle the data to the FIR filter using TR as the back pressure flag but I'm trying to figure out how many clock cycles this could be. In my case I am clocking the FIR with 300Mhz and the input data rate is 48khz and it's set up as a decimation by 2 filter.
02-18-2016 06:02 AM
changing the hardware oversampling seemed to resolve this issue, specifically the input sampling frequency. The data input is 48Khz data, when I set the input sampling to 0.048 in the tool then the slave tready was mostly low. I changed this to 0.001 and now the tready is high most of the time and it appears like correct data is output from the filter. I've read through page 78 of PG149 but don't fully comprehend the ramification here.
02-18-2016 12:09 PM
Reverting this design to a single channel but using two FIR filters seems to work. I'm a little puzzled why. It would seem that I shouldn't be overflowing the FIFO so quickly with a two channel filter with input data at 48Khz and a filter clock running at over 200Mhz. When I implement this as a single core using two channels the s_tready bit is never asserted for more than two samples, most of the time for only one short sample time, once the s_tvalid is issued the s_tready goes inactive very soon after the transaction. However, running the same data into two FIR filters but configured as single channel then s_tready is always asserted (let it run in hardware for 10 minutes and t_ready never went low on either filter). Anyone have thoughts on this?