Forum Discussion

fpga_user1's avatar
fpga_user1
Icon for New Contributor rankNew Contributor
2 months ago

Arria 10 Native PHY 66:64 RX wrong word with valid asserted

I am using Arria 10 Native PHY in Basic Enhanced PCS mode at 12.5 Gbps for a custom protocol.

The protocol layer is implemented in FPGA fabric. The Native PHY is intended to provide the serial transceiver path and the Enhanced PCS 66b gearbox only. The fabric provides one 66b block per clk_sys: 2-bit sync/control header + 64-bit payload

The goal is a non-backpressure full-rate interface: one 66b TX block accepted every clk_sys, and one 66b RX block produced every clk_sys after RX lock.

I've attached the .tcl to generate the core, but some of the key config parameters are:

protocol_mode = basic_enh
data_rate = 12500
enh_pld_pcs_width = 66
enh_pcs_pma_width = 64
TX 64b/66b encoder = disabled
RX 64b/66b decoder = disabled
TX scrambler = disabled
RX descrambler = disabled
RX block synchronizer = enabled
TX FIFO mode = Phase Compensation
RX FIFO mode = Phase Compensation
double width = disabled
10GBASE-R insert/delete = disabled
Interlaken deletion features = disabled

Clocking:

clk_sys      <= tx_clkout(0);
tx_coreclkin <= (others => clk_sys);
rx_coreclkin <= (others => clk_sys);

Controls:

tx_enh_data_valid <= (others => '1');
rx_enh_fifo_rd_en <= (others => '1');
tx_pma_elecidle   <= (others => '0');

66b mapping:

(inside a loop that iterates for every channel 'c')
tx_parallel_data((c+1)*64-1 downto c*64) <= tx_data(c)(63 downto 0);
tx_control((c+1)*2-1 downto c*2)         <= tx_header(c)(1 downto 0);

rx_data(c)(63 downto 0)  <= rx_parallel_data((c+1)*64-1 downto c*64);
rx_header(c)(1 downto 0) <= rx_control((c+1)*2-1 downto c*2);

Observed in serial loopback simulation:
With RX FIFO in RX Register mode, rx_enh_data_valid has periodic bubbles, apparently matching the 66:64 gearbox cadence.
With RX FIFO in RX Phase Compensation mode, rx_enh_data_valid stays asserted, but rx_parallel_data periodically has a whole-word discontinuity. It looks like a 66b word is skipped/repeated, or the latency changes by one word. The event periodicity is about 160 ns, close to the expected 66:64 gearbox cadence.

These two captures are from a sequence where I receive wrong data with rx valid asserted (the first is the tx'ed sequence and the second the received:

To make the issue clear I mapped the word to a letter to make it easier to see the issue:

In the capture above there is the tx and rx sequence, and can be seen where the pattern breaks compared to tx.

My question is:
For Arria 10 Native PHY Basic Enhanced PCS with enh_pld_pcs_width=66, enh_pcs_pma_width=64, and RX FIFO in Phase Compensation mode, is a continuous non-backpressure 66b RX stream supported?

If yes, what configuration or clocking condition could cause a periodic one-word wrong while rx_enh_blk_lock, rx_enh_data_valid, and rx_control remain stable?

Thanks in advance.

5 Replies

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor

    Hi,

     

    Thank you for the update.

     

    It appears that I am unable to locate the other case in our internal system at the moment. Let me check with the forum moderators and see if they can help identify the related case.

     

    In the meantime, to facilitate the debugging process and ensure that we have a common understanding of the issue, could you please share a simulation example along with the detailed steps required to reproduce the observed behavior?  This information will help us investigate the issue more effectively while we work on locating the other case.

     

    Please let us know if you have any concerns or questions.

     

    Thank you.

    • fpga_user1's avatar
      fpga_user1
      Icon for New Contributor rankNew Contributor

      Hi,
      Thanks for your reply.

      With regards to another case: don't worry about it, this post is the actual case I want to discuss. I did two attempts to publish my question but the system was tagging it as spam.

      Regarding the simulation of the issue: I cannot upload the full design, but for this case, as my data is scrambled prior to enter the XCVR, it would be the same if a PRBS is used. In that case it should report the same symptoms: the data from XCVR is flagged as valid but the actual received data is not correct.

      Thanks.

      • CheepinC_altera's avatar
        CheepinC_altera
        Icon for Regular Contributor rankRegular Contributor

        Hi,

         

        Thank you for the update.

         

        Just to check check if you are able to create a simple test design (for example, using a fixed data pattern or an incremental data pattern) that can reliably reproduce the observed behavior? Having a simple reproducible design would help us replicate the issue on our side and facilitate the debugging process by using a known and controlled data pattern.

         

        If possible, please upload the design files to the support case. If the files are too large or cannot be attached to the case, you may also try sending them directly to me at [email protected].

         

        Thank you for your assistance, and I look forward to your feedback.

  • CheepinC_altera's avatar
    CheepinC_altera
    Icon for Regular Contributor rankRegular Contributor

    Hi,

     

    Thanks for your update. I took a closer look at the user guide for the case where the PCS/PMA width is configured as 66/64.

     

    In the RX direction, the soft gearbox repacks the 66-bit PCS blocks into 64-bit words toward the fabric. Because the two widths are unequal, the rates do not line up evenly: for every 32 input blocks (32 × 66 = 2112 bits), the gearbox produces 33 output words (33 × 64 = 2112 bits). As a result, one out of every 33 output cycles carries no valid data — which in your case, you would need the fabric logic needs to accommodate.

     

    If you would prefer a continuous, non-backpressured stream, my understanding is that you can configure a matched (even) PCS/PMA width ratio so that no gap cycle is required.

     

    Please let me know if you have any further questions. Thank you.