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

[EGrub]

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.

[CheePin_C_Intel]

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

[CheePin_C_Intel]

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

[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

[CheePin_C_Intel]

Hi 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

[CheePin_C_Intel]

Hi 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

[CheePin_C_Intel]

Hi 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

[CheePin_C_Intel]

Hi 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

[CheePin_C_Intel]

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]

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

[CheePin_C_Intel]

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]

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]

And here is the read from a Quartus 15.1 FIR:

Valid is always 0!

Best Regards,

Erich

[CheePin_C_Intel]

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]

Hi Chee Pin!

Here your screenshots:

[EGrub]

Hi Chee Pin!

Do you agree that the behavior is different than described in the manual?

Best regards,

Erich

[CheePin_C_Intel]

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]

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