Forum Discussion
Occasional ContributorBUG - Fir filter coefficient read mode
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
25 Replies
EGrubAdditionally 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.
CheepinC_alteraRegular Contributor
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- EGrub
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
- CheepinC_alteraHi 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
- EGrub
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.html
Best regards,
Erich
- CheepinC_alteraHi Erich, Thanks for your update. Generally it is recommended to use the latest Quartus to isolate any version dependent issue and also in case any update which was not captured in the release note. As I check, it seems like the latest release note is only up to 17.1. It would be great if you could try with the latest Q18.1 By the way, I understand that you mentioned simulation seems not working. Would you mind to further elaborate on the specific issue that you are observing with simulation? It would be great if you could help to create a simple test design which could replicate the issue in simulation and share with me the simple test design. Note that this is referring to simple test design but not your project. Please let me know if there is any concern. Thank you. Best regards, Chee Pin
- CheepinC_alteraHi Erich, Just would like to follow up with you on the simple test design. Please let me know if there is any concern. Thank you. Best regards, Chee Pin
- EGrub
Hi Chee Pin!
Sorry for my late answer!
I will not install Quartus 18.1 as there was no improvement on FIR or Quartus itself. The only updates I saw were done for the Pro version.
I'm afraid I can not promise that I will get some time for setting up another simulation. And yes simulation does not work but this thread was created because the real implementation does not behave like the manual! You can see the wave forms in my first post. So maybe that should be forwarded to the developers so that they can have a look to that.
The developers should have a simulation for the FIR including the coefficient reload. They should know that it does not work! That is very basic.
By the way from the design perspective it is a very bad implementation because it is declared as Avalon Bus but it needs upfront a reset which is not the way how the Avalon Bus is specified!
Best regards,
Erich
- CheepinC_alteraHi Erich, Sorry for the delay. Thanks for your clarification that you have observe similar issue in simulation. For your information, the simulation would represent the actual functional behavior of the IP. If issue is observed in simulation, you would be seeing similar in the hardware. As I understand it, all the IPs will undergo functional verification by the Engineering prior to release. If bug was found during the verification, it will be fixed prior to release. For those which was not fixed in current release, it will be stated in the errata. To facilitate further debugging into the functional behavior, would you mind to share with me the previous simulation that you had which show the issue? I would like to perform observation replication on my side for further debugging. Please help to share with me your simulation together with steps for replication. Once replicated, I will engage Factory if required. It would be much appreciated if you can share me your simulation for replication so that we could further debug into this potential problem. Thanks for your understanding. Please let me know if there is any concern. Thank you. Best regards, Chee Pin
- CheepinC_alteraHi Erich, For your information, while pending for your simulation files which could replicate anomaly in the coeff reading in Modelsim simulation, I have created a simple simulation example with FIR II in Read Mode in A10 and Q18.1pro. For your information, from the simulation, it seems like the coeff reading is working as expected. I can observe the coeff_out_valid goes high together with valid data coeff_out_data after coeff_in_read goes low. Please let me know if there is any concern. Thank you. Best regards, Chee Pin
