03-31-2020 07:10 AM
I am using System Generator to design a 32 tap decimating filter, super sample rate is 2. The problem I am seeing is with the coefficient reload port.
First, the case that works. I configure the FIR as 32 taps and decimation is 2. I load 32 coefficients through the Reload Data port accompanied by the Reload Valid asserted to 1. On the last coefficient (number 32) I assert the Reload Last signal. The FIR responds as expected by clearing Reload Ready. I assert the Config Valid input for one cycle. Reload Ready remains low, until the first input data value arrives indicated by Data Valid. Reload Ready asserts completing the cycle.
Now the case that does not work. I configure the FIR as 32 taps as in the first case, but the decimation is 5. I load 32 coefficients through the Reload Data port accompanied by the Reload Valid asserted to 1. On the last coefficient (number 32) I assert the Reload Last signal. In this case the FIR does not respond as expected by clearing Reload Ready. Instead, Reload Ready remains asserted.
Repeating the above case, I configure the FIR as 32 taps as in the first case, decimation is 5, but in this experiment, I load the 35 coefficients (first multiple of 5 after 32) In this case, the Reload Ready responds as expected. I have attached a snapshot of the three cases.
Why does the decimate by 5 only respond when the extra 3 coefficients are sent.
Thank you for any help you can provide.
04-01-2020 01:15 PM
Some additional information:
I think I have figured out the problem, at least in part. I suspected there must be something going on with the generated core that was not obvious. So I regenerated the FIR in VIVADO using the FIR compiler. VIVADO FIR Compiler generated my 32 tap FIR with 35 taps (which is what I was seeing on the reload).
I am not sure how to get the same information out of the System Generator output files. I found the utility xlGetReOrderedCoeff but it does not seem to provide the data I need.
I would like a response to my original post specifically in regard as to how to get the implementation structure and reload order out of System Generator without having to generate all the cores in VIVADO.
Thank you for any help you can give.
04-01-2020 10:28 PM
Hi @curtisra ,
The sysgen FIR compiler block behavior is as expected because the FIR compiler IP which is used underneath this block expects 35 coefficients when decimation is set to 5. The additional 3 coefficients are added to original coefficients as well and it is indicated as "calculated coefficients" in "coefficient tab" in Vivado's FIR compiler IP GUI.
The FIR compiler IP's GUI also has a dedicated tab that displays the reload coefficient order as well as the data type required for this interface. Such display tabs is not present in the corresponding sysgen block, because it the GUI that has the logic to calculate these metrics based on values entered in GUI fields. This GUI forms a part of the encrypted IP source in Vivado. Sysgen block is merely a Simulink wrapper of this block.
So it is recommended to refer to PG149 as mentioned in the Sysgen FIR block documentation, which would have guided to the Vivado GUI information.
However, the utility function that you have pointed out "xlGetReOrderedCoeff" also gives an indication of coefficient size mismatch. I have configured a FIR block with SSR=2 , decimation =5 and 32 coefficients and run the utility function. It indicates that reload coefficients should be 35. The attached snapshot shows this.
04-02-2020 07:37 AM
Thanks for the reply. Using VIVADO, I can look at the FIR IP in the netlist project, and the summary tab does include the calculated number of coefficients.
I was able to generate the reorder file from the IP.
I was not able to use the xlGetReOrderedCoeff utility. I have a multi-filter subfunction, and no matter which FIR I select in Simulink, the utility generated the coefficients as if the first filter in the chain was selected.
04-06-2020 05:45 AM
Hi @curtisra ,
Regarding the utility function, you have mentioned that it generates coefficients related to only one filter.
Do the filters in the sub-function contain different number of coefficients? This could be a result of corrupted cache. Could you try the operation after deleting the sysgen cache ?
Also check if making a dummy parameter changes in FIR block and then selecting that FIR block allows the utility function to generate the coefficient correctly for that block.
I did a small example with two FIR filters and using the utility function, I could successfully generate the reload ordered coefficients.
So the above should clear if the Sysgen is not recognizing the FIR block due to some cache problem in Simulink.