这实际上是一个非常棘手的问题。
SDI要求每个帧在消隐像素和消隐线的数量方面是相同的。
换句话说，您的串行数据速率必须是像素速率的精确倍数。
因此，当您收到流时，您将以恢复的时钟速率使用它 - 这有效地与发送设备的时钟速率同步。
要向前发送数据而不是累积一些长期漂移，您必须以输入流的比特率正向传输数据。
但是，对于高速收发器，发送器的比特率来自REFCLK - 这是用于收发器的高稳定性时钟。
因此，要将SDI-TX锁定到SDI-RX，您必须将发送器的REFCLK锁定到接收器的恢复时钟。
由于以下几个原因，无法做到这一点：
- REFCLK是收发器的外部引脚 - 您无法从FPGA内部访问它
- （在某些体系结构中，有一种测试模式允许内部连接到REFCLK，但它不能用于用户设计）。
- 来自GT RX的恢复时钟具有太多的抖动，无法用作GT的参考时钟......
所以，有几个解决方案。
第一种（也是最常见的）是使用某种外部时钟元件来产生REFCLK - 这可以是具有极好抖动抑制的外部PLL，可以“清理”恢复的时钟，足以用作REFCLK（编辑：
内部MMCM或PLL不足以完成此任务），或VCXO使用FPGA生成的信息锁定恢复时钟的比特率。
另一种解决方案是使用名为PICXO的东西。
简而言之，GT仍然使用REFCLK作为变送器，但是通过动态重配置端口（DRP）在GT内部使用机制来连续调整输出数据流的相位。
通过不断调整相位，您可以调整输出频率以匹配输入频率（毕竟，如果您每单位时间将相位改变一个恒定的量，则您正在更改频率）。
PICXO解决方案并不一定适用于所有情况 - 它可以补偿的频率有一个上限，并且可能会为输出数据流增加一些抖动。
有关PICXO的信息可以在本应用笔记中找到（将SDI输入转发到输出是此解决方案的示例应用之一）。
Avrum
以上来自于谷歌翻译
以下为原文
This is actually a really tough problem.
SDI requires each frame to be identical in terms of the number of blanking pixels and blanking lines. In other words, your serial data rate must be the exact multiple of the pixel rate.
So, when you receive a stream, you work with it at the recovered clock rate - this is effectively synchronized to the clock rate of the transmitting device.
To send the data forward and not accumulate some long term drift, you must transmit the data forward at
exactly the bit rate of the incoming stream.
However, for a high speed transceiver, the bit rate of the transmitter is derived from the REFCLK - this is the high stability clock that is used for the transceiver.
So, to lock a SDI-TX to the SDI-RX you would have to lock the REFCLK of the transmitter to the recovered clock of the receiver. This can't be done for a couple of reasons:
- REFCLK is an external pin to the transceiver - you cannot access it from inside the FPGA
- (in some architectures there is a test mode to allow internal connections to REFCLK, but it is not to be used for user designs).
- the recovered clock from a GT RX has
far too much jitter to be used as a reference clock for the GT...
So, there are a couple of solutions.
The first (and most common) is to use some kind of external clock component to generate REFCLK - this can be an
external PLL with extremely good jitter rejection that can "clean up" the recovered clock enough to be used as REFCLK (EDIT: the internal MMCMs or PLLs are not sufficient for this task), or a VCXO that uses information generated by the FPGA to lock to the recovered clock's bit rate.
The other solution is to use something called PICXO. In a nutshell, the GT still uses the REFCLK for the transmitter, but uses a mechanism within the GT through the dynamic reconfiguration port (DRP) to continually adjust the phase of the output datastream. By continually adjusting the phase, you can tweak the outgoing frequency to match the incoming frequency (after all if you change the phase by a constant amount every unit of time, you are changing the frequency).
The PICXO solution does not necessarily work in all situations - there is an upper limit to how much frequency it can compensate for, and, presumably, adds some jitter to the outgoing data stream.
Information on the PICXO can be found in this application note (and forwarding an SDI input to an output is one of the example applications of this solution).
Avrum
这实际上是一个非常棘手的问题。
SDI要求每个帧在消隐像素和消隐线的数量方面是相同的。
换句话说，您的串行数据速率必须是像素速率的精确倍数。
因此，当您收到流时，您将以恢复的时钟速率使用它 - 这有效地与发送设备的时钟速率同步。
要向前发送数据而不是累积一些长期漂移，您必须以输入流的比特率正向传输数据。
但是，对于高速收发器，发送器的比特率来自REFCLK - 这是用于收发器的高稳定性时钟。
因此，要将SDI-TX锁定到SDI-RX，您必须将发送器的REFCLK锁定到接收器的恢复时钟。
由于以下几个原因，无法做到这一点：
- REFCLK是收发器的外部引脚 - 您无法从FPGA内部访问它
- （在某些体系结构中，有一种测试模式允许内部连接到REFCLK，但它不能用于用户设计）。
- 来自GT RX的恢复时钟具有太多的抖动，无法用作GT的参考时钟......
所以，有几个解决方案。
第一种（也是最常见的）是使用某种外部时钟元件来产生REFCLK - 这可以是具有极好抖动抑制的外部PLL，可以“清理”恢复的时钟，足以用作REFCLK（编辑：
内部MMCM或PLL不足以完成此任务），或VCXO使用FPGA生成的信息锁定恢复时钟的比特率。
另一种解决方案是使用名为PICXO的东西。
简而言之，GT仍然使用REFCLK作为变送器，但是通过动态重配置端口（DRP）在GT内部使用机制来连续调整输出数据流的相位。
通过不断调整相位，您可以调整输出频率以匹配输入频率（毕竟，如果您每单位时间将相位改变一个恒定的量，则您正在更改频率）。
PICXO解决方案并不一定适用于所有情况 - 它可以补偿的频率有一个上限，并且可能会为输出数据流增加一些抖动。
有关PICXO的信息可以在本应用笔记中找到（将SDI输入转发到输出是此解决方案的示例应用之一）。
Avrum
以上来自于谷歌翻译
以下为原文
This is actually a really tough problem.
SDI requires each frame to be identical in terms of the number of blanking pixels and blanking lines. In other words, your serial data rate must be the exact multiple of the pixel rate.
So, when you receive a stream, you work with it at the recovered clock rate - this is effectively synchronized to the clock rate of the transmitting device.
To send the data forward and not accumulate some long term drift, you must transmit the data forward at
exactly the bit rate of the incoming stream.
However, for a high speed transceiver, the bit rate of the transmitter is derived from the REFCLK - this is the high stability clock that is used for the transceiver.
So, to lock a SDI-TX to the SDI-RX you would have to lock the REFCLK of the transmitter to the recovered clock of the receiver. This can't be done for a couple of reasons:
- REFCLK is an external pin to the transceiver - you cannot access it from inside the FPGA
- (in some architectures there is a test mode to allow internal connections to REFCLK, but it is not to be used for user designs).
- the recovered clock from a GT RX has
far too much jitter to be used as a reference clock for the GT...
So, there are a couple of solutions.
The first (and most common) is to use some kind of external clock component to generate REFCLK - this can be an
external PLL with extremely good jitter rejection that can "clean up" the recovered clock enough to be used as REFCLK (EDIT: the internal MMCMs or PLLs are not sufficient for this task), or a VCXO that uses information generated by the FPGA to lock to the recovered clock's bit rate.
The other solution is to use something called PICXO. In a nutshell, the GT still uses the REFCLK for the transmitter, but uses a mechanism within the GT through the dynamic reconfiguration port (DRP) to continually adjust the phase of the output datastream. By continually adjusting the phase, you can tweak the outgoing frequency to match the incoming frequency (after all if you change the phase by a constant amount every unit of time, you are changing the frequency).
The PICXO solution does not necessarily work in all situations - there is an upper limit to how much frequency it can compensate for, and, presumably, adds some jitter to the outgoing data stream.
Information on the PICXO can be found in this application note (and forwarding an SDI input to an output is one of the example applications of this solution).
Avrum
举报
举报
