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 issuesConsidering 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

Additionally both Quartus 15.1 and 17.1 the Fir filter still has the issue with the low active reset declaration in the _hw.tcl file but in fact it is active high! You can find a description here.And here is the capture with Quartus 15.1:First read the data output is 0x16 but valid never is set to high and at the end the end (yellow circle), the output changes but the valid not set to high.

Hi Erich, As I understand it, you observe some behavior mismatch between the signatap vs the user guide for FIR II in both 17.1 and 15.1 especially on the read enable and valid signal. Thanks for highlighting this. This seems to be trending towards user guide related. Would you mind to help to create a simple test design with FIR II only and perform a Modelsim simulation with Q17.1 or later to see if can replicate similar observation? This would be helpful to narrow down to any functional related issue. If Modelsim also shows similar observation, please help to share with me the simulation files so that I could perform replication and highlight to Engineering. Please let me know if there is any concern. Thank you very much. Best regards, Chee Pin

Hi Chee Pin!It is not only a mismatch between manual and the implementation. The implementation is for sure wrong! In Quartus 15.1 there is never a valid signal -> so a Avalon Master will never return proper data.In Quartus 17.1 the valid signal is much to early -> Avalon Master will receive wrong and too much data!Regarding simulation, I tried to setup a simulation. If I enable the Coefficients interface in Quartus 15.1 it doesn't even compile. With Quartus 17.1 it compiled but it did not work at all -> therefore another bug(s) in simulation as well.Best regards,Erich

Hi Erich, Thanks for your update. To further narrow down the focus, I would like to recommend to use the latest Quartus version ie 18.1 so that we could isolate out any bug which might have been fixed prior to this version. Please help to create a simple test design with FIR II only and run a Modelsim simulation to see if similar issue observed. Please share with me the simulations for replication as well. Please let me know if there is any concern. Thank you very much. Best regards, Chee Pin

Hi Chee Pin!As I written in my previous post, the simulation does not work and does not behave as the real implementation -> therefore I started to capture data with the Signal Tap Logic Analyzer!So setting up a simulation does not help. As I already wrote in an other post of a different topic.Intel decided to stop the support requests and there is no NDA so I can not give company implementations to the puplic! So I cannot give you my project.You could setup a project and capture real data with Signal Tap Logic Analyzer to see the issue. Same is true for simulation.I will not setup Quartus 18.1 because as far as I saw there were no important changes. And if I have a look to the FIR filter release notes there were no changes after 17.1:https://www.intel.com/content/www/us/en/programmable/documentation/hco1421697814795.htmlBest regards,Erich

BUG - Fir filter coefficient read mode

25 Replies

CheepinC_altera
Regular Contributor
6 years ago
Hi Erich, Sorry as it seems like I am unable to add the screenshot into the post. I have tested sending you through email and hopefully you can get it. Thank you.
EGrub
Occasional Contributor
6 years ago
Hi Chee Pin!
Thank you for your image!
Above is your screenshot you send me per mail!
But you did not reset the coefficient interface like it is descriped in the FIR manual:
Looking forward to your answer!
Best regards,
Erich
CheepinC_altera
Regular Contributor
6 years ago
Hi Erich, For your information, the reset took place much earlier which is not shown in the screenshot which was a zoom in. As for the user guide extraction that you shown in the previous post, it is related to reloading coefficient with new data. In my simulation, I was showing a reading of existing coefficient in FIR IP. Thank you.
EGrub
Occasional Contributor
6 years ago
Hi Chee Pin!
If you have a look to mir first post and if you compare the waveforms from the signal tap then you will recognize that they look exact like the waveforms from the manual except that the valid is wrong.
Best regards,
Erich
EGrub
Occasional Contributor
6 years ago
And here is the read from a Quartus 15.1 FIR:
Valid is always 0!
Best Regards,
Erich
CheepinC_altera
Regular Contributor
6 years ago
Hi Erich, Just to update you on my recent finding after running hardware test and simulation. For your information, with my simple test design, I can get the same observation in both hardware and simulation. One thing that I notice is that it seems like we do not need to assert the read signal to retrieve the coefficient value at a specific address. With the coeff_in_areset = 0, as long as your address is a valid value, then the coeff_out_valid = 1 and coeff_out_data will show the coefficient data at that address. When I change to different valid address, the right coefficient data is output. There is one clock cycle latency from address change to the coefficient data available at the out_data. This tallies between simulation and hardware. Note that I am using Q18.1Pro with A10. Since you are observing differences between hardware and simulation with previous Quartus version, I would like to recommend you to use the latest Q18.1Pro where I observe consistent functional behavior between the simulation and hardware. Note that it seems like I am unable to attach the screenshot to this post. Will try to email you the screenshot. Please let me know if there is any concern. Thank you. Best regards, Chee Pin
EGrub
Occasional Contributor
6 years ago
Hi Chee Pin!
Here your screenshots:
EGrub
Occasional Contributor
6 years ago
Hi Chee Pin!
Do you agree that the behavior is different than described in the manual?
Best regards,
Erich
CheepinC_altera
Regular Contributor
6 years ago
Hi Erich, Thanks for your update. From my previous simulation, seems like there is only one clock cycle latency from the address changes to coeff data available at the out_data instead of the 3 clock cycles shown in the user guide. Just wonder if you are referring to this difference? If not, please feel free to further elaborate so that I could highlight to Factory for documentation update. Please let me know if there is any concern. Thank you. Best regards, Chee Pin
EGrub
Occasional Contributor
6 years ago
Hi Chee Pin!
Really? Do I really need to explain it?
First what you described here: https://forums.intel.com/s/question/0D70P000006INUJSA4
Valid is always high!!!!!!!
Read request is not necessary! Why is there then a read request signal?????????????????????????
Data changes one clock cycle after, the manual states 3!!!!!!!
Reset signal seem not to be necessary for read
The waveforms for reading in the manual shows a reset upfront!!!!!!!!!!
Behavior between Quartus 15.1 and Quartus 17.1 is different but manual does not show any difference!
Maybe even Quartus 18.1 behavior is different but there is no new document for that!
Best regards,
Erich