Honored Contributor
Honored ContributorI 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.
