E-Tile not working with custom pattern ?

[TobiasS98]

Hi,

I am currently trying to implement an E-Tile into my design. I used a tcl script and the system console to make a test with PRBS31 and the setup. Using PRBS31 with Serial Loop as well as with my physical connection is running now with a BER of 0 after a parameter search.

First of all: Is it correct that I get a BER of 0 with a Cable? Or may this be a bug ?

A soon as I try to use a custom pattern it stops working. I followed the guide from the E-Tile User Guide and implemented my custom pattern. I used an oscilloscope to verify it. The pattern was properly displayed there.

The problem is the Bit Error Rate. I tried a parameter sweep of the TX parameter, RX Adapation and also a optimizer algorithm with both TX and RX. In no case do I get a reasonable error rate. My BER is always bigger 0.05.

I already checked:

- rx_locked_to_data

-rx/tx_ready

but they where always 1 when I checked.

Is there any specifications on how my pattern is encoded ? Could this be a cause of the problem ? Or may it be anything else ?

Kindest Regards

Tobias

[Kshitij_Intel]

Hi,

Can you please check are you configuring the 0x84 = 3b'111 for the user pattern.

Please refer to the link below for more information.

https://www.intel.com/content/www/us/en/docs/programmable/683723/current/prbs-usage-model.html

Thank you

Kshitij Goel

[TobiasS98]

It did set those bits. I am also now able to get a zero bit error. Though If I capture the data via the PMA register they do not fit my pattern at all. How exactly is this data captured ?

[TobiasS98]

I have added the result of my signal analyzer. The received data do to equal the one I send. I already checked the TX signal with an oscilloscope. I also took an eye diagram. Both looked fine. The connection is etablished as described in the guide and rx and tx both signal ready and rx_lockedtodata is also true.

Using the internal PRBS31 I got 0 bit error. So the signal quality should be good enough.

[Kshitij_Intel]

Hi,

It's good to hear you are getting zero BER now.

Just wanted to check for the user defined pattern are you following the steps mentioned in the below link.

https://www.intel.com/content/www/us/en/docs/programmable/683723/current/user-defined-pattern-example.html

Also, please check the transmit adaption order select which determines the how 64 bits sent to 32-bit transceiver channel.

https://www.intel.com/content/www/us/en/docs/programmable/683723/current/pma.html

Hope this will resolve your issue.

Thank you

Kshitij Goel

[TobiasS98]

I have done some further testing. And I was able to receive somewhat correct data when reading the RX_pma register out via systemconsole (the order was sometimes wrong of the 10 bit values).

Nevertheless, the values I receive from the rx_parallel_data interface are still completely wrong.

[TobiasS98]

I looked further into it and found that there is quite a big skew :

-90.758 u0|etile|xcvr_native_s10_etile_0|g_pma_rsfec_reset.g_auto_reset.reset_ip_auto_etile_inst|reset_control_inst|g_rx.g_rx[0].g_rx.counter_rx_ready|r_reset u0|qsys_rx_snapshot_fifo|qsys_rx_snapshot_fifo|dcfifo_component|auto_generated|fifo_altera_syncram|altera_syncram_impl1|ram_block2a0~reg0 ALTERA_INSERTED_INTOSC_FOR_TRS|divided_osc_clk u0|etile|xcvr_native_s10_etile_0|rx_clkout|ch0 1.600 -90.864 1.384 Slow 900mV 100C Model

Could this be the cause of this problem ?

[Kshitij_Intel]

Hi,

Yes, this could be.

Thank you

Kshitij Goel

[TobiasS98]

I have taken another look and just want to summarize a few things:

1. The physical connection seems to work. PRBS31 works when used in the System Console and reaches BER of 0. I also tested to Inject Errors to verify the link is properly working

2. I have taken waveforms with the oscilloscope [image.png] to verify a proper transmission of the data. The 80-bit sequence here was [0x00AAAAAfff0000AAFF5500FFAAAAA000055FFAA]

       - I have used two ways to send this data. 1. via the debug interface of the e-tile and also via my own implementation of tx_parallel_data. Both ways worked

3. I have changed the program so that no direct timing violation is recognized by the Quartus Timing Analayzer

4. I used a tcl script inside of the system console. There I was able to get a partial success. I send the sequence [0x1BC,0x2BC,0x3BC,0x4BC,0x5BC,0x6BC,0x7BC,0x8BC] and received [0x2BC,0x3BC, 0x3BC,0xBC,0x1BC,0x2BC,0x3BC,0xBC,0x1BC]

-> The mentioned data was read out by using following commands:

rcfg_etile $phy $channel 0x0001C 0x0 1
rcfg_etile $phy $channel 0x00018 0x4 1
rcfg_etile $phy $channel 0x0001A 0x0 1
rcfg_etile $phy $channel 0x0001A 0x0  1
rcfg_etile $phy $channel 0x0001A 0x0  1
rcfg_etile $phy $channel 0x0001A 0x0  1
rcfg_etile $phy $channel 0x0001A 0x0  1
rcfg_etile $phy $channel 0x0001A 0x0  1
rcfg_etile $phy $channel 0x0001A 0x0 1
rcfg_etile $phy $channel 0x0001A 0x0  1

5. I have added an EYE diagram measured by the System Console Toolkit

=> The general transmission seems to work more or less fine so far. The link should work.

Now the problem begins when I try to read it out via the FPGA Core Interface. I am using a FIFO which writes on rx_ready true and is then readout later. I also verified that the FIFOs are read out properly. I also tried using the Signal Tap Logic Analyzer to read out the data from rx_parallel_data (see attached image). But the receiving data seems completely random. I would assume there is some problem between the PMA and my FPGA core but I can't so where and I am also not sure how to properly debug this part.

I have already tried:

1. Enabling Deskew and adding the deskew bits

2. Reducing the transmission speed

3. Use TX channel bonding

4. Different reference clocks

But nothing has produced a useable result so far. I would be happy about any recommendation on how to proceed.

[Kshitij_Intel]

Hi,

Are you doing adaptation?

https://www.intel.com/content/www/us/en/docs/programmable/683723/current/rx-adaptation-modes.html

Thank you

Kshitij Goel

[TobiasS98]

Yes, as described in the user guide.

1. Set to Serial Loopback

2. Start High Effort Adaption

3. Turn Serial Loopback off

4. Start High Effort Adaption

The PRBS31 test works well after that.

[Kshitij_Intel]

Hi,

When you are testing with custom pattern you have to implement your custom pattern verifier as well.

That's why you might be not able to see the BER 0.

When you testing with internal PRBS pattern for the same configuration PRBS verifier is implemented for the same.

Please check this.

Thank you

Kshitij Goel

[Kshitij_Intel]

Hi,

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘ https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Thank you

Kshitij Goel