to use altlvds,how I can use LVDS bit clock and LVDS frame clock of ADC at the same t

You can only use one clock to clock in the data. My original thought was to use the bit clock to capture the data and the frame signal, and then use the frame signal to word-align the incoming data. The problem is that the frame clock is shifted from the data, so if the capture clock is lined up at the best possible time to capture the data, it is the worst possible time to capture the frame.

Could you ignore the bit clock and just use the frame clock to capture the data? I think the parallel data will come out word aligned. (Does altlvds support x7 deserialization? I don't remember, but that may be an issue)

Thanks, the altlvds support X7 deserialization, we can set the deserialization factor from 1 to 10 in altlvds ip.

My problem is, if only use bit clock in altlvds ip, we can convert the serial data into parallel data, but MSB of each frame data beginning from random bit.

If I use frame clock as altlvds clock input port, the some bits of converted parallel data is error.

Except for altlvds ip, could I use other ip to convert my serial data ?For example, the DDIO_IN ip?

I do not believe the DDIO will close timing at those speeds. altlvds uses a lot of dedicated hardware to make timing closure easier.

If you use frame clock, why are some of the parallel data bits an error? I missed that.

If using the bit clock, I've seen some ADCs that can send a fixed pattern that you can use to calibrate on in logic. A bit of a pain to do though. Capturing the frame transitions and then just shifting the parallel data to align the word would be the easiest.

What about creating two altlvds blocks with external PLL, one to capture the data and one to capture the frame bit. Then have a single external PLL drive both. I think a PLL can drive two altlvds blocks. (Throw something down quickly and make sure it fits before really making sure the clocks are correct and what-not).

The frame line is just a 9th data line that sends a constant value. If you're doing x14 deserialization, then it sends "1111111_0000000." But it looks like x14 is not an option, so you're going to be doing x7. That means the frame data is going to alternate between "1111111" and "0000000".

If you're already using an 8-channel altlvds megafunction, just change it to 9 channel. You also need to select options so that you have the rx_channel_data_align port on the altlvds. This port allows you at ask the altlvds block to change where the word boundary is in the serial stream. Every pulse on this port moves the word boundary by one stream.

The final piece is to write a fairly simple state machine to pulse rx_channel_data_align until you see the frame channel coming out of the lvds block as "1111111" or "0000000." The bit-slip operation applies to all 9 data channels, so once you have the frame pattern aligned, your other 8 data lines are also word aligned.

In summary, the frame "clock" is really just another data line with a known word being transmitted. You can use that knowledge to find the correct word boundary in the serial stream on the other 8 data lines.

Also note, that the frame word also tells you whether you are getting the high 7-bits or low 7-bits. It is "1111111" for one and "0000000" for the other.

--- Quote Start ---

The frame line is just a 9th data line that sends a constant value. If you're doing x14 deserialization, then it sends "1111111_0000000." But it looks like x14 is not an option, so you're going to be doing x7. That means the frame data is going to alternate between "1111111" and "0000000".

If you're already using an 8-channel altlvds megafunction, just change it to 9 channel. You also need to select options so that you have the rx_channel_data_align port on the altlvds. This port allows you at ask the altlvds block to change where the word boundary is in the serial stream. Every pulse on this port moves the word boundary by one stream.

The final piece is to write a fairly simple state machine to pulse rx_channel_data_align until you see the frame channel coming out of the lvds block as "1111111" or "0000000." The bit-slip operation applies to all 9 data channels, so once you have the frame pattern aligned, your other 8 data lines are also word aligned.

In summary, the frame "clock" is really just another data line with a known word being transmitted. You can use that knowledge to find the correct word boundary in the serial stream on the other 8 data lines.

Also note, that the frame word also tells you whether you are getting the high 7-bits or low 7-bits. It is "1111111" for one and "0000000" for the other.

--- Quote End ---

Thanks for you answer, hendryjh. I'm confused about how to frame clock and bit clock, too.

I have some questions about how to set altlvds_rx ip, could you help me?

1, When I choose internal PLL for altlvds_rx, do I need to connect lvds bit clock from A/D converter to the FPGA?

2, In the following sentence, "The final piece is to write a fairly simple state machine to pulse rx_channel_data_align", what does "pulse" mean? Keep rx_channel_data_align to 1 all the time?

3, About "The frame line is just a 9th data line", I can't find it in the Altera's user guide, could you give me some references?

Thanks in advance.

"2, In the following sentence, "The final piece is to write a fairly simple state machine to pulse rx_channel_data_align", what does "pulse" mean? Keep rx_channel_data_align to 1 all the time?"

Pulse here mean a high and low signal instead holding the signal at high always. In other words, in your control, you assert it for certain clock cycle and then de-assert it.

--- Quote Start ---

1, When I choose internal PLL for altlvds_rx, do I need to connect lvds bit clock from A/D converter to the FPGA?

--- Quote End ---

Not necessarily, if you use the frame clock as PLL input clock and multiply it to half the bit rate. I implemented many different LVDS ADC interfaces this way, with 12, 14 and 16 bit width. The phase of the internal generated bit and frame clock can be adjusted for maximal sampling window margin.

--- Quote Start ---

"2, In the following sentence, "The final piece is to write a fairly simple state machine to pulse rx_channel_data_align", what does "pulse" mean? Keep rx_channel_data_align to 1 all the time?"

Pulse here mean a high and low signal instead holding the signal at high always. In other words, in your control, you assert it for certain clock cycle and then de-assert it.

--- Quote End ---

Thanks for your answer, bfkstimchan.

First, I assert rx_channel_data_align, after I receive the right data, I should de-assert the rx_channel_data_align, is my understanding correct?

--- Quote Start ---

Not necessarily, if you use the frame clock as PLL input clock and multiply it to half the bit rate. I implemented many different LVDS ADC interfaces this way, with 12, 14 and 16 bit width. The phase of the internal generated bit and frame clock can be adjusted for maximal sampling window margin.

--- Quote End ---

Thanks, FvM.

If I don't use the frame clock as PLL input clock, but use FPGA's clock as the PLL input clock, can I get the correct data from the A/D converter?

Best regards,

zhangfeng