FIR IP reloading coefficients

[cleigeber]

I am having trouble loading coefficients into the FIR IP.  I assert the s_axis_reload_tvalid for 32 cycles in order to load 32 coefficients.  The problem is that the core responds with s_axis_reload_tready going low the very last coefficient along with event_s_reload_tlast_missing going high.  It is as if the core has already had a single coefficient loaded and so only expects 31 coefficients.  

Here is the chipscope capture.  The signals in orange drive the reload ports of the FIR IP.  Note the tready going to '0' and the tlast_missing to '1' on the very last coefficient to load.  

Anyone thoughts on how to resolve this issue?  Also note, that this does not occur in the testbench.  

Thank you!

[cleigeber]

Also using:  Vivado 2018.2, IP core version for the FIR Compiler is 7.2. 

[nathanx]

Did you look at the coefficient Reload Order File? see below. Fore more info, take a look at "Coefficient Reload" section on PG149. Hope it helps. 

Coefficient Reload
To minimize the resources required to implement the coefficient reload feature, it is necessary for users to re-order the coefficients that are to be reloaded to correctly pass each coefficient to its correct storage location in the filter structure. The Vivado IDE offers the facility to generate re-ordered coefficient files for use with the RELOAD channel and during core generation delivers an informational text file to the project area named <component_name>_reload_order.txt, which lists the indexes of the coefficients, Coefficient x, in the order they should be reloaded into the filter through the reload channel Reload index x.

[cleigeber]

Nathan,

I did see the _reload_order.txt file but my problem was that only 31 coefficients would be accepted regardless of the order.  It appears that the solution was to validate the initial/default configuration before trying to reload the coefficients.  I was thinking the default on power-up/reset would not require validation.  Doing this though, subsequently allowed me to load all 32 new coefficients without the tlast missing error.

Thanks!

[nathanx]

The RELOAD channel packet length is derived from the number of coefficients specified at core generation time and the filter implementation used. The user needs to look at the  _reload_order.txt to determine the reload channel packet length.

How many reload index do you see in the _reload_order.txt? Is it 32? NOTE the index starts from 0, so, in your case, it should end at 31. Is that true?

The provided screenshot is not clear to look at, but based on what you said, it's a bit wired. I suspect one coef was already loaded, which results in you only loading 31 rather than 32 coefs.

BTW, How do you validate the initial/default configuration? Is the reset included?

[cleigeber]

Yes, I know about the reload order and packet length.  There is no port on the reload interface to specify which coefficient is currently being written, which is the whole reason that the order even matters.  But, I could write the values any order I wish and while the FIR would not function properly, it would accept the reload.  But this does not happen as only 31 coefficients are accepted when a t_last_missing error is thrown.  What appears to have fixed this is that I now assert the s_axis_config_tvalid once the the s_axis_config_tready is asserted using a FSM as control.  The FSM then waits for a reload signal from a AXI-based register control to reload a new set of coefficients.  

Thank you, nathanx.