如何进行Spartan-6 LX9微型板的数字转换器时间编码

嗨，
最简单的实现是一些具有小控制FSM的超快计数器，以尽可能高的时钟频率计时。
时间分辨率受时钟周期的限制，但实现简单可靠（！）。
任何涉及FPGA内部延迟的方案都注定要失败。
1）不仅仅是编写一些导致有用延迟链的VHDL源非常困难。
2）温度校准也是一个问题。
3）此外，您将如何将结果接管到数字域？
根据您真正需要的分辨率，您可以尝试这样的事情：
1）创建一个常量加法器：7FFF + 0000 + Carry_in（或更大的数字） 
Carry逻辑非常快，并且放置非常规则。
2）创建第二个加法器并以快速可靠的时钟信号作为参考馈入进位。 
结果的更改将为您提供延迟链实际时间分辨率的度量。
3）CLB / Slices中有FF用于保存Carry链。
关键是如何触发它们。 
在常规路由资源上对FF进行计时将导致高偏差。 
使用Trigger / CarryIn的全局时钟网很困难，因为全局时钟网络无法提供组合输入， 
至少会有工具报告的DRC问题。
您可以使用FPGA-Editor工具在实施后手动检查所有净延迟。
可能需要进行大量的手工返工，并且无法保证您可以获得有用的工作。
你知道，它实现起来并不容易，并且不太可能从这样的设计中获得有用的结果。
最好先检查一下柜台设计的极限。
也许它已经足够您的应用程序，因为它可能会达到低于2 ns的分辨率。
有一个很好的综合 
Eilert



以下为原文

Hi,
the most simple implementation would be some ultrafast counter with a small controlling FSM, clocked at the highest possible clock frequency.
The time resolution is limited by the clock period, but the implementation is simple and reliable(!) .
 
Any scheme involving delays inside an FPGA is doomed to fail.
1) Not just that it is very difficult to write some VHDL  source that results in a useful delay chain.
2) The calibration over temperature will be some problem as well.
3) Also, how will you take over the result into the digital domain?
 
Depending on the resolution you really need you can try something like this:
1)  Create a constant adder: 7FFF + 0000 + Carry_in (or some larger number)
      The Carry logic is quite fast and the placement very regular.
 
2)  Create a second adder and feed the Carry in with a fast reliable Clock signal as a reference.
      The change of the result will give you a measure for the actual time resolution of the delay chain.
 
3) There are FFs in the CLBs/Slices that hold the Carry chains. The point is how to trigger them.
    Clocking the FFs over regular routing ressources will result in a high skew.
    Using a global clock net for the Trigger/CarryIn is difficult, because Global clock nets can not feed combinatorical inputs,
    at least there will be DRC problems reported by the tools.
 
You can use the FPGA-Editor tool to check all the net delays manually after the implementation.
A lot of manual rework might be necessary and there's no guarantee that you will get something useful to work.
 
You see, it's not easy to implement and very unlikely to get useful results from such a design.
Better first check the limits of the counter design.
Maybe it is already sufficient for your application because you might reach below 2 ns resolution with it.
 
Have a nice synthesis
  Eilert
 

感谢Eliert的解释，这真的是一个帮助......
在论坛写作之前，我在互联网上做了一些搜索，发现了一些与实现相关的文章/文章，我确实试图理解它......但是当实现这种技术时，对它一无所知......所以
，我在这里分享这些论文，如果我们能用比时钟周期限制更好的分辨率，那么它值得尝试....
再次感谢...
低资源基于fpga的tdc.pdf 536 KB
fpga.pdf中的高分辨率tdc 237 KB



以下为原文

Thanks Eliert for the explaination, its really a help......
 
Before writting in the forum, I did some search on the internet, and found some paper/article related to the implementation, I did try to understand it...but when came to implement that technique, was clueless about it...So, I am sharing those papers here, If we can have better resolution than clock period limitation using that, then its a worth attempt....
 
Thanks again...
            low resource fpga based tdc.pdf ‏536 KB                high resolution tdc in fpga.pdf ‏237 KB

嗨，
第一篇论文的重点是低资源，几乎避免了延迟线方法。
它只是提到完整性，但随后立即下降。
第二篇论文使用了我提到的相同基本方法。
只是他们使用了Adder的一个LSB​​而不是CarryIn。
两个交错灰色计数器用于基于固定时钟提供粗略定时。
非常聪明。
当然，在开始设计之前定义测量目标和使用是很重要的。
第二篇论文描述了一种检测事件并确定其在一个时钟周期内的位置的方案，
从而提高了事件时间测量的准确性。
确定短脉冲的持续时间并不需要粗略的计数器，只是提到一些不同的方法。
但是，您的项目需求是什么？
你究竟想测量什么？
例如
第一篇论文描述了一种4xOversampling技术，它比选择的时钟更快，仍然是一种非常可靠和易于编码的方法（实际上一些代码已存在于数据恢复XAPP中），而FF的放置在这里也是至关重要的。
有一个很好的综合 
Eilert



以下为原文

Hi,
the first paper focusses on low ressources and almost avoids the delay line approach.
It is just mentioned for completeness, but then dropped immediately.
 
The second paper uses the same basic approach I mentioned.
Only that they used one LSB of the Adder instead of the CarryIn.
Two interleaving gray counters are used to provide a coarse timing based on a fixed clock.
Very clever.
 
Of course to define the measurement goal and usage is important before starting the design.
The second paper describes a scheme to detect events and determine their position within a clock cycle,
thus improving the accuracy of the event time measurement.
 
Mesuring the duration of short impulses does not need a coarse counter, just to mention some different approach.
 
However, what is the requirement of your project?
And what exactly do you want to measure?
 
e.g. The first paper describes a 4xOversampling technique which is faster than the chosen clock, still a quite reliable and easy codeable approach (actually some of that code already exists in a data recovery XAPP),  while the placement of the FFs also is crucial here.
 
Have a nice synthesis
  Eilert
 
 

嗨Eliert，再次感谢专家评论.......
我的项目要求是在给定资源的情况下实现最低TDC分辨率....所以，我想学习并实现任何可以在FPGA本身中使用TDC的方法....我仍然是关于这个主题的新手，所以可以'
真正解释一切，不是哪种是基本方法，哪种是先进的......但我在每篇论文中发现的一个常见的事情就是采用多抽头延迟线方法......所以我很好奇实施和检查
结果....是否可以只用FPGA编码..我的意思是没有任何外部硬件？
再次感谢。



以下为原文

Hi Eliert, Thanks again for the expert comments.......
 
My project requirement is to achieve minimum TDC resolution given the resources....So, I want to learn and implement any of the method which can imolement TDC in FPGA itself....I am still newbie regarding the topic, so can't really interpret everything and don't which is basic method and which is advanced...... But one thing I found common in every paper is a multi-tapped delay line approach...so am curious about implementing and checking the results....Is it possible to do with only coding in FPGA..I mean without any external hardware?
 
Thanks again.

FPGA制造了糟糕的延迟线，因为内部并不是真正的设计。
有一些I / O资源允许您具有可变延迟，实际上这些元素内部由多抽头延迟线组成。
问题是您一次只能访问一个水龙头。
我已经阅读过早期的应用笔记（Virtex-E，如果我没记错的话）使用进位链延迟的家庭。
问题是在Spartan 6中，进位链有一种奇怪的4位向前看，所以你不会在链中从一位到另一位得到一致（甚至是单调）的延迟。
当尝试以抽头延迟方式使用内部元件时的另一个问题是仅路由延迟可能超过实例化元件的延迟。
因此，如果您尝试将相同的输入馈送到几个不同长度的LUT链中，由于链中LUT的数量导致的输出时序差异实际上可能小于由于第一个LUT的到达时间导致的差异，因为
路由。
对于DCM而言，使用时钟进行4倍过采样似乎相当简单，而不是产生4个时钟相位。
但是现在您有一个输入路由到在不同时钟相位上运行的4个触发器，并且由于片中的时钟路由资源，这必然意味着4个不同的片。
因此，当您的时钟达到相当高的频率时，路由延迟开始主导四个样本之间的相位差。
最重要的是，您可能需要进行一些手动放置和布线，以使任何基于延迟线的设计高速运行。
ISERDES模块提供了一个非常快速的移位寄存器，可以让您大部分时间回家进行高速定时。
如果您可以将输入信号连接到多个引脚（再次在板级仔细布线），您可以使用具有不同IDELAY值的多个ISERDES来获得更高的分辨率。
-  Gabor



以下为原文

FPGA's make lousy delay lines, because the internals are not really designed for that.  There are I/O resources that allow you to have a variable delay, and in fact those elements internally consist of multi-tap delay lines.  The problem is that you only have access to one tap at a time.
 
I've read app notes from earlier (Virtex-E if I remember correctly) families that used carry chain delays.  The problem is that in Spartan 6 the carry chain has a weird sort of 4-bit look ahead so you don't get a consistent (or even monotonic) delay going from one bit to the next in the chain.
 
Another problem when trying to use internal elements in a tapped-delay fashion is that the routing delays alone can exceed the delays of the instantiated elements.  Thus if you for example tried to feed the same input into several different length chains of LUTs, the difference in output timing due to the number of LUTs in the chain may actually be smaller than the difference due to the arrival time at the first LUT because of routing.
 
4x oversampling with a clock seems fairly straightforward given a DCM than generates 4 clock phases.  However now you have a single input that routes to 4 flops running on different clock phases, and that necessarily means 4 different slices due to the clock routing resources in the slice.  So again as your clock gets to a fairly high frequency, the routing delays start to dominate the phase differential between the four samples.  Bottom line is that you will probably need to do some hand placement and routing to get any delay-line based design working at a high speed.
 
The ISERDES block offers a very fast shift register that could get you most of the way home for high-speed timing.  If you can connect the input signal to multiple pins (again with careful routing at the board level) you can use multiple ISERDES with different IDELAY values to get more resolution.
-- Gabor

谢谢gszakacs， 
我正在尝试使用4xclock方法并使用DCM尝试再生成3个相位相差90度的时钟...目标设备是Spartan-6 LX9 CSG324 ....但是当我合成了只包含clk的代码时
输入和少量输出和DCM ...我得到错误XST：2035 ....然后我减少到只有一个时钟-90 ...然后在映射中它失败...显示映射中的跟随错误...
任何人都可以帮忙吗？
错误：放置：1205  - 此设计包含一个全局缓冲器实例，驱动网络，驱动以下（前30个）非时钟负载引脚芯片外。
在Spartan-6中，这种设计实践可能由于全局布线的限制而导致不可预测的情况。
如果设计确实存在路线，则该网络可能存在过度延迟或倾斜。
建议使用时钟转发技术来创建可靠且可重复的低偏斜解决方案：实例化ODDR2组件;
将.D0引脚连接到Logic1;
将.D1引脚连接到Logic0;
将时钟网连接到.C0;
将倒置时钟连接到.C1。
如果您希望覆盖此建议，可以使用.ucf文件中的CLOCK_DEDICATED_ROUTE约束（如下所示）将此消息降级为警告并允许您的设计继续。
虽然网络可能仍未路由，但您可以分析FPGA_Editor中的故障。
错误：位置：1136  - 此设计包含一个全局缓冲区实例，驱动网络，驱动以下（前30个）非时钟加载引脚。
这不是Spartan-6中推荐的设计实践，因为全局布线的限制可能导致过度延迟，歪斜或不可路由的情况。
建议仅使用BUFG资源来驱动时钟负载。
如果您希望覆盖此建议，可以使用.ucf文件中的CLOCK_DEDICATED_ROUTE约束（如下所示）将此消息降级为警告并允许您的设计继续。
错误：包装：1654  - 时序驱动的放置阶段遇到错误。
tdc.vhd 2 KB



以下为原文

Thanks gszakacs,
 
                                I am trying the 4xclock method and using DCM tried to generate 3 more clocks which are 90 degree out of phase with each other...Target device is Spartan-6 LX9 CSG324....But when I synthesized the code which only contains clk input and few outputs and a DCM...I get error XST:2035....then I reduced to only one clock-90...then in the mapping it gets failed...showing following error in Mapping... Can anyone help on this?
 
ERROR:Place:1205 - This design contains a global buffer instance,
, driving the net, , that is driving
the following (first 30) non-clock load pins off chip.
< PIN: a.O; >
This design practice, in Spartan-6, can lead to an unroutable situation due
to limitations in the global routing. If the design does route there may be
excessive delay or skew on this net. It is recommended to use a Clock
Forwarding technique to create a reliable and repeatable low skew solution:
instantiate an ODDR2 component; tie the .D0 pin to Logic1; tie the .D1 pin to
Logic0; tie the clock net to be forwarded to .C0; tie the inverted clock to
.C1. If you wish to override this recommendation, you may use the
CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
this message to a WARNING and allow your design to continue. Although the net
may still not route, you will be able to analyze the failure in FPGA_Editor.
< PIN "your_instance_name/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >

ERROR:Place:1136 - This design contains a global buffer instance,
, driving the net, , that is driving
the following (first 30) non-clock load pins.
< PIN: a.O; >
This is not a recommended design practice in Spartan-6 due to limitations in
the global routing that may cause excessive delay, skew or unroutable
situations. It is recommended to only use a BUFG resource to drive clock
loads. If you wish to override this recommendation, you may use the
CLOCK_DEDICATED_ROUTE constraint (given below) in the .ucf file to demote
this message to a WARNING and allow your design to continue.
< PIN "your_instance_name/clkout1_buf.O" CLOCK_DEDICATED_ROUTE = FALSE; >

ERROR:Pack:1654 - The timing-driven placement phase encountered an error.
            tdc.vhd ‏2 KB

“XST：2035”对我们大多数人来说意义不大。
应该有可能有帮助的错误或警告的描述。
在任何情况下，你得到的映射错误都是因为你正在将一个全局时钟网络驱动到一个引脚，这对Spartan 6来说是不合法的。正如错误文本建议你使用ODDR2来驱动一个引脚的时钟。
这称为“时钟转发”。
搜索该术语可能会为您提供大量信息，但基本思路是使用D实例化ODDR2，其中上升沿时钟连接到“1”，D代表下降沿时钟连接到“0”。
这会将时钟转发到引脚，而不会出现错误。
至于原始综合错误，您需要发布代码以获得有关这些错误的帮助。
顺便说一句，如果您要像ODDR2一样向设计添加基元，则应该取消注释顶部的线：
- 如果在此代码中实例化 - 任何Xilinx原语，则取消注释以下库声明.-- library UNISIM;  - 使用UNISIM.VComponents.all;
-  Gabor



以下为原文

"XST:2035" doesn't mean much to most of us.  There should be a description of the error or warning that might help.  In any case, the mapping error you got is because you're driving a global clock net to a pin, which is not legal for Spartan 6.  As the error text suggests you shold use an ODDR2 to drive a clock to a pin.  This is called "clock forwarding."  Searching for that term will probably give you a lot of information, but the basic idea is to instantiate an ODDR2 with the D for the rising edge clock connected to '1' and the D for the falling edge clock connected to '0'.  This will forward the clock to the pin without the error you're getting.
 
As for the original synthesis errors, you'd need to post the code to get help on those.  And by the way, you should uncomment the lines at the top if you're going to add primitives to the design like an ODDR2:
 
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;


-- Gabor

亲爱的大家，
我使用ODDR2，效果很好。
现在，我正在尝试从DCM生成时钟，我的输入频率为100Mhz，我知道在375 MHz输出频率之后，时钟向导发出警告建议使用BUFPL ....我需要知道我可以生成的最大频率
与dcm的相位差为90,180和270 ......即使使用BUFPL ..？
谢谢，
MSD



以下为原文

Dear all,
 I have use ODDR2 and it worked well. Now, I am trying to generate clock from DCM, my input frequency is 100Mhz, I come to know that after 375 MHz output frequency, clock wizard gives warning to suggest use of BUFPL.... I need to know maximum frequency I can generate with 90,180 and 270 phase difference from dcm...even if using BUFPL..?
 
Thanks,
MSD