phase problem about transceiver of stratix ii GX

[Altera_Forum]

Hi, I need help for a problem 

 I use transceiver of stratix ii GX for high speed output, and need four channels. The output of transmitters is right, but the phase are different for different channels, which i can understand and handle. But my problem is that when I reboot the FPGA(power off then power on), the phase relationship between channels change.   It looks like everytime I reboot the FPGA, the phase relationship is random.  I can't understand the reason for that.  So can anyone give me some help about the reason and method to solve this problem. I just need to make the phase relationship between channels fixed rather than random.  Thank you

[Altera_Forum]

The behavior is most likely due to the phase compensation FIFO inside the transceiver. They come out of reset at different times. 

 Jake

[Altera_Forum]

Thanks for your reply. Is there any way to solve this problem, how can I make the FIFO reset at the same time? or I can't... 

 Thanks again

[Altera_Forum]

I retract my previous statement. I did not pay close enough attention. You are saying that the individual bits of the serial output are not phase aligned. Is that correct? If so, the behavior is likely caused by the serializer itself. 

 The only way I can think of to remove the skew is to operate the transmitters in bonded mode. Bonded mode is intended to specifically remove that channel-to-channel TX skew. However this imposes certain restrictions which you may not be able to live with in your design.  What mode are you currently operating the transceiver in? Are all of your channels located within the same Quad?  Jake

[Altera_Forum]

I instantiated five transmitter channels using alt2gxb module. Four of them are in the same quad. 

 I don't need to remove the phase difference between channels, I just want to get a fixed difference. Now the situation is like this, say the time difference between the serial output of channel 1 and channel 2 is 4 ns (channel 2 delay 4 ns). if I turn off fpga and reboot it again, this time difference will change to other value, such as 2 ns, and channel 2 may be ahead this time. Every time I reboot FPGA, the time relationship between channels are different, even for the four channel in same quad.  I can understand there are time difference for the output of channels, but I can't understand why this difference change random.  Thanks

[Altera_Forum]

Do you reset the Transceiver (respectively release the reset) after a stable reference clock is present? I would assume this as a prerequisite to achieve predictable timing relations. It may be the case, that Stratix II doesn't provide it anyway.

[Altera_Forum]

I am Dr. David Pommerenk the adviser of Xu Gao, allow me to go into this conversation. 

 Let me add one more piece of information.  We are using the Altera provided Transceiver evaluation board "Stratix II GX Transceiver SI Board" Rev. D. In a deterministic device I do not see a reason why the timing should not come up the same way, every time the device is allowed to wake up from reset.   If we know the reason, we maybe able to correct it in software.   Please advise us on how to proceed.  Regards,  Dr. David Pommerenke

[Altera_Forum]

You are not the first to tackle this problem. A search of the forum will reveal other similar discussions. The problem I believe is that the individual transceiver channels actually have internal reset circuitry. The serializers are coming out of reset at different (random) times. I do not believe you have access to control this. 

 Protocols that require strict channel-to-channel skew requirements typically use bonding.   It sounds like you obviously have control of the receiver as well if you're able to tolerate a fixed skew. Can you implement dynamic phase alignment at the receiver?  Jake

[Altera_Forum]

Here is another thread that explored the same issue ... Presumably also unresolved: 

http://www.alteraforum.org/forum/showthread.php?t=23319  Jake

[Altera_Forum]

we can't implement dynamic phase alignment now, but I believe it is doable. 

 Thank you. Your reply is helpful, I hope I and fix this problem.  Xu

[Altera_Forum]

--- Quote Start ---  Here is another thread that explored the same issue  --- Quote End ---   It seems to suggest, that the feature to achieve a deterministic timing after a reset has been actually forgotten when designing the chip. But to be sure, I would ask Altera support.

[Altera_Forum]

I am currently facing a similar problem but on the RX side: I have to capture data from 10 source-synchronous data flows @2Gbps that must be transferred synchronously from the receivers to the FPGA fabric (in other words, "data lanes" must be aligned). 

 According to SignalTap and when considered individually, each RX is properly aligned with respect to its alignment pattern send by the data source but from one RX to another, the alignments does not occur all together at the same time. There is typically a 1 parallel clock cycle shift between RXs (all located on the same side) but randomly distributed amongst the different RXs from one RX reset (or power-up) to another.  At first, I was suspecting a GXB-FPGA Fabric interface timing failure but after several test, I am 90% convinced that such a behaviour is just..."normal" and due to the latency uncertainty along the RX datapath.  Indeed, when you read carefully the Stratix IV handbook, there is no statement that channels will be "in phase" after reset (even in bonded mode). Indeed, a look at the recovered parallel clock distribution shows that some PCS blocks are clocked by their recovered parallel clock (whatever the clocking scheme is). Thus, at each power-up or FPGA reboot, you can’t have any warranty that the phase comparators of each RX CDRs (i.e. their recovered clocks) will be in the same phase state as previously. Therefore, the received (or transmitted) data that goes through these PCS blocks will not be “in phase” by default but asks for some specific options to be enabled (PLL PFD feedback to compensate latency uncertainty in tx_dataout) or additional control logic in the FPGA fabric.  I have several ideas to solve this problem (from easy to awfully difficult...): 1) Switching the RX CDRs from "automatic lock" mode back to "lock to reference" mode (CDR recovered parallel clocks are more likely to be in-phase as they will have a common reference clock...) 2) Switching the RX phase compensation FIFO in the "register" mode ("enable low latency PCS mode" in the Megawizard) and designing a word aligner within the FPGA fabric 3) Introducing a "lane aligner" in the FPGA fabric prior to deliver recovered data to the processing modules 4) By-passing the RX PCS ("PMA-only" mode) => parallel recovered clock become accessible but word aligner shall be implemented within the FPGA fabric and timing closure may be much more difficult. 5) getting efficient support from ALTERA  6) getting a little more details about the GXB circuitry behaviour from ALTERA  All my above statements concern the RX datapath within StxIV devices only but may probably be applied to the TX datapath of Stx II as well (I haven't studied the TX datapath in detail yet). Don’t you think the latency uncertainty may explain your problem and that you have to put additional logic in the fabric to make sure the TX data are transmitted “in-phase”or rather put your GXB TX instance in “Deterministic Latency” mode or enable the “low latency PCS” option ?  If you have tested some solutions, I’ll be glad to know the end of your story.  Regards.