BUG - Fir filter coefficient read mode

[EGrub]

Hi all!

For writing/reading coefficients I made a wrapper to compute the proper reset before accessing the Avalon slave.

Writing seems to work fine but reading has issues

Considering the FIR II IP Core User Guide and the read waveform:

As you can see they forgot to add the read signal (read enable) to the waveform.

If I capture the signals with the Signal Tap Logic Analyzer (Quartus 17.1), the behavior is completely different!:

As you can see in the waveform above the reset is right and the address and read signal is set after the same amount of clock cycles. 3 clock cycles later the proper data shows up on the read interface but the valid signal comes much earlier and therefore the behavior is wrong and does not correspond to the user guide.

Behavior in Quartus 15.1 is wrong as well as the valid signal is never set there!

I will provide later a capture with the Signal Tap Logic Analyzer.

Kind regards,

Erich

[CheePin_C_Intel]

Hi Erich, Thanks lot for your update and clarification. These would be helpful for filing a specific request to Factory to update the documentation. Thank you very much for your help and feedback. Best regards, Chee Pin

[EGrub]

Hi Chee Pin!

No it is not just a documentation issue!

If output is always valid (valid signal high) without a request I see that as an implementation issue/bug!

Best regards,

Erich

[CheePin_C_Intel]

Hi Erich, Thanks for your update. Regarding the output valid, if I understand your correctly, you are referring to the coeff_out_valid signal. For your information, per the observation in my simulation and signatap, this signal will be high one cycle after there is a valid coeff address fed to the coeff_in_address input to indicate there is a valid coeff data at coeff_out_data output. In the recent simulation and signaltap screenshots from me, you can observe that the coeff_out_valid = low when there are invalid address ie -5, -4. The coeff_out_valid goes high one clock cycle after there is a valid address ie 0, 1, 2 ... Please feel free to let me know if there is any further concern. Thank you. Best regards, Chee Pin

[EGrub]

Hi Chee Pin!

Yes I have a concern regarding that topic!

In real live there is always a valid address assigned to the input.

If the filter has 256 coefficients there is then no invalid address possible because input width is exactly 8 bit!

So in a real implementation the valid would be always high!

By the way, you should not have negative addresses ;-)

Best regards,

Erich

[CheePin_C_Intel]

Hi Erich, Thanks for your update and elaboration. I understand the concern on the valid would be always high in actual implementation when there is no invalid address possible. I will feedback this to Factory for them to look into future enhancement. Regarding the negative address, yes, you are right. I am just feeding in negative address to mimic the behavior with invalid address. Please let me know if there is any concern. Thank you. Best regards, Chee Pin