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 --- 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--- 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 --- 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
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 --- 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--- Quote Start --- Why build 9 separate instances? You can build one ALTLVDS_RX instance with up to 64 channels. Much easier to work with one module, especially when it comes to alignment. And if you're in a family that supports DPA I highly recommend using it. DPA takes care of the bit alignment for you and it then tracks alignment continuously during run-time. If you don't use DPA then you have to do bit alignment yourself. I've done it - it's not that complicated. But then the alignment is static. Checking alignment manually during run-time is normally difficult to do because you have to switch back into training mode. DPA is definitely the way to go if you have the option. I'm not sure I answered your questions but if not then let me know and I'll take another crack at it. --- Quote End --- Hi rsefton, I want to process three ADC devices, which output LVDS data lines. Can i conbine these 3 ADC outputs into one ALTVLDS_RX module? My devcie can enable DPA. Regards
- Altera_Forum
That is another big benefit of DPA. Since each channel aligns itself, you can use a single PLL for all three interfaces.
- Altera_Forum--- Quote Start --- That is another big benefit of DPA. Since each channel aligns itself, you can use a single PLL for all three interfaces. --- Quote End --- Hi Rysc, Thanks for you reply. Do I need to match the trace lines' length equeal among the 3 ADC output LVDS signals outside the fpga? Or just make the ADCs sampling clock traces equal lengh? Best Regard
- Altera_Forum
With DPA, each channel is dynamically captured, so no matter what your trace length is, you will get clean data. The problem is that the data from adjacent channels is not necessarily aligned, so the closer your trace lengths the less difference there will be when entering the fabric.
- Altera_Forum--- Quote Start --- With DPA, each channel is dynamically captured, so no matter what your trace length is, you will get clean data. The problem is that the data from adjacent channels is not necessarily aligned, so the closer your trace lengths the less difference there will be when entering the fabric. --- Quote End --- Hi Rysc, Thanks for you reply quickly. 1. For i want to combine 3 ADC chips output into one alt-lvds receiver module, i have chose one of these 3 ADC chips DCO to feed into fpga. Do you think which one selected is better, or anyone is ok? 2. In order to save LVDS RX pins, can i only connect one of three FCO into fpga? Even i have enough lvds-rx pins to reciever all three fco, i just want to know if i can combine more than 3 ADC chips into one alt-lvds reciever module. Best Regard
