Native Phy Word Aligner

[JLee25]

Hi,

I am using Cyclone V Native Phy for custom protocol.

My simple project using the K28.5 as word aligner symbol.

But from signal tap, I see the rx_patterndetect triggered when data is 0xBE instead of 0xBC.

Please see my capture below.

Any idea why the rx_patterndetect asserted at wrong pattern?

Thank you!

BRs,

Johnson

[CheePin_C_Intel]

Hi Johnson,

As i understand it, you observe in some cases the rx_patterndetect go high even not for 0xBC pattern.

Would you mind to share with me you Native PHY .qsys or .ip file so that I can have a better understanding on your configuration.

Just would like to check with you also for the 2nd signaltap, do you observe data corrupt? Or if the 0xBE is something expected.

Thank you.

[JLee25]

Hi CheePin,

Yes, your understanding is correct that I am expecting to see rx_patterndetect assert for 0xBC.

0XBE is not expected that should not be seen at this stage.

During this stage, only repeated 4-byte idle will be seen.

BRs,

Johnson

[CheePin_C_Intel]

Hi Johnson,

Sorry for any confusion. As I unzip the native_phy that you are attaching, I only observe a native_phy.qip. Would you mind to help sharing with me the native_phy.qsys file?

Regarding the 0xBE, as I understand it, this is not a data that you are sending. Does it mean that the 0xFDBE data pattern is a corrupted data pattern and cause data error at the downstream logic at receiver?

Thank you.

[JLee25]

Hi CheePin,

I am using older Quartus Ver.16 for this.

Therefore I did not see the native_phy.qsys in the project.

Would you check the configurations using different file?

0xBE as you understood, is not the data I expected.

Perhaps 0xFDBE is a corrupted pattern, but I don't expect to see rx_patterndetect assetred by this.

BRS,

Johnson

[CheePin_C_Intel]

Hi Johnson, Thanks for your update. Probably you can share with me the native_phy.v file, the file generated by the Megawizard. As for the 0xBE, this seems to be a corrupted data with one bit flipped vs 0xBC if it is not something expected by you. I am not sure why the rx_patterndetect assert with 0xBE based on the current observation. Just would like to check with you on the following: 1. If you observe any timing marginality in the signaltap related logic? 2. Does the 0xBE issue goes away after reset? For example, get back correct 0xBC? 3. Just wonder if you have had tried to increase the sampling clock frequency ie 3x of the rx_clkout? Just to avoid any sampling issue. I will also look into you native phy configuration after receiving the .v file to see if can spot any anomaly. Thank you. Best regards, Chee Pin

[JLee25]

Hi CheePin,

Thank you for the reply.

Please see the v. file as attached.

BRs,

Johnson

[CheePin_C_Intel]

Hi Johnson,

Thanks for sharing the file. As I look into the Native PHY .v file, I could not locate any anomaly with it. Would you mind to help performing the following test just to isolate out any potential sampling issue with the signaltap?

1. Can you try to send continous and fixed data pattern ie 0xFDBC to RX to see if it can recover 0xFDBC correctly?

2. In addition, you may try to use PCS-PMA interface width to 20 instead of 10. With this, you will not need to use Byte Ordering and Byte SERDES blocks.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[JLee25]

Hi CheePin,

Thanks for the reply.

I did not test again, just to detect the combination of both rx_patterndetect and 0xBC.

Well, it did not trigger for more than 30 mins.

Therefore I suppose it's kind of timing issue related to SignalTap..

Do you think it's possible?

BRs,

Johnson

[CheePin_C_Intel]

Hi Johnson, Based on the currently observation, frankly speaking, we could not really narrow down the root cause if it is related to timing issue related to the signaltap. If you does not plan to further pursue the testing, you would need to perform thorough testing with your application to ensure it is meeting your expectation. For example, no issue with the received data and no word alignment issue. Thank you. Best regards, Chee Pin