Hi, I'm using an Arria EP1AGX60CF484C6 with an ALT2GXB core configured in XAUI mode (4 lanes). I'm trying to do a loopback to test it out. The loopback is in the core, so what I've done is connect the rx_dataout (64-bit) to the tx_datain (64-bit) and connect the rx_ctrldetect (8 bits) to the tx_ctrlenable(8 bits). The gxb_powerdown is permantely tied to a logic 0. The resets have been staggered so that the rx_analog is released first followed by the rx_digital followed by the tx_digital sections. The input clock is 156.25MHz. I'm using a HP Pro Curve Switch 6400cl to try to ger a link between the FPGA and the switch. I know that the Tx PLL is locking as this goes to an LED. I know that the Rx PLL is locking and it's switching over to lock on to the incoming data (rx_freqlocked is also output to an LED). I'm also watching the debug_rx_phase_comp_fifo_error[3:0] and debug_tx_phase_comp_fifo_error[3:0] - only bit 0 of each (they also go to LED's). I find that the debug_tx_phase_comp_fifo_error[0] seems to go high which suggests the tx FIFO has an overrun/underrun problem. Both the Tx and Rx FIFO's are being clocked by coreclockout which is generated by the GXB. I'm not sure why there is an error as the timing report seems to state there is no issue with timing. I've never used a GXB block before and I've been working my way through it trying various things to see if I can get it to work. I don't know if putting it in loopback is as simple as I've described or if there's a sequence that I need to follow. And I don't understand the fifo error flag either as timing seems to be ok. Thanks MT

Hi, You reset sequence does not really comply with the handbook. Tx_digitalreset should always really be released first, followed by Rx_analogreset, followed by rx_digitalreset. this is all explained in the handbook and ensures a proper sequence for the Tx and Rx PLLs locking. You do realise that there is already a loopback function in the ALT2GXB right? OK, so it looks like only the serial loopback is available in the XAUI mode but this could make it simpler for you (depending on what you are trying to do. all you need to do is pump in your data into the Tx_datain along with your tx_ctrlenable signals, then simply assert the rx_serialoopback and your transmitted serial data will be looped back to your Rx_datain. you should be able to observe the same data coming out of the Rx_dataout. Hope this helps.

Thanks for the info. I couldn't find any information about the reset order. I read it on some other site and used it. Thanks for clarifying that. Right now, all I want to do just get this link up working with this external switch hence the reason I did the loopback in the core. Unless, there is something missing that isn't in the datasheets, I thought it would be simple enough to tie the tx and rx databuses/ctrl lines in the FPGA core and it should work. Sounds like there is something else that needs to be done here. MT

There is a whole chapter dedicated to Reset control and power down on page 2-214 of the SIIGX Handbook. "Figure 2–160. Reset Power Signal Timing Waveform" gives a typical reset sequence. I would try implementing something like in the diagram I would also then drive signals from your own logic into the tx_datain and associated control signals. then loopback using the conventional loopback method and verify that what you receive on the rx_dataout is the same as what you applied to Tx_datain. If all is wotking then you should see pll_locked, rx_freqlocked, rx_syncstatus all asserted. you should also see occasional rx_patterndetect assertions (assuming your logic sends word alignement patterns etc) and also rx_ctrldetect.

Thanks again. I'm using the Arria and I couldn't find the rest info in that unless there is another version that has it. I'm just downloading the Stratix II GX one. I've noticed with this code (the original code wasn't created by me) that there is a calibration block input which requires a clock between 10MHz and 125MHz, I believe. I traced the clock on the board and it's not connected. Will this cause any problems? MT

I've just read the reset section and I have a few questions: 1. How long is a parallel clock cycle? 2. What does this 'Synchronization' refer to? Is this something that is done by the GXB after reset? "Synchronization is performed after any reset condition. You must determine when the data is valid after reset (for example, by using the rx_syncstatus signal). Table 2–52 shows the blocks affected by each reset and power-down signal." If it is done by the GXB, then I would imagine, after reset, I can't enable loopback in the FPGA until the rx_syncstatus signal is high? 3. In the XAUI interface mode a coreclockout is available which I presume I can use to clock the reset logic? Thanks

ALT2GXB loopback problem | Altera Community

16 Replies

Altera_Forum
Honored Contributor
17 years ago
Using the REFCLK pin will give you optimal jitter performance. you should be able to route this into the PLD for use in your logic. Quartus should choose the optimal clock resources. it will fail fitting if you do anything illegal. just try it.

Rx_Syncstatus (or I believe any of the PLLs) do not have to be asserted in order to enable loopback. Loopback is a diagnostic mode and it wouldnt be very useful if everything had to be synced up prior to it being enabled.
Altera_Forum
Honored Contributor
17 years ago
I thought I would feedback some results. I put the reset logic in and the tx fifo error disappeared. I didn't quite simulate the logic but let's just assume it's working for now.

This next part is not making any sense. If I monitor the rx_freqlocked signal, it's low when the board is powered up. As soon as I connect it to the switch, it goes high. This says that it automatically switched from lock-to-reference mode to lock-to-data mode. In order to make this switch, certain conditions regarding the PLL, voltage levels have to be met.

What I did was to look at the rx_pll_locked signals on all 4 channels (pulled them out to leds). When the board is powered-up, these leds are on indicated that the rx_pll_locked[3:0] are all 0. In other words, the PLL's are not locking on the REFCLK0 which is the clock that I presume they are trying to lock onto.

So, if the PLL's aren't locking onto the REFCLK0, the how is the switch from lock-to-reference mode to lock-to-data mode begin made as the following conditions have to be met:

for automatic transition from the lock-to-reference mode to the
lock-to-data mode, the following conditions must be met:
■ the serial data at the receiver input buffer is within the prescribed
voltage signal loss threshold.
■ the cru pll is within the prescribed ppm frequency threshold
setting (62.5, 100, 125, 200, 250, 300 , 500, or 1,000 ppm) of the cru
reference clock.
■ the reference clock and cru pll output are phase matched (phases
are within approximately 0.08 ui).

Unless I have misunderstood something, I would have expected the rx_pll_locked signals all to be high in the absense of any data coming in on the rx_datain pins.

MT
Altera_Forum
Honored Contributor
17 years ago
Hi,

Just an update and some new issues.

I put a state machine to carry out the reset sequence and I put in the calibration clock in too. But it still doesn't work.

In simulation, I discovered that I had to feed the Rx pins K28.5-, K28.5+, K28.3- and K28.3+ in order to get a '07' (Idle) state out of the rx_dataout port. I could then see this idle state data loop it's way around the Tx side and see some activity on the Tx pins that seemed to make some sense. This was all in simulation. Does this mean that after the reset sequence, the GXB block has to be put into idle state before it will accept data?

However, we've also discovered a problem with the Tx output voltage. It seems to be around -40mv to +40mv. We'eve done all the usual checks on the board with supplies etc. but haven't found a problem. We tried with and without calibration resistors and it does make a difference to the output.

Any idea's will be most welcome.

Regards

MT
Altera_Forum
Honored Contributor
15 years ago
Hi,

I'll try to get some hints within this thread because the content discussed here is close to my problem.
I have an Arria2GX Devkit with the EP2AGX125 FPGA. I try to implement XAUI transceiver using ALTGX, ALTGX_RECONFIG, some user logic an an external loopback adapter at the HSMC A port. The Transceivers GX8, 9, 10, 11 are used for this test.

For the short time it looks good but there are some misalignments an receive side (see attached jpgs).
According the status bits the receiver is synchronized (rx_syncstatus = X"FF") and deskewing is done (rx_channelaligned = '1'). rx_errdetect is also X"00".
Nevertheless the received date are not correct. I have verified the reset sequence, all pll_locks are like in Chapter 4: Reset Control and Power Down in Arria II Devices described.

Every new reset (or FPGA reconfiguration and reset) produces other behavior of the receivers.
The misalignment varies slightly. (2 examples attached)

What could be the problem?

Jens
multiple-attachments.zip1.5 MB
Altera_Forum
Honored Contributor
14 years ago
--- Quote Start ---
Hi,

I'll try to get some hints within this thread because the content discussed here is close to my problem.
I have an Arria2GX Devkit with the EP2AGX125 FPGA. I try to implement XAUI transceiver using ALTGX, ALTGX_RECONFIG, some user logic an an external loopback adapter at the HSMC A port. The Transceivers GX8, 9, 10, 11 are used for this test.

For the short time it looks good but there are some misalignments an receive side (see attached jpgs).
According the status bits the receiver is synchronized (rx_syncstatus = X"FF") and deskewing is done (rx_channelaligned = '1'). rx_errdetect is also X"00".
Nevertheless the received date are not correct. I have verified the reset sequence, all pll_locks are like in Chapter 4: Reset Control and Power Down in Arria II Devices described.

Every new reset (or FPGA reconfiguration and reset) produces other behavior of the receivers.
The misalignment varies slightly. (2 examples attached)

What could be the problem?

Jens
--- Quote End ---

Hi
I am a beginner.
How do we check the "rx_errdetect" signal ? Do we use a oscilloscope ? Or do we use some sub-software in Quartus II to track this "rx_errdetect" signal ?
Thanks
Altera_Forum
Honored Contributor
14 years ago
Hi,

you have to include control and status ports for the XAUI - Megafunction in the Wizard.
(Advanced Options if you are using XAUI Phy Megafunction).
Then you can use SignalTap to check the rx_errdetect signal. SignalTap is an Onchip Logic Analyzer which is accessible from Quartus Tools Menu.

Jens

Forum Discussion

ALT2GXB loopback problem

16 Replies

Recent Discussions

Agilex7 M PCIe MCDMA: debug toolkit attachment

Agilex-5 supported Transceivers

Agilex 5 GTS Supported Protocols

PCIe stuck at reset Agilex5

LVDS Output of FPGA