如何对待我的DDR输入时钟？

woko写道：
真的很难猜，嗯？
你是对的，可以使用更低的费率和更多的车道。
但目前我们的空间非常有限，而且我们在未来的设计中需要更多的吞吐量，因此我们希望保持设计的可扩展性。
这就是为什么我现在想坚持使用ISERDES组件。
当然合理，但要考虑最终结果吞吐量。
来自传感器的数据必须在某处，因此您无法以比吸入数据更快的速度运行传感器。
我想如果你现在需要工作，你应该坚持使用IDDR而不用担心ISERDES。
如果您的日程安排允许玩ISERDES，那么当然可以。
因此，bitlip机制只告诉ISERDES哪个位先到哪个位？
基本上，是的。
反序列化的单词会显示给您，您显然希望数据MSb位于MSb位置。
bitlip过程安排这一点。
这意味着可以在结构中运行的简单FSM中控制bitlip信号，从传感器处查找正确的“IDLE”字。
一旦发现这个，我不再需要为bitlip烦恼了吗？
是的，就是这样。
您的状态机监视每个反序列化的字，如果它与训练模式不匹配，则为一个CLKDIV断言BITSLIP信号，然后再次查看并行字，并继续执行直到匹配。
除非您更改传感器的运行方式，否则您不需要为此烦恼。
但是当传感器没有读出时，仍然值得监视空闲模式，所以如果它确实失去了理智，你可以尝试恢复。
话虽如此，我从未见过传感器在正常操作期间失去理智。
但比抱歉更安全。
我是否需要使用IDELAY2在Clk和数据线之间进行相位校正才能获得干净的采样点？
我发布的实现1:10 serdes的方法是否正确？
我没有在Spartan 6中对这个传感器进行接口，所以我不能告诉你。
但我的猜测是你应该使用相位检测器。
----------------------------是的，我这样做是为了谋生。
在原帖中查看解决方案



以下为原文

woko wrote:
Really hard to guess, hm?
You're right, it would be possible to use lower rates and more lanes. But at the moment we are really limited in space and furthermore we need much more throughput in a future design, so we want to keep the design scalable. Thats why I want to stick at the ISERDES components for now.

Reasonable, of course, but consider your end-result throughput. The data from the sensor's gotta so somewhere, so you can't run the sensor any faster than you can suck in the data.
 
I suppose that if you need to get something working NOW you should just stick with the IDDR and not worry about the ISERDES. If your schedule allows for playing with the ISERDES, then of course do it. 

So, the bitslip mechanism is only telling the ISERDES which bit comes first and which last?

Basically, yes. The deserialized word is presented to you and you'd obviously like the data MSb to be in the MSb position. The bitslip process arranges for that. 

That means the bitslip signal can be controlled in a simple FSM running in the fabric, looking after the correct "IDLE" word from the sensor. Once this is found, I don't need to bother about the bitslip anymore?

 Yup, that's it. Your state machine monitors each deserialized word, and if it doesn't match the training pattern, you assert the BITSLIP signal for one CLKDIV, then you look at the parallel word again, and keep doing it until you match.
 
You shouldn't need to bother with it, unless you change how the sensor operates. But it's still worth monitoring the idle pattern when the sensor isn't reading out, so if it does lose its mind you can attempt to recover. Having said that, I've never seen the sensor lose its mind during normal operation. But better safe than sorry.
 

• Do I need phase correction between Clk and Data lines with an IDELAY2 to achieve clean sampling points?
  
• Is the approach I've posted for achieving 1:10 serdes correct? 
  

I didn't do my interface to this sensor in the Spartan 6 so I can't tell you. But my guess is that you should use the phase detector.
----------------------------Yes, I do this for a living.View solution in original post

XAPP正试图解决两个问题。
重要的是要清楚它们是什么。
首先是在1050Mbps时数据眼图太小而无法静态捕获。
因此，XAPP正在尝试使用IDELAY和ISERDES捕获它自己的时钟来进行一些动态校准。
第二个是框架;
当并行数据转换为串行时，“哪个N位形成一个字”的分组将丢失。
从您的帖子来看，您似乎正在尝试以480Mbps /引脚（240MHz DDR）捕获10位并行总线。
要做到这一点，你绝对不需要这个解决方案的第二部分，你可能甚至不需要第一部分。
让我们来处理第二部分。
您的数据宽度为10位，每个时钟周期有一个数据。
这与串行数据进入时有根本的不同，在这种情况下，您必须将串行流的“正确”N位“重新分组”回一个字。
这就是“bitlip”的全部内容 - 找到N个连续样本的正确分组以重新形成单词。
你不这样做 - 一个引脚上的每个样本都是一个字的一位 - 该字明确地通过N条不同的线（在这种情况下为10）传输。
所以所有这些“bitlip”的东西都不适用于你的情况。
第一部分也可能是不必要的（或可能不是必要的）。
您只运行240MHz DDR，即2.08ns单位间隔（每位时间）。
这可能足以静态捕获。
但是，要弄清楚它是否存在，您将需要进行大量分析。
Spartan-6有许多静态捕获数据的机制。
您可以通过BUFIO2，DCM或PLL驱动时钟。
根据零件和速度等级（Tpscs / Tphcs，Tpsdcm0 / Tphdcm0和Tpspll / Tphpll分别为 - 显示数字的Spartan-6数据表 -  DS162），每个设置对设置和保持的要求略有不同。
根据零件和速度等级，这些组合中的一些需要不到2ns的可靠捕获。
如果CMOS传感器在时钟和数据之间提供非常紧密的偏斜，并且您的电路板跟踪非常匹配，则可以静态捕获此窗口。
如果是这样，那么您不需要打扰XAPP的任何一个方面。
对于结构方面，您可以查看这篇文章，尽管它适用于Virtex-6。
与Spartan-6有一些重要的区别 
- 没有MMCM  - 你只有PLL和DCM 
-  DCM可以进行精细的相移（如MMCM），但PLL只能进行粗略的相移 
- 尽管PLL时钟接口所需的时序窗口略小 
-  Spartan-6中的IDELAY未校准 - 这需要在XAPP1064中进行动态校准等操作
除非Tpscs / Tphcs完全适合您的计时（这是非常不可能的），否则芯片同步时钟不会对您有效。
至于PLL或DCM  - 取决于确切的时序，一个可能比另一个略好 -  DCM对其相位具有更大的可调性（CLKPER / 256 = 16.3ps），而PLL具有更大的粒度（1 / FVCO /
8 = 130ps：假设VCO频率为960MHz），但PLL时钟需要大约200ps的小窗口......
为了计算边距，你将不得不进行类似于这篇文章的分析，但这是针对K7，仅用于芯片同步分析 - 但基本原理是相同的。
您需要修改时钟/数据关系 
- 在芯片同步（Tpscs / Tphcs）中，你可以通过调整IDELAY来实现 
- 这适用于7系列或Virtex设备，因为IDELAY已经过校准 - 它在Spartan-6中不起作用 
- 在PLL或DCM时钟交互（Tpspll0 / Tphpll0或Tpsdcm0 / Tphdcm0）中，您可以使用PLL / DCM的相移功能调整时钟相位。
如果所有这些解决方案中的边距都小于0，那么您将不得不进行动态校准。
您可能最终使用XAPP1064中的部分机制，或使用DIFF_PHASE_DETECTOR模式（可能与XAPP1064正在执行的操作相同）的Spartan-6选择I / O用户指南（UG381）中描述的机制。
但即使在这种情况下，你只是做动态眼睛发现部分 - 而不是bitlip框架部分。
Avrum



以下为原文

The XAPP is trying to solve two problems. Its important to be clear what they are.
 
The first is the fact that at 1050Mbps the data eye is too small to capture statically. Therefore the XAPP is doing some dynamic calibraton by trying to capture it's own clock using an IDELAY and an ISERDES.
 
The second one is framing; when parallel data is converted to serial, the grouping of "which N bits form a word" is lost.
 
From your post, it seems that you are trying to capture a 10 bit parallel bus at 480Mbps/pin (240MHz DDR). To do this, you definitely don't need the 2nd part of this solution, and you may not even need the first part.
 
Lets deal with the 2nd part. Your data is coming at 10 bits wide, with one datum each clock period. This is fundamentally different than when serial data is coming in, where you have to "re-group" the "correct" N bits of the serial stream back to a word. That is what the "bitslip" is all about - finding the correct grouping of N consecutive samples to re-form the word. You don't do that - each of your samples on a pin is one bit of one word - the word is explicitly carried over N different wires (10, in this case). So all this "bitslip" stuff doesn't apply to your situation.
 
The first part may also be unecessary (or may not be unecessary). You are only running 240MHz DDR, thats a 2.08ns unit interval (time for each bit). This might be big enough to capture statically. However, to figure out if it is, you are going to need to do a LOT of analysis. The Spartan-6 has a number of mechanisms for capturing data statically. You can drive the clock through a BUFIO2,  a DCM, or a PLL. Each of these has slightly different requirements for setup and hold, depending on part and speed grade (Tpscs/Tphcs, Tpsdcm0/Tphdcm0 and Tpspll/Tphpll respectively - look a the Spartan-6 datasheet for the numbers - DS162).
 
Some of these combinations require less than 2ns for reliable capture, depending on part and speed grade. If the CMOS sensor provides very tight skew between the clock and data, and your board traces are very well matched, then it may be possible to capture this window statically. If so, then you don't need to bother with either aspect of the XAPP.
 
For the structural aspect you can look at this post, although it is for a Virtex-6. There are some important differences with the Spartan-6
  - there is no MMCM - you only have the PLL and DCM
  - the DCM can do fine phase shifting (like the MMCM), but the PLL can only do coarse phase shifting
    - although the timing window required by a PLL clocked interface is slightly smaller
  - the IDELAY in Spartan-6 is not calibrated - which necessitates things like the dynamic calibration done in XAPP1064
 
Unless the Tpscs/Tphcs falls in exactly the right place for your timing (which is very unlikely), then the chip-sync clocking is not going to work for you statically.
 
As for the PLL or DCM - depending on the exact timing, one may be slightly better than the other - the DCM has more adjustability to its phase (CLKPER/256 = 16.3ps), whereas the PLL has larger granularity (1/FVCO/8 = 130ps : assuming a 960MHz VCO frequency), but the PLL clocking requires about 200ps smaller windows...
 
For figuring out the margins, you will have to do an analysis similar to this post, but this is for a K7, and only for Chip-sync analysis - but the basics are the same. You need to modify the clock/data relationship
  - in chip-sync (Tpscs/Tphcs) you do it by adjusting the IDELAYs
    - this works in a 7 series or Virtex device because the IDELAYs are calibrated - it doesn't work in Spartan-6
  - in PLL or DCM clocked interaces (Tpspll0/Tphpll0 or Tpsdcm0/Tphdcm0) you adjust the clock phase using the phase shifting capabilities of the PLL/DCM.
 
If the margins turn out to be less than 0 in all these solutions, then you will have to do dynamic calibration. You may end up using part of the mechanism in XAPP1064, or the mechanism described in the Spartan-6 Select I/O User Guide (UG381) using the DIFF_PHASE_DETECTOR mode (which may be the same as what XAPP1064 is doing). But even in this case, you are only doing the dynamic eye finding part - not the bitslip framing part.
 
Avrum

avrumw写道：
从您的帖子来看，您似乎正在尝试以480Mbps /引脚（240MHz DDR）捕获10位并行总线。
要做到这一点，你绝对不需要这个解决方案的第二部分，你可能甚至不需要第一部分。
嗨avrumw，
非常感谢您的详细解答。
不幸的是，你在这里弄错了。
在我的帖子中，我写道“传感器输出2路LVDS 10位数据，480MHz和LVDS DDR时钟”，并附有时序图。
但显然，这还不够清楚，对不起。
同样，传感器可以使用多达16个LVDS输出来传输数据。
在我们的例子中，由于不同的原因，我们只使用其中的2个。
无论使用多少数据通道，传感器都使用另一个LVDS对输出DDR时钟。
此外，具有同步信号和其他信息的“控制和调试通道”输出到另一个LVDS对。
数据和控制通道的运行频率为480MHz（DDR时钟频率为240MHz）。
配置传感器以使用更多LVDS通道作为输出将提高定时性能。
它只需要更少的时间来读出一帧，因为然后更多的像素被并行读出。
但是，逐个读出一个像素的机制当然是真正的序列化。
我附上了另一张图片，希望能够描述使用1个以上的LVDS数据输出。
好吧，我得到的是一个DDR时钟，我必须使用它来反序列化2 + 1 LVDS通道，我的问题是如何调整XAPP1064，因为应用笔记使用“帧时钟”而且我有一个
DDR时钟，就像在时序图上看到的那样。
所以从我的角度来看，我确实需要
用于实现眼睛中间采样的bitlip机制
一个“框架”一个单词的机制，因为接收者不知道一个单词何时开始和结束。
一种方法是将序列化因子从8（最大值从主/从/ iserdes）增加到10.使用与1：5相同的实例是正确的，但是“缓冲”每秒“偶数”字并连接它
连同每一秒“奇”字？
这将是一个将ser系数提高到1:10的简单方法。
谢谢和最好的问候，
掠夺



以下为原文

avrumw wrote:

From your post, it seems that you are trying to capture a 10 bit parallel bus at 480Mbps/pin (240MHz DDR). To do this, you definitely don't need the 2nd part of this solution, and you may not even need the first part.

Hi avrumw,
thank you very much for your detailled answer. Unfortunately, you've got me wrong here. In my post, I wrote "The sensor outputs 2 lanes of LVDS 10bit-data at 480MHz and a LVDS DDR clock" and attached a timing diagram. But obviously, this wasn't clear enough, sorry for that.
So again, the sensor has the possibility to use up to 16 LVDS outputs to transmit data. In our case we only use 2 of them because of different reasons. Regardless of how much data lanes are used, the sensor outputs a DDR clock using another LVDS pair. Furthermore, a "control- and debug-channel" with sync-signals and other information is output to another LVDS pair. The data and control lanes are running at 480MHz (DDR clock at 240MHz). Configuring the sensor to use more LVDS channels as outputs would increase the timing performance. It just would need less time to readout one frame, because more pixels are readout in parallel then. But the mechanism to read-out one pixel after another is of course true serialized. I've attached another image which hopefully describes the use of more than 1 LVDS data outputs.
 

 
Well, what I've got is a DDR clock, which I have to use to deserialize 2+1 LVDS lanes and my problem is how to adapt the XAPP1064 for that, because the application note uses a "framing clock" and I have a DDR clock, like seen on the timing diagram.
 
So from my point of view, I do need

• the bitslip mechanism to achieve middle-of-the-eye-sampling
  
• a mechanism to "frame" a word, because the receiver doesn't know, when a word starts and ends.
  
• a way to increase the serialization factor from 8 (max. from master/slave/iserdes) to 10. Is it correct to use just the same instances as with 1:5, but "buffering" each second "even" word and concatenating it together with each second "odd" word? That would be a very easy way of increasing the ser-factor to 1:10.
  

Thanks and best regards,
Harry

woko写道：
avrumw写道：
从您的帖子来看，您似乎正在尝试以480Mbps /引脚（240MHz DDR）捕获10位并行总线。
要做到这一点，你绝对不需要这个解决方案的第二部分，你可能甚至不需要第一部分。
嗨avrumw，
非常感谢您的详细解答。
不幸的是，你在这里弄错了。
在我的帖子中，我写道“传感器输出2路LVDS 10位数据，480MHz和LVDS DDR时钟”，并附有时序图。
但显然，这还不够清楚，对不起。
同样，传感器可以使用多达16个LVDS输出来传输数据。
在我们的例子中，由于不同的原因，我们只使用其中的2个。
无论使用多少数据通道，传感器都使用另一个LVDS对输出DDR时钟。
此外，具有同步信号和其他信息的“控制和调试通道”输出到另一个LVDS对。
数据和控制通道的运行频率为480MHz（DDR时钟频率为240MHz）。
配置传感器以使用更多LVDS通道作为输出将提高定时性能。
它只需要更少的时间来读出一帧，因为然后更多的像素被并行读出。
但是，逐个读出一个像素的机制当然是真正的序列化。
我附上了另一张图片，希望能够描述使用1个以上的LVDS数据输出。
好吧，我得到的是一个DDR时钟，我必须使用它来反序列化2 + 1 LVDS通道，我的问题是如何调整XAPP1064，因为应用笔记使用“帧时钟”而且我有一个
DDR时钟，就像在时序图上看到的那样。
所以从我的角度来看，我确实需要
用于实现眼睛中间采样的bitlip机制
一个“框架”一个单词的机制，因为接收者不知道一个单词何时开始和结束。
一种方法是将序列化因子从8（最大值从主/从/ iserdes）增加到10.使用与1：5相同的实例是正确的，但是“缓冲”每秒“偶数”字并连接它
连同每一秒“奇”字？
这将是一个将ser系数提高到1:10的简单方法。
我知道你正在使用什么传感器。
让我们解决问题。
“bitslip”对位采样不起作用。
这是“帧对齐”，将所有位都放入一个单词中。
在S6上，我认为你甚至不需要使用ISERDES;
您可以捕获IDDR中的位并在结构中反序列化。
由于连接器或其他物理限制，您是否仅使用16个分接头中的两个？
因为您可以减慢时钟并使用4个分接头，并获得相同的吞吐量，同时使数据接收更容易。
----------------------------是的，我这样做是为了谋生。



以下为原文

woko wrote:

avrumw wrote:

From your post, it seems that you are trying to capture a 10 bit parallel bus at 480Mbps/pin (240MHz DDR). To do this, you definitely don't need the 2nd part of this solution, and you may not even need the first part.

Hi avrumw,
thank you very much for your detailled answer. Unfortunately, you've got me wrong here. In my post, I wrote "The sensor outputs 2 lanes of LVDS 10bit-data at 480MHz and a LVDS DDR clock" and attached a timing diagram. But obviously, this wasn't clear enough, sorry for that.
So again, the sensor has the possibility to use up to 16 LVDS outputs to transmit data. In our case we only use 2 of them because of different reasons. Regardless of how much data lanes are used, the sensor outputs a DDR clock using another LVDS pair. Furthermore, a "control- and debug-channel" with sync-signals and other information is output to another LVDS pair. The data and control lanes are running at 480MHz (DDR clock at 240MHz). Configuring the sensor to use more LVDS channels as outputs would increase the timing performance. It just would need less time to readout one frame, because more pixels are readout in parallel then. But the mechanism to read-out one pixel after another is of course true serialized. I've attached another image which hopefully describes the use of more than 1 LVDS data outputs.
Well, what I've got is a DDR clock, which I have to use to deserialize 2+1 LVDS lanes and my problem is how to adapt the XAPP1064 for that, because the application note uses a "framing clock" and I have a DDR clock, like seen on the timing diagram.
 
So from my point of view, I do need

• the bitslip mechanism to achieve middle-of-the-eye-sampling
  
• a mechanism to "frame" a word, because the receiver doesn't know, when a word starts and ends.
  
• a way to increase the serialization factor from 8 (max. from master/slave/iserdes) to 10. Is it correct to use just the same instances as with 1:5, but "buffering" each second "even" word and concatenating it together with each second "odd" word? That would be a very easy way of increasing the ser-factor to 1:10.
  

 

I know what sensor you're using.
 
Let's sort things out.
 
"bitslip" doesn't work on the bit sampling. It's the "frame alignment," putting all of the bits into a word.
On an S6, I don't think you even need to use the ISERDES; you can capture the bits in the IDDR and deserialize in the fabric.
 
Are you using only two of the 16 taps because of connector or other physical limitation? Because you can slow down the clocking and use 4 taps, and get the same throughput while making the data reception easier.
----------------------------Yes, I do this for a living.

真的很难猜，嗯？
你是对的，可以使用更低的费率和更多的车道。
但目前我们的空间非常有限，而且我们在未来的设计中需要更多的吞吐量，因此我们希望保持设计的可扩展性。
这就是为什么我现在想坚持使用ISERDES组件。
因此，bitlip机制只告诉ISERDES哪个位先到哪个位？
这意味着可以在结构中运行的简单FSM中控制bitlip信号，从传感器处查找正确的“IDLE”字。
一旦发现这个，我不再需要为bitlip烦恼了吗？
我是否需要使用IDELAY2在Clk和数据线之间进行相位校正才能获得干净的采样点？
我发布的实现1:10 serdes的方法是否正确？
谢谢，



以下为原文

Really hard to guess, hm?
You're right, it would be possible to use lower rates and more lanes. But at the moment we are really limited in space and furthermore we need much more throughput in a future design, so we want to keep the design scalable. Thats why I want to stick at the ISERDES components for now.
 
So, the bitslip mechanism is only telling the ISERDES which bit comes first and which last? That means the bitslip signal can be controlled in a simple FSM running in the fabric, looking after the correct "IDLE" word from the sensor. Once this is found, I don't need to bother about the bitslip anymore?
 

• Do I need phase correction between Clk and Data lines with an IDELAY2 to achieve clean sampling points?
  
• Is the approach I've posted for achieving 1:10 serdes correct?
  

thanks,
 

woko写道：
真的很难猜，嗯？
你是对的，可以使用更低的费率和更多的车道。
但目前我们的空间非常有限，而且我们在未来的设计中需要更多的吞吐量，因此我们希望保持设计的可扩展性。
这就是为什么我现在想坚持使用ISERDES组件。
当然合理，但要考虑最终结果吞吐量。
来自传感器的数据必须在某处，因此您无法以比吸入数据更快的速度运行传感器。
我想如果你现在需要工作，你应该坚持使用IDDR而不用担心ISERDES。
如果您的日程安排允许玩ISERDES，那么当然可以。
因此，bitlip机制只告诉ISERDES哪个位先到哪个位？
基本上，是的。
反序列化的单词会显示给您，您显然希望数据MSb位于MSb位置。
bitlip过程安排这一点。
这意味着可以在结构中运行的简单FSM中控制bitlip信号，从传感器处查找正确的“IDLE”字。
一旦发现这个，我不再需要为bitlip烦恼了吗？
是的，就是这样。
您的状态机监视每个反序列化的字，如果它与训练模式不匹配，则为一个CLKDIV断言BITSLIP信号，然后再次查看并行字，并继续执行直到匹配。
除非您更改传感器的运行方式，否则您不需要为此烦恼。
但是当传感器没有读出时，仍然值得监视空闲模式，所以如果它确实失去了理智，你可以尝试恢复。
话虽如此，我从未见过传感器在正常操作期间失去理智。
但比抱歉更安全。
我是否需要使用IDELAY2在Clk和数据线之间进行相位校正才能获得干净的采样点？
我发布的实现1:10 serdes的方法是否正确？
我没有在Spartan 6中对这个传感器进行接口，所以我不能告诉你。
但我的猜测是你应该使用相位检测器。
----------------------------是的，我这样做是为了谋生。



以下为原文

woko wrote:
Really hard to guess, hm?
You're right, it would be possible to use lower rates and more lanes. But at the moment we are really limited in space and furthermore we need much more throughput in a future design, so we want to keep the design scalable. Thats why I want to stick at the ISERDES components for now.

Reasonable, of course, but consider your end-result throughput. The data from the sensor's gotta so somewhere, so you can't run the sensor any faster than you can suck in the data.
 
I suppose that if you need to get something working NOW you should just stick with the IDDR and not worry about the ISERDES. If your schedule allows for playing with the ISERDES, then of course do it. 

So, the bitslip mechanism is only telling the ISERDES which bit comes first and which last?

Basically, yes. The deserialized word is presented to you and you'd obviously like the data MSb to be in the MSb position. The bitslip process arranges for that. 

That means the bitslip signal can be controlled in a simple FSM running in the fabric, looking after the correct "IDLE" word from the sensor. Once this is found, I don't need to bother about the bitslip anymore?

 Yup, that's it. Your state machine monitors each deserialized word, and if it doesn't match the training pattern, you assert the BITSLIP signal for one CLKDIV, then you look at the parallel word again, and keep doing it until you match.
 
You shouldn't need to bother with it, unless you change how the sensor operates. But it's still worth monitoring the idle pattern when the sensor isn't reading out, so if it does lose its mind you can attempt to recover. Having said that, I've never seen the sensor lose its mind during normal operation. But better safe than sorry.
 

• Do I need phase correction between Clk and Data lines with an IDELAY2 to achieve clean sampling points?
  
• Is the approach I've posted for achieving 1:10 serdes correct? 
  

I didn't do my interface to this sensor in the Spartan 6 so I can't tell you. But my guess is that you should use the phase detector.
----------------------------Yes, I do this for a living.

嗨bassman59，
感谢有关bitlip和你的设计建议的有价值的信息 - 最后我现在已经得到了它......我想的并不是那么复杂。
我设法让10：1 ISERDES在模拟中工作 - 剩下的部分应该是直截了当的。
我同意我应该不断检查IDLE字，安全第一。
并谈论相位校准：我认为我应该考虑到这一点，以确保数据在眼睛中间采样。
相位校准器也包含在XAPP1064和SelectIOGuide中，因此我应该能够处理那个。
到目前为止，谢谢你的帮助。
问候哈拉尔德



以下为原文

Hi bassman59,

thanks for the valuable information about bitslip and your design advices - finally I've got it now... it really isn't that complicated I thought first. I managed to get the 10:1 ISERDES working in simulation - the remaining parts should be straightforward.

I agree that I should check the IDLE word constantly, safety first. And talking about phase calibration: I think I should take into account that one, to make sure the data is sampled in the middle of the eye. The phase calibrator is also covered within the XAPP1064 and the SelectIOGuide, so I should be able to handle that one.

So far, thank you for your help.

Greetings Harald