科林,
如果你不关心绝对阶段,那就没有问题。
IBUF,专用时钟引脚路由具有受控的已知延迟(对于工具),并且使用常规结构互连的通用IO引脚将具有比专用路由更多的延迟,但实际上没有性能差异
。
确实,如果您使用常规互连进行所有时钟路由,则可能会有更多抖动,但是从IOB到最近的全局缓冲区访问点(或DCM)的短路径不足以引入抖动。
通过为DCM反馈路径选择相同的资源,您实际上可以补偿变化。
这可能需要在FPGA_editor中手动放置hte路由,但可以提供更好的解决方案(需要花费一些时间和精力,以及将来的可维护性)。
您将收到警告或多个警告,您可能会忽略这些警告。
延迟将随着过程(芯片到另一个芯片),电压和温度而变化;
但是,它也会为IBUF做到这一点。
将BUFG用于DCM反馈旨在弥补这一点。
如果您没有将性能推得太远,您将能够选择固定的延迟采样点。
否则,您将需要一种训练序列,以找到每块电路板的最佳采样点,如果电压/温度发生变化,可能需要重新校准(就像在高速时对DDR存储器设备所做的那样)。
Austin Lesea主要工程师Xilinx San Jose
在原帖中查看解决方案
以上来自于谷歌翻译
以下为原文
Colin,
If you do not care about absolute phase, then there is no problem.
The IBUF, dedicated clock pin route has a controlled, known delay (for the tools), and a general IO pin, using hte regular fabric interconnect will have a delay that varies more, but is really no different in performance, than the dedicated route.
It is true that if you used regular interconnect for all of your clock routing, you could have more jitter, but the short path from IOB to the nearest global buffer access point (or DCM), is not enough of a span to introduce jitter. By choosing the same resources for the DCM feedback path, you may actually compensate for the variations. This may require hand placement of hte routes in FPGA_editor, but could provide a better solution (at some cost of time and effort, and future maintainability).
You will get a warning, or more than one warning, which you may ignore.
The delay will change with process (chip to another chip), voltage, and temperature; but then, it would do so for the IBUF as well. The use of the BUFG for the DCM feedback is designed to compensate for this. If you are not pushing the performance too far, you will be able to choose a fixed delay sampling point. Otherwise you will have to have a sort of training sequence to find the best spot to sample for each board, and perhaps re-calibrate if the voltage/temperature changes (like what is done for the DDR memory devices at very high speeds).
Austin Lesea
Principal Engineer
Xilinx San JoseView solution in original post
科林,
如果你不关心绝对阶段,那就没有问题。
IBUF,专用时钟引脚路由具有受控的已知延迟(对于工具),并且使用常规结构互连的通用IO引脚将具有比专用路由更多的延迟,但实际上没有性能差异
。
确实,如果您使用常规互连进行所有时钟路由,则可能会有更多抖动,但是从IOB到最近的全局缓冲区访问点(或DCM)的短路径不足以引入抖动。
通过为DCM反馈路径选择相同的资源,您实际上可以补偿变化。
这可能需要在FPGA_editor中手动放置hte路由,但可以提供更好的解决方案(需要花费一些时间和精力,以及将来的可维护性)。
您将收到警告或多个警告,您可能会忽略这些警告。
延迟将随着过程(芯片到另一个芯片),电压和温度而变化;
但是,它也会为IBUF做到这一点。
将BUFG用于DCM反馈旨在弥补这一点。
如果您没有将性能推得太远,您将能够选择固定的延迟采样点。
否则,您将需要一种训练序列,以找到每块电路板的最佳采样点,如果电压/温度发生变化,可能需要重新校准(就像在高速时对DDR存储器设备所做的那样)。
Austin Lesea主要工程师Xilinx San Jose
在原帖中查看解决方案
以上来自于谷歌翻译
以下为原文
Colin,
If you do not care about absolute phase, then there is no problem.
The IBUF, dedicated clock pin route has a controlled, known delay (for the tools), and a general IO pin, using hte regular fabric interconnect will have a delay that varies more, but is really no different in performance, than the dedicated route.
It is true that if you used regular interconnect for all of your clock routing, you could have more jitter, but the short path from IOB to the nearest global buffer access point (or DCM), is not enough of a span to introduce jitter. By choosing the same resources for the DCM feedback path, you may actually compensate for the variations. This may require hand placement of hte routes in FPGA_editor, but could provide a better solution (at some cost of time and effort, and future maintainability).
You will get a warning, or more than one warning, which you may ignore.
The delay will change with process (chip to another chip), voltage, and temperature; but then, it would do so for the IBUF as well. The use of the BUFG for the DCM feedback is designed to compensate for this. If you are not pushing the performance too far, you will be able to choose a fixed delay sampling point. Otherwise you will have to have a sort of training sequence to find the best spot to sample for each board, and perhaps re-calibrate if the voltage/temperature changes (like what is done for the DDR memory devices at very high speeds).
Austin Lesea
Principal Engineer
Xilinx San JoseView solution in original post
举报