Forum Discussion
Honored ContributorALTLVDS_RX->LVDS serdes Link Training
Implementing Receiver interface. From transmitter we have 8 LVDS data channel and 1 LVDS sync channel. From sync channel we use to get training pattern which will be available in data channel for link training.
I have used "ALTLVDS_RX" component for each LVDS data channel and sync channel (9's ALTLVDS_RX). I have query that how to do the link training? In ALTLVDS_RX i have observed that we have "rx_data_align" which will be input port after making tick while generating component. So, from where this input is controlled or generate. What mechanism or logic is required for this, if it will resolve our bit align/ bit slip for link training. Else what we need to do for this....:confused::confused::confused:25 Replies
Altera_Forum--- Quote Start --- I assume it is merging the PLL for each altlvds_rx instance, so they are all driven by a single PLL and all aligned. (If they each required their own PLL, it would not fit.) --- Quote End --- Hello Rysc, If i have three seperated ADC(LVDS output type) processed by FPGA, can i merge all of them into one altlvds_rx module? Best Regards- Altera_Forum
576 Mbps can be met by all speed grades. Look at the fHSDR spec, which is 875Mbps, 850 and 640 for the different speed grades. Note that the sampling window is 350ps for each one, which means the data only needs to be stable around the clock edge for 350ps. (Other reasons limit the Fmax, since 350ps is technically ~2.8G) Use the altlvds_rx IP with deserialization of 8 and you'll be fine. (There are board layout restrictions since this uses dedicated hardware, specifically a dedicated clock tree from the PLL to the IO to guarantee low skew and ODV). Your system may not even need word alignment(if the words are spread across each channel, so each cycle is a new word, then you're good.) There are a few other cases. But let's say each channel is bringing in its own 8 bit word, so when it's deserialized the output may not be word aligned. You will need to rx channel data align to slip it. (I've seen user's do this in logic too, but no need to)
- Altera_Forum--- Quote Start --- Agreed. I assumed the OP was using a high-speed image sensor because he mentioned a sync channel. I've been working with high-speed image sensors for many years now and most of them come with shockingly incomplete data sheets. I designed one sensor interface without DPA but I didn't do it by closing timing. That would have been impossible due to lack of detailed enough timing specs in the sensor data sheet. Instead I designed a state machine that performed a bit timing calibration by cycling through all 8 phases of the sampling clock and observing the parallel data out of the ALTLVDS_RX blocks to determine the optimal clock phase for sampling the data. The timing would drift during operation and we would start getting errors, so ended up having to re-calibrate the interface every video frame during the dead time between frames. --- Quote End --- You could be quite right, I overlooked the Sync channel, which very probably indicates the OP is interfacing to an image sensor. The OP could use the input buffer dynamic delay chain in Cyclone V to align the incoming data-stream.
- Altera_Forum--- Quote Start --- It rather depends on the transmitting device. Unfortunately the OP didn't tell us what device it is. I have closed 600 Mbps in Cyclone II, the source devices were TI octal ADCs using a home-made deserialiser. Here is an image of the board with 16 ADCs:http://c-cam.be/images/img_7.jpg --- Quote End --- Agreed. I assumed the OP was using a high-speed image sensor because he mentioned a sync channel. I've been working with high-speed image sensors for many years now and most of them come with shockingly incomplete data sheets. I designed one sensor interface without DPA but I didn't do it by closing timing. That would have been impossible due to lack of detailed enough timing specs in the sensor data sheet. Instead I designed a state machine that performed a bit timing calibration by cycling through all 8 phases of the sampling clock and observing the parallel data out of the ALTLVDS_RX blocks to determine the optimal clock phase for sampling the data. The timing would drift during operation and we would start getting errors, so ended up having to re-calibrate the interface every video frame during the dead time between frames.
- Altera_Forum--- Quote Start --- If you can close static timing then bit alignment is not needed - it's already done. If you can do that at 576Mbps you're a better engineer than I am! --- Quote End --- It rather depends on the transmitting device. Unfortunately the OP didn't tell us what device it is. I have closed 600 Mbps in Cyclone II, the source devices were TI octal ADCs using a home-made deserialiser. Here is an image of the board with 16 ADCs:http://c-cam.be/images/img_7.jpg (http://c-cam.be/images/img_7.jpg)
- Altera_Forum
If you can close static timing then bit alignment is not needed - it's already done. If you can do that at 576Mbps you're a better engineer than I am!
- Altera_Forum
Device -> Cyclone V:5CGTFD7D5F27C7
Data Rate -> 576 Mbps Deserialization Factor -> 8 Device Speed Grade -> Any/6(Fastest) Rsync agree with you but rsefton mentioned bit & word alignment. In my previous response i told "rx_channel_data_align" is used to handle for bitslip if parallel data is not matched with training pattern. SO, i think both alignment will be taken care by ALTLVDS_RX by using "rx_channel_data_align". What is your opinion? - Altera_Forum
DPA is not supported in Cyclone V. I somewhat disagree with rsefton on how great DPA is. It is absolutely required for really high speeds, but it has the drawback that each lane does its own alignment, and so two lanes can be off from each other by a bit period or so. With regular LVDS you have to close timing, but once you do you know that each channel is aligned with the other channels, since the data is synchronously clocked in. What is your data rate? Assuming it's within the max LVDS rx data rate in the datasheet, you should be good to go. The altlvds block has really good timing numbers and should work with any device meant to run at that rate. The only thing you really need to watch out for is to make sure you know if the clock coming in is edge-aligned(in which case the altlvds will do a 90 degree phase shift on it to put it in the center of the data eye) or center aligned(in which case it doesn't do a shift and maintains that relationship, since it is already in the middle of the data eye). Otherwise it should work right out of the box.
What's your data rate, deserialization rate, and device speed grade? - Altera_Forum
I am using Cyclone V:5CGTFD7D5F27C7 device. I am not able to make make ALTLVDS_RX's DPA setting enabled. Then what logic need to implement to take care for bit alignment? What will be output of ALTLVDS_RX for 8 bit parallel data? That will be not bit aligned from incoming serial data? Please let me know what else need to do to make work in non-DPA Rx mode? If DPA setting is disable in Device, can we consider that DPA is supported default.
- Altera_Forum
There are two phases to aligning an interface like this, bit alignment then word alignment. Bit alignment involves finding the serial data transitions and establishing the optimal clock phase for sampling the data (sampling in the center of the eye). DPA does this for you automatically if you enable it. If you don't enable DPA then you have to find your own solution for bit alignment.
Once bit alignment is complete then you start word alignment. Word alignment involves doing bitslips on each channel one at a time until the parallel data out of that channel matches the expected training word value. This is what "rx_channel_data_align" is used for. The word alignment process is very simple. Bit alignment is much trickier without DPA and you've made no mention of bit alignment. As I said in my previous post, if DPA is supported in the device family you're using then it will make your task much simpler and your design much more robust if you enable DPA.
