XAUI Phy in Stratix IV GX

--- Quote Start ---

actually I'm using the Stratix IV GX Devkit (EP4SGX230KF40)

--- Quote End ---

I have this kit.

--- Quote Start ---

and try to implement a communication using the HSMC- loobpack adapter on port HSMCA. The protocol I'm using is XAUI. I started with the ALTGX and ALTGX_RECONFIG Megafunctions and a pattern generator in conjunction with a pattern checker. This little testdesign works fine in some cases. Mostly the lanes on the receiver are mixed up compared to the transmitter even though the rx_channelaligned signal is set to '1' from the ALTGX function.

--- Quote End ---

I have not seen any lane assignment errors on this board. Do you mean that the data is scrambled from what you expect?

Cheers,

Dave

Hi Dave,

the lanes are scrambled. If I send at tx_datain X"FFEEDDCCBBAA9988" the I receive at rx_dataout X"EEFFCCDDAABB8899". (see attached signal tap screenshots tx_datain.jpg and rx_dataout.jpg)

In some cases the alignment is correct (rx_dataout2.jpg). Before sending the data I use two start packets. The transmission of these packets is always incorrect (see the screenshots).

Which megafunction you are using? ALTGX and ALTGX_RECONFIG?

What are your parameter settings? (if you want have a look at my settings, see params at the end of reply)

Which clocks you re using? I use for XAUI Refclk the LVDS clock source at pin AA2 (156.25 MHz)

For the dynamic reconfiguration circuit I'm using the freerunning clock clkin_50 at pin AC34.

The data generator is clocked with the coreclockout from ALTGX block.

How is your implementation of the reset controller for ALTGX_RECONFIG?

My reset sequence is like in the Stratix IV Device Handbook Volume 2: Transceivers, page 4-8, figure 4-4. (see attached altgx_reset1.jpg and altgx_reset2.jpg)

There just is one difference. In my case the busy signal is always '0'.

How do you verfy the transmission? With external or internal loopback?

p.s.

I try using the XAUI_PHY (external reconfig is not required) like in the example for Stratix V.

I didn't succeed. (tx_ready and rx_ready signals are always '0')

Jens

---------------------------------------

ALTGX settings

---------------------------------------

General

protocol: xaui

nr of channels: 4

channel width: 16

effective data rate: 3125

clock freq.: 156.25

base data rate: 3125.0

PLL/ports

train transceiver clock : enabled

optional ports: enabled

ports/calibration

analog power: auto

Rx analog

static equalizer ctrl: disabled

DC gain: 0

common mode voltage: 0.82

termination resistance: 100 ohm

Tx analog

transmitter buffer power: auto

transmitter common mode voltage: 0.65

transmitter termination: 100 ohm

next parameter all to 0

Reconfig sttings

just offset cancellation is enabled

--- Quote Start ---

the lanes are scrambled. If I send at tx_datain X"FFEEDDCCBBAA9988" the I receive at rx_dataout X"EEFFCCDDAABB8899".

--- Quote End ---

Your original description is ambiguous. The lanes (wires on the board) are not scrambled, the data from a lane is scrambled.

Look at the pattern - what do you see?

FFEE DDCC BBAA 9988

EEFF CCDD AABB 8899

Each 16-bit value has the bytes swapped. Now look in the Stratix IV user manual. You will find there is a FIFO that can cause this byte-swapping. You need to use the synchronization controls to align to a pattern; look at rx_byteorderalign and rx_enapatternalign, there is also a byte-reversal feature you can use (if you do not control the source of the data).

However, I would have thought XAUI would have taken care of this for you, by initializing the link with sync codes.

Cheers,

Dave

Dave, you are right. The bytes are swapped. Also in some cases the alignment is not correct.

I read in the transceiver section of Stratix IV hadbook that byte ordering is disabled in XAUI mode (refer figure 1-123, page 1-156). Furthermore the rx_enabyteord (together with rx_

byteorderalignstatus) signal is just used when byte ordering block is enabled. In XAUI mode I don't have access to these signals.

Even if I had the possibility to restart byte ordering operation how should I know when it is to do?

After each reset the byte order is random. In the attached screenshots you see also the misalignment. Affected are also the control signals.

Transmit:

control | 0xFF | 0x00

lane 3 | 0x0707 | 0xAD00

lane 2 | 0x0707 | 0x0000

lane 1 | 0x0707 | 0x0000

lane 0 | 0x0707 | 0x00AB

Receive:

control | 0xFF | 0x55 | 0xAA

lane 3 | 0x0707 | 0x0007 | 0x07AD

lane 2 | 0x0707 | 0x0007 | 0x0700

lane 1 | 0x0707 | 0x0007 | 0x0700

lane 0 | 0x0707 | 0xAB07 | 0x0700

(for more details see signal tap files in the zip archive).

Dave, you have an example with XAUI running on the Devkit and loopback adapter? I could compare it with my implementation.

Jens

Jens

Hi Jens,

--- Quote Start ---

Dave, you are right. The bytes are swapped. Also in some cases the alignment is not correct.

--- Quote End ---

Ok, so this is a XAUI synchronization issue then.

I have not used the XAUI core.

--- Quote Start ---

After each reset the byte order is random. In the attached screenshots you see also the misalignment.

--- Quote End ---

I'd recommend putting a Modelsim simulation together. Its a lot easier to probe signals and change things there.

--- Quote Start ---

Dave, do you have an example with XAUI running on the Devkit and loopback adapter? I could compare it with my implementation.

--- Quote End ---

I'm sorry, but I do not.

Perhaps someone more familiar with the operation of the XAUI core can comment on how the link is supposed to be synchronized.

Cheers,

Dave

Hi Nick,

Now I'm using XAUI_PHY LPM instead of ALTGX. At the receiver the upper and lower 32 Bits of data and corresponding control bytes are swapped sometimes.

Transmit:

control: 0xFF, 0xFF, 0x01

data: 0x0707 0707 0707 0707, 0x0707 0707 0707 0707, 0x1111 1111 2222 22FB

Receive:

control: 0x0F, 0x0F, 0x1F

data: 0x0707 0707 0707 0707, 0x0707 0707 0707 0707, 0x2222 22FB 0707 0707

In some cases at Receive:

control: 0xFF, 0xFF, 0x01

data: 0x0707 0707 0707 0707, 0x0707 0707 0707 0707, 0x1111 1111 2222 22FB

After Idle-Code Gap I do the alignment manually by means of detecting the START Code (0xFB) in the upper or lower 32 Bit word.

Because we are using our own protocol we can do that. I don't know how its viable in case of 10GE.

Good Luck!

Jens

Hello Jens,

Could you please share your xaui project? I'm trying to test by using a hsmc loopback and i'm failing on it.

Thank you!

--- Quote Start ---

Hi Nick,

Now I'm using XAUI_PHY LPM instead of ALTGX. At the receiver the upper and lower 32 Bits of data and corresponding control bytes are swapped sometimes.

Transmit:

control: 0xFF, 0xFF, 0x01

data: 0x0707 0707 0707 0707 (tel:0707 0707 0707), 0x0707 0707 0707 0707 (tel:0707 0707 0707), 0x1111 1111 2222 22FB

Receive:

control: 0x0F, 0x0F, 0x1F

data: 0x0707 0707 0707 0707 (tel:0707 0707 0707), 0x0707 0707 0707 0707 (tel:0707 0707 0707), 0x2222 22FB 0707 0707 (tel:0707 0707)

In some cases at Receive:

control: 0xFF, 0xFF, 0x01

data: 0x0707 0707 0707 0707 (tel:0707 0707 0707), 0x0707 0707 0707 0707 (tel:0707 0707 0707), 0x1111 1111 2222 22FB

After Idle-Code Gap I do the alignment manually by means of detecting the START Code (0xFB) in the upper or lower 32 Bit word.

Because we are using our own protocol we can do that. I don't know how its viable in case of 10GE.

Good Luck!

Jens

--- Quote End ---

Hi comododragon,

I could not find the project on my workstation. It's more than one year gone. Finally the swapping of lower and upper 32 Bits in case the alignment was wrong was the key to bring up the XAUI.

Within the project we used the alt2gxb_reconfig and xaui_phy Megafunctions. For the loopback test the best is you have two instances of XAUI Phy. The alt2gxb_reconfig must configured for using two Phys.

What are the problems in your case?

Jens

Thanks for the reply.

Do I really need the alt2gxb_reconfig module for the Stratix IV GX Development Kit? On the reference manual is written that is not mandatory.

I was connecting the xgmii_rx_clk to xgmii_tx_clk (XAUI), tx_clk (MAC) and rx_clk (MAC). Everytime I tried to read/write on MAC Registers, the waitrequest signal asserted and never went low. I've solved this by connecting all TX clocks to a 156.25 PLL clock (since there was no clock coming from xgmii_rx_clk). Now I can read/write on all registers.

Now I'm trying to send signals by using a NIOS connected to a DC MM-to-ST FIFO, but the data doesn't come back. So I can't use the hsmc loopback to test this module?

Best regards.

Yes, you need the reconfiguration controller because the offset cancellation must be done. Look at my attached screenshots.

They show the settings for the LPMs, which I use actually on a custom hardware. For the devkit it should be the same. The analog options in

XAUI Phy may vary.

xaui_lpms.jpg show the connection between reconfig controller and phy. The signal reconfig_fromgxb is splitted between the 2 phys. (described in

Stratix IV Device Handbook Volume 2: Transceivers, Feb. 2011, p. 5-77)

reconfig_clk.jpg shows the constraints for the clock to the reconfig controller. Use an appropriate clock on the devkit.

The connection from xgmii_rx_clk to xgmii_tx_clk is correct. I use this clock to drive the control logic for send and receive data over the XAUI channels.

I do not use a MAC (10GE) just the low level XAUI protocol.

best regards

Jens