Is the channel indicator byte (0x7C) in the SPI IP Core guaranteed?

[SSmit7]

I have implemented the SPI to Avalon-MM IP core in my MAX10 design. While running stress tests on the data transfer between a processor and the MAX10, there is a very rare situation where the channel indicator byte does not appear in the returned packet.

E.g. I am expecting the following returned packet from the MAX10 via the SPI interface:

7C 00 7A 80 00 00 7B 04

(with all preceding and succeeding idle [0x4A] characters removed, and the channel indicator is shown in bold).

In rare circumstances, I will receive an idle character instead of the channel indicator:

4A 00 7A 80 00 00 7B 04

Note that the channel number is still present, but the channel indicator character is not.

I see no other strange or unexpected packets or bytes. Is this behaviour expected? Is the channel indicator character not guaranteed?

Thank you in advance.

[Rahul_S_Intel1]

Hi ,

I cannot say like that , can you try the same in ideal condition , that mean to say only usign spi prorotocl , and power utilized by the fpga is minimum

[SSmit7]

Hi there

I'm not sure what you are asking. The power utilised by the FPGA is not very high, though there are a few other pins driving signals. I am not sure how this will affect the SPI though? Are you suggesting that this could be a power consumption issue?

[Rahul_S_Intel1]

Hi Ssmit,

The above suggestion is to rule out external factors, some times the data misalignment will be caused by power . If the FPGA is not utilizing much power , we can rule out . Is the SPI ip is from third party vendor

[SSmit7]

The SPI IP is Intel Quartus IP Core included with Quartus Prime 17.1.0 (subscription edition). It is a subsystem in the Qsys System Designer. The IP Core's name is SPI Slave to Avalon Master Bridge.

[Rahul_S_Intel1]

Hi Smit,

Just had conversation with internal guys and I check from our data base , as of now what ever u say like that kind of issue is not been reported and SPI protocol which is been used by altera is standard industrial protocol , not added any additional bits

[SSmit7]

Hi Sree

The problem is not with the SPI protocol itself. The SPI protocol layer appears to be working as intended. The problem is that the encoding used by Altera is not behaving consistently. This means that the error is probably occurring on the Packet layer of the SPI Core. If you refer to original question, you will see that I did not mention the problem of extra bits, as this is not what is occuring. The issue is that we are receiving an Idle character (0x4A) when we are supposed to receive a Channel Indicator character (0x7C). I provided an example of the behaviour. Please can you inform the internal guys about that.

[Rahul_S_Intel1]

HI ,

To give you an update , I am still checking the internal team , kindly be patient

[Rahul_S_Intel1]

Hi ,

I am awaiting for internal confirmation

[SSmit7]

Hi

Thank you for the update on the progress. I look forward to a resolution to this matter.

[Rahul_S_Intel1]

Hi SSmit,

Is it possible to share sample project where we can create the issue , I have consulted the software team , they have the below request .

Sample project

Signal tap of the signals

[SSmit7]

Hi RSree

I am able to send you the Qsys project to test, but I may not send you the rest of the project. I have no SignalTap signals to show you, we detected the error in on the receiver side, which is the SPI port of a NXP T1042 processor. Where can I send the qsys projects?

[Rahul_S_Intel1]

Hi Ssmit,

Sorry I could not able to provide a solution for the above , with your permission can i close the tread

[SSmit7]

Hi Rahul You can close the thread. Regards Stuart