Forum Discussion
It is not channel to channel skew. I have used these and the (formerly) Fairchild Semiconductor equivalent of this serdes receiver for years: http://www.ti.com/lit/gpn/DS90CR288A They have a pre-programmed data word alignment vs. Rx clock and they assume the channel to channel skew is controlled by length matching PCB trace pairs. My PCB does the same. The issue is that a designer should be able to set the bitslip count at design time rather than run time. All register elements in the FPGA fabric can be configured for set or preset on power up and/or reset. Now that I understand the IP core more completely I'm suggesting Intel does the following: 1) document the word alignment vs. bitslip count with at least one timing diagram and emphasize that not enabling bit slip means that the serial data word is aligned with the rising edge of the data clock. Further, that increasing the bit slip count will effectively right shift (with LSb wrapping to MSb) received bits on the parallel output bus. 2) Add a bit slip setting to the megafunction wizard which presets the bit slip counter when "data_align_reset" is asserted thereby avoiding the need to generate a prescribed number of pulses at runtime.
Beyond this the MAX10 implementation of the Soft LVDS Core is buggy. The gate level RTL simulation model (post fitted, no timing annotation) does not match hardware behavior. My system has two LVDS Rx streams which are generated in the same clock domain within a CycloneV. Each stream is identical except for the data content. In my two identical Max10 receivers, I have to set bitslip to 6 in one of them and 5 in the other on hardware despite simulation of the .vo EDA netlist indicating that bit slip should be set to 5 on both. My point being is that I see buggy behavior in the Max10 LVDS serdes behavior that I do not see when porting the same code to a Cyclone10 for pre synthesis vs. post fitted RTL simulation. Getting timing closure has proven problematic in that I am having to constrain parallel data paths in the Max10 just to keep an internal data bus in sync as it propagates toward a subsequent LVDS transmitter despite having tons of margin on my Fmax. This is more effort than I've had to apply on previous generation devices for similar functionality.