I am using the altlvds_rx core of altera to make a video deserializer in an FPGA. I have implemented the design and it is now running on my board. However, it looks like I have a timing problem. Recently I noticed that specifying a Tsu and Tho for the LVDS pairs changes the behavior. Has anybody used the altLVDS core and can you tell me if it is necessary to add constarints for this core:
- tSU and tHO? To which clock should these values be referenced?
Yes, I've used the this MegaWizard core many times, I've even built my own. If the skew (board + cable) & jitter (transmitter) between the clock and data lanes is tight you typically don't have to do anything with setup and hold times--the MegaWizard takes care of all the important timing under the hood. What is your 1x clock frequency and deserialization factor?
What do you mean when you say "it looks like I have a timing problem?". Does the transmitter have the ability to send a test pattern? I've found the best way to test these types of interfaces is to use a known pattern. Debugging timing on this interface with a unknown changing input will cause you to pull your hair out.
Thanks for the information. I want to decode the data coming from a THine THC63LVD823. This chip sends dual link video data. Each link has its own clock. In my FPGA I instantiate two altLVDS cores. The clock of such a link is 70MHz. The deserialization factor is 7. This clock is edge-aligned with the data.
I am testing my design with a video source that generates a known resolution. In my FPGA I can check the resolution that I receive from the altLVDS core by reading some registers. Sometimes this resolution is good, sometimes it isn't (it looks like I am not clocking the data at the correct moment).
Maybe I should try to find a valid window by changing the clock alignment?
You should determine what your data valid window will be given the variance in the bit positions of the THline part, its out clock jitter, and the Cyclone2's setup and hold times. At 490MHz (speed of the serialized lane) your period is approx 2ns. This is a respectable speed for a CycloneII part.
I would also check the output clock skew between the two links of the dual video, coming from the THline device. The skew could be large enough that your design might have to implement a FIFO to correctly align the data coming from your two alt_lvds cores.
These Tsu times are expected to be different, but slightly . Your TA1 and TA2 number jump out as suspicious to me. The reason these Tsu times are different is because the path delays (either pin to register or clock path) will be slightly (on the order of 10's of ps) different.
A better representation of Tsu on this input register would be to subtract the pin to register delay from the reported Tsu. Depending on the transmitter (THline) output clock jitter, bit position variance, and board trace skew, you might have to tune the Tsu time by adjusting the phase delay of the PLL, which will change the time the latch edge triggers the input register.
This definitely calls for a Tsu constraint. Cyclone II devices have programmable input delay chains (in order to make Tsu/Th tradeoffs), and it looks like these chains have been set to 0 on TA, and to 7 on the other ones.
You can find the actual Input Delay Chain values if, in the compilation report, you for to the fitter report, Resource section, and then expand the "Input pins" section. It's in one of the columns there.
I find that Quartus by default (i.e. unconstrained) sets only one bit in a bus with delay tap 0 and the rest at 7. It's not really a Quartus 'bug', according to someone at Altera - the mismatch is there in order to show up and remind people to constrain their input buses...
I suggest you set Tsu for these inputs to 0.4ns and recompile. You may get some errors, but at least the delay chain will be set to 0. Then raise the Tsu to a little more than the largest Tsu you find after the initial compilation and you should be all set.
Thanks for the information. After struggling with the core I have developed my own core (I allready had an LVDS deser for Xilinx, I rewrote it for Altera). I used the "Input Delay from Pin to Input Register" constraint to set all input delay chains to "0". After adding this constraint all LVDS pins have nearly similar tSU and tH. The best news is that the design works nice.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.