Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
728 Views

Custom PHY 8b/10b test fails but 8b is OK

Hi, 

 

I am trying to validate my Custom PHY design with the transceiver toolkit. I am using the transceiver toolkit to generate test-patterns. My setup is very similar to the setup in The Transceiver Toolkit Example for the Cyclone V GX, only that I have 8bit symbol width and want to use 8b/10. I have serial loopback enabled, but would like to test this on gigabit hardware once it works. Without 8b/10b I can send my test-pattern and receive it without bit-errors. 

 

As soon as I enable 8b/10b in the Custom PHY, I don't receive anything. 

  1. I can't even get the receiver side to sync. It's not even receiving bit errors, it's not doing anything!  

  2. Even if it would sync, I suspect that the word-alignment will not match anyhow, but I am also getting timing violations
  3. In the Custom PHY, I can only select one magic 10b word for alignment (OK, that's fine so far)  

  4. But In the transceiver toolkit, there is only the option to have an 8b preamble word in the generator. So depending on the running disparity, I could end up with one or the other on the receiving side?  

  5. In the Altera Transciever PHY IP Core User Guide, they sugggest using 1011111100 for word alignment.Where does this come from? This doesn't look like a comma symbol to me...  

 

 

How do you guys test your Custom PHY with GIGE? I guess can't access the transceiver toolkit in the simulation, so that's not an option I think. 

 

Cheers, Peter
0 Kudos
3 Replies
Highlighted
Valued Contributor III
4 Views

OK, the timing violations seem to be "harmless" as they were associated with the the pattern generator. Altera has set a false path on them in their cyclone v gs reference designs (http://www.altera.com/support/examples/on-chip-debugging/on-chip-debugging.html) as well: 

 

set_false_path -from set_false_path -from set_false_path -from set_false_path -from set_false_path -from set_false_path -from .gpll~PLL_OUTPUT_COUNTER|divclk}] -to .gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch.inst_av_pcs_ch|inst_av_hssi_8g_rx_pcs|wys|rcvdclkpma}] set_false_path -from .gpll~PLL_OUTPUT_COUNTER|divclk}] -to .gen_bonded_group.av_xcvr_native_inst|inst_av_pcs|ch.inst_av_pcs_ch|inst_av_hssi_8g_tx_pcs|wys|txpmalocalclk}]  

 

(Besides, they showed up without the 8b/10b interface, and there, the test ran fine....) 

 

So Back to the original problem: What am I doing wrong?
0 Kudos
Highlighted
Valued Contributor III
4 Views

Hi Peter, 

 

I just read your post, do you finally succeed to run your Cyclone V design (with 8b10b) on the Transceiver Toolkit ? 

 

I have a very similar problem with a Stratix V GX. 

I start from an Altera example design for Stratix V GX, it runs correctly with my SI Dev Kit board with the Transceiver toolkit. 

Then I modify the example design, I mainly enable the 8B10B codec on the XCVR Custom PHY and increase the word alignment length accordingly. 

When I test this modified example: 

- The Tx transceiver seems to run correctly 

- For the Rx transceiver, the indicator "RX CDR locked to data" is green but the Receiver Channel remains in Yellow with the following indication: "TOOLTIP_STATUS_RECEIVER_CHECKING_BUT_NOT_LOCKED"... 

The behaviour is similar with and without the check of option "enable word aligner" 

 

Thanks in advance for your help. 

 

Regards 

Mike
0 Kudos
Highlighted
Valued Contributor III
4 Views

Hello, 

 

Even if this thread is a bit old I too would like to know if you had any luck in getting the custom PHY working with the 8b10b encoding. I have been working with this module since it is required to be instantiated for the SerialLiteII core when working with Stratix V devices, but I seem to have the same symptoms as you: 

 

  • I am able to simulate correctly. 

  • The tx portion of the PHY is able to apparently transmit the patterns correctly. 

  • The receiver side simply ignores the input packets, never asserting the stat_rr_link signal, nor giving any indication that it is seeing something at its input. 

 

 

I noticed that this happens even in the provided reference models: 

 

https://www.altera.com/support/support-resources/design-examples/interfaces-peripherals/exm-serialli... 

 

The testbenches that are provided simulate and compile correctly, yet the actual testbench inside them fails. The reason being that the link was never set up and it times out in error.  

 

I have a feeling that the 8b10b portion is buggy, but since the SerialLiteII core requires it, turning it off is not an option. 

 

Regards, 

Alfredo
0 Kudos