A question of time

Current fpgas and highly integrated processors generally support a range of high speed interface standards, many of which are LVDS based or which can be configured to LVDS. These interfaces can be used to implement multiple gigabit per second data links. However, as data rates and link lengths keep increasing, practical implementations of these links may require alternative architectures. Common LVDS type links will run out of steam at data rates of more than 1.5 to 2Gbit/s. Techniques like pre emphasis at the transmit side and equalisation at the receiving end will help keep signal integrity up, but they will go only so far. For higher bandwidths, it may be better to move to a higher speed physical layer, such as current mode logic (CML). Many designs opt to spread data over multiple lanes, effectively using several high speed links to implement the link. Common implementations are the well known FPD-Link type of interfaces. Here, multiple data lanes and a single clock lane are used to transfer the payload. A common issue associated with this architecture is the data to clock skew. By definition, one cannot have too much skew between each data and the clock link. This requires careful layout and design, especially if there are many data links. At higher data rates, it limits the maximum cable length. A more design friendly implementation with respect to skew tolerance – hence ease of layout – would be to use a single data link with the clock embedded in the data stream. By definition, embedding the clock into the data stream eliminates any skew, simplifies layout and eases cable selection criteria. Still, there are architecture issues associated with embedded clock links that have, until now, limited the widespread use of embedded clock interfaces. For instance, high performance single channel embedded clock links will require a high performance PLL on the receiving side to be able to extract the clock. Many receiver solutions require a reference clock with a tight tolerance around the receive data rate frequency. This is needed for the PLL to be able to lock to the receiving data. Often, it is undesirable to have a reference clock on the receiving side; not just because of the cost associated with it, but also because having a reference clock inherently means the receiver is built for a specific data rate. What if you do not know the data rate of the incoming data? A good example would be a display link. Depending on image resolution, the actual data rate may vary quite a bit. A limited PLL lock range will prohibit any display resolution change.