OSERDES2间歇性地工作

嗨，
我们遇到了Spartan 6 LX45 -3设备的问题。
在我们的设计中，我们基本上有一些图像处理算法和许多视频接口。
我们在HDMI / DVI输出方面存在一些问题，该输出间歇性地工作。
当用示波器探测时，HDMI引脚，时钟和数据信号周期性地停留一段时间（按十分之一秒的顺序），然​​后重新开始切换。
我们遵循XAPP1064建议来实现HDMI输出：在我们的设计中，我们有3个时钟，x1，x2和x10 w.r.t.
像素时钟。
这些由可编程PLL（与DRP接口结合使用）提供;
x2时钟（CLKOUT1）通过BUFG缓冲并连接到OSERDE2 CLKDIV输入，而x10时钟（CLKOUT0）通过BUFPLL缓冲并转发到CLK0。
BUFPLL的SERDESTROBE连接到IOCE，LOCK用作OSERDES的异步复位.serdes_n_to_1_s16_diff模块用于实例化输出逻辑。
有趣的是，我们注意到PLL始终处于锁定状态（通过ChipScope验证，并且使用同一PLL提供的时钟信号的其他视频输出正常工作）。
更有趣的是，可以使用所有视频配置（具有25,40和108 MHz像素时钟）复制不良行为，但并不总是存在：也就是说，当我们更改视频模式时，一旦PLL锁定，输出就可以开始显示问题
或不。
当问题不存在时，视频可以正常工作，直到下一次模式更改。
设计中的时钟信号受到适当约束，实现后不会报告时序违规。
我们假设我们在视频输出威廉希尔官方网站 上缺少一些约束（可能与OSERDES2有关）。
有人曾经经历过类似的事吗？
我们一直在william hill官网 中搜索一段时间，但我们没有找到任何有类似问题的人。
问候，
斯特凡诺



以下为原文

Hi,
we're experiencing problems with a Spartan 6 LX45 -3 device. In our design we basically have some image processing algorithms and many video interfaces. We've some issue with the HDMI/DVI output, which is working intermittently. When probing with an oscilloscope the HDMI pins, clock and data signals cyclically stuck for a while (in the order of some tenth of second) and then restart switching.

We followed XAPP1064 recommendations for implementing the HDMI output: in our design we have 3 clocks, a x1, x2 and x10 w.r.t. pixel clock. These are provided by a programmable PLL (used in conjunction with a DRP interface); x2 clock (CLKOUT1) is buffered with a BUFG and connected to OSERDE2 CLKDIV inputs, while x10 clock (CLKOUT0) is buffered with a BUFPLL and forwarded to CLK0. BUFPLL's SERDESTROBE is connected to IOCE and LOCK is used as asynchronous reset for the OSERDES. serdes_n_to_1_s16_diff module is used as is for instantiating the output logic.

Interestingly we've noticed that PLL is always locked (verified with ChipScope and by the fact that other video outputs, which use clock signals provided by the same PLL, are working correctly). Even more interestingly the bad behavior can be replicated with all video configurations (with 25, 40 and 108 MHz pixel clock) but is not always present: that is, when we change video mode, once PLL has locked the output can start manifesting the problem or not. When the problem is not present, video works correctly , forever until next mode change.

Clock signals in the design are properly constrained, and no timing violation is reported after implementation. We suppose we're missing some constraint on the video output circuit (maybe something related to OSERDES2). Has someone ever experienced something similar? We've been searching for a while in the forum but we didn't find anyone with a similar issue.

Regards,

Stefano