微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 信号完整性分析 > 信号完整性分析讨论 > 请教:时序分析公式的理解?

请教:时序分析公式的理解?

时间:10-02 整理:3721RD 点击:
[upload=jpg]uploadImages/20028191739433359.jpg[/upload]
阿鸣,你好!再请教一个关于时序分析公式的理解问题。如上图的公式中:
“我们知道Tco(max) + FlightTime(max) + Clock Skew + Receiver Setup 一定少于时钟周期, 否则便违反了 receiver 的建立时间约束。”(某些因素如Jitter等已忽略)
“我们也知道Tco(min) + FlightTime(min) - Clock Skew 一定多于 receiver 的维持时间。”
上述好象不好理解,可否帮我解释解释!
另外,基于以上公式,是否如假设时钟为0时延,对数据线的时序约束公式?也即时钟和数据线之间的时延差所必须遵循的公式?

这个一下子很难说清楚,还是贴两个图来说明吧:[upload=jpg]uploadImages/cpu.jpg[/upload][upload=jpg]uploadImages/200281918115843679.jpg[/upload]系统时序的基本要求就是:在下一个时钟周期到达之前,前一个数据要能稳定的被读取。第一个图中,时钟是同时到达Driver和receiver的,也就是说驱动端时钟触发新的数据发送的同时,接受器正好读取前一个数据。如果接收器的下一个时钟脉冲来了,但新的数据还没有传到,就会出现时序紊乱,这就是建立时间不够的情况,所以数据线长不能太长(而且负载不能太重),这就是目前正常时序系统设计中最关键的制约因素之一;同时,数据不能来的太快,因为数据必须稳定存在一定的时间才能被正确接收,如果过早的传输到接收端,等时钟触发的之后,数据稳定存在的时间不足以让器件读取,这就是保持时间不够的问题。所以数据信号传输延时不能过大也不能过小,这就是时序设计要求。知道了时序的这些要求就能推算出时序公式了,可以简单的用文字表达为:数据从驱动端发送到接收端的最大延时 + 数据的建立时间要求 <= 一个时钟周期数据从驱动端发送到接收端的最小延时 >= 器件需要的保持实践这是两个不等式,如果不但满足这两个不等式,还有多余的时间量,就称为时序裕量。需要注意的是,保持时间和建立时间裕量一定是随着传输延时的改变此消彼长的,但如果减少Skew或Jitter之类的偏差,可以让两者的裕量同时增加。这也是为什么我们要控制时钟偏移,减小板子串扰的原因。

哎呀,阿鸣,厉害啊!
我看了半天没明白,你这一说,感觉并不难理解。高手!高手!理解的就是透彻啊!谢谢!
扛个大草莓给你尝尝!

[upload=jpg]uploadImages/200281920435041448.jpg[/upload]

谢谢你的草莓
:)
其实我当初也是花了很大精力才摸清楚的
没人问,只能抱着一堆外文资料啃,到现在还牙疼~~

ming解释的很清楚,不过如果在时序图上观察并将公式写成下面方式可能更容易理解,呵呵
1、receiver的setup时间 > 根据实际计算值
2、receiver的hold时间 > 根据实际计算值

阿鸣,你好!
   如果按以上的公式计算后,最后得出的结果如下:
   Tflightmax = 4.55 ns
   Tflightmin = 0.05 ns
   那么,在实际布线中,又是如何计算和控制时钟与数据的时延差的?也即如何在布线中体现出以上参数的?
   是否可以按如下方式计算?
   信号在介质中的传输速度为:Vp=C/√εr,因此在一般的FR4中速度约为5.7inch/ns。
   然后按此公式计算:
    a.数据线可以比时钟线长5.7inch/ns×4.55ns=26inch以内
    b.时钟线可以比数据线长5.7inch/nc×0.05ns=0.285inch以内
   必须同时满足以上两个条件,可得到:
     时钟线长-0.285 < 数据线长度 < 时钟线长+26  (单位:inch)
   是否按如上理解?请赐教,谢谢!

实际的系统时序设计中的问题我还不是很清楚
如果按我上面的分析,时钟信号到driver和receiver是同时的话,计算出来的信号最大/最小延时和时钟信号线的长度无关;如果这两个时钟CLKA和CLKB不同时到达,那就要考虑到两段时钟走线的长度问题;如果是源同步总线技术,receiver的时钟信号是从driver发出的话(即上图中去掉clock buffer),计算setup裕量的时候就不是以时钟信号周期为限,而是以driver到receiver的时钟走线长度做为比较。
另外,对于数据线来说,由于它是双向传送的,不但要考虑正向传输的时序(写操作),还要考虑反向时序(读操作),这样driver和receiver就要交换位置考虑了,所以不是很简单地就能确定的。
在计算时序时,还有一个重要的参数就是Tco的值,他在不同负载情况下值也不同,保守起见,在考虑setup裕量时要取最大值,在考虑hold裕量时要考虑最小值。
我觉得系统时序设计是很复杂的,尤其是高速电路,需要综合很多因素,我也在学习。

因为在实际的应用中,器件大部分基本上已决定,因此如Tco等参数已基本上确定。我们能够灵活处理的就剩下走线的长度了。在很多的Datasheet中有提到:某组高速信号线(包括一组数据线和时钟线)的走线长度差必须小于100mils等等。这“100mils”应该就是按时序的约束公式算出来的吧!
另外,请教一下,什么叫“源同步总线技术”?还有哪些技术?

你提到的走线长度差小于100mils应该是为了减小skew,以提高时序裕量,但这个100mils不是通过公式算出来的,是个靠经验或仿真确定的允许误差范围
因为确定最大flight时间时,不能只看一根信号线,而是取同组所有信号线中最长的
同样对于最小flight时间,也要取所有中最短的
保证同组信号之间的走线偏差可以减少相对误差,提高整体Margin,也有利于时序的调整。
对于Tco也是一样的,器件厂家提供的肯定不是一个固定值,所以也要在不同的情况取不同大小的值去计算。
源同步比较典型例子是现在DDR内存的数据总线,它不是直接由系统的Clock读取的,而是靠和数据线同步传输的数据指针(DQS,data strope)来进行读取,其实DQS也就相当于时钟的功能,优点是,和数据同步传输,在芯片内部进行延时处理,能保证精确的时序。如果仅仅是针对数据信号和源同步时钟来说,将不受时钟周期对建立时间时序的约束。不过是理想情况而已了。我对源同步现在也是一知半解,以后知道多一点再进一步讨论。

我现在对Flight time的概念,被搞得越糊涂了!按照您上面的说法:
  “如果接收器的下一个时钟脉冲来了,但新的数据还没有传到,就会出现时序紊乱,这就是建立时间不够的情况,所以数据线长不能太长”,我的理解:这个最长的数据线长(时钟和数据长度差)就是Flight time(max)时间所传输的距离。
  “同时,数据不能来的太快,因为数据必须稳定存在一定的时间才能被正确接收,如果过早的传输到接收端,等时钟触发的之后,数据稳定存在的时间不足以让器件读取,这就是保持时间不够的问题。”,我的理解:这个最短的数据线长(数据和时钟长度差)就是Flight time(min)时间内传输的距离。
   不知以上理解是否正确?再举个简单的例子:一根时钟线和一根数据线,如果始终保持等长,从时序上来说(排除衰减等其他因素的影响),不管走多长,应该都是可以满足时序要求的。只有长度差超过以上所说的情况时,才导致时序问题。我的理解是这样的!
   再看看Cadence里的一个如下插图,对于Flight time max (即First Switch Delay)和Flight time min(即Final Settle Delay)两个概念就太难理解了!
   请阿鸣指教!谢谢!
[upload=jpg]uploadImages/200282016301048558.jpg[/upload]

从我开始画的那个时序图上可以看到,系统的时钟信号都是同步的,即驱动端和接收端的时钟都是由主板上时钟发生器提供,在这种情况下,讨论时序问题时不牵涉到时钟信号的走线长短问题,(即使有也是时钟信号线之间的差别,而数据线的长度约束与时钟信号线无关,只与周期有关)。但实际的系统很复杂,不一定是严格的同步时钟系统,有时是异步传输,接收器的时钟可能是直接由driver产生的,这时候就不能完全按照前面提到的公式,可能这时候时序计算的确要考虑时钟走线的长度,因为我没有接触很深,所以现在我也无法讲清,但基本的理论是上面说的,如果知道系统的设计结构,就可以进行相应的推论。我也看到很多设计的datasheet上约束的线长是和时钟走线作比较的,我还没仔细的分析过,有空会再看看。
你说的“一根时钟线和一根数据线,如果始终保持等长,从时序上来说(排除衰减等其他因素的影响),不管走多长,应该都是可以满足时序要求的。”如果对于理想的“源同步时钟系统”来说是成立的,但是普通的时钟系统则不是如此,时钟信号只是保证所有的器件同时进行触发操作,但并不是跟踪每个数据线进行读取。如果按照你上面的理解,那好像应该让数据线短一点更为合适,时钟信号在数据信号的中间部位读取才是最理想的,所以相位上应该有数据信号1/4周期的偏移。
还有一个关键性的思想:我们是通过时序约束条件计算来确定Flight time的最大最小值,从而调整走线的结构或线长。举个例子,对于一块DDR333来说,其时钟周期是166MHz,即6ns,如果memory controller的Tco是1 ns,DDR内存颗粒需要的建立时间为0.8ns,估计时钟的skew, jitter,以及 串扰对时序的影响为0.6ns,那么,就可以计算出地址/控制线的最大传输延时(Flightmax)为:6-1-0.8-0.6=3.6ns,这时候我们设计走线结构和线长的时候就必须要保证传输延时小于3.6ns,小的多少就是setup时间裕量的大小。
至于如何计算Flight Time就是Cadence图中标明的,有一点要注意的是:每一根信号走线在Cadence中仿真中都会测量出其最大/最小的Flight time,但这不是约束条件中的Flight time,约束条件中的传输延时是所有同类信号的最大延时。
先说这么多,时序的东西一下子是难以理解,多想想,如果对Flight time如何定义及如何量度,可以再讨论,现在饿了,要回家吃饭了。:)

[此贴子已经被阿鸣于2002-8-20 18:21:07编辑过]

从你画的第一个时序图上来看,时序分析确实满复杂的。我觉的先要计算CLKA和CLKB的时序关系,其实可以将到达Driver和Receive的CLK看作的Clock Skew,由于Clock Skew的结果使得Clock的有效周期变短(相当于两个时序不同的时钟周期相叠,造成周期的有效时间变短)。然后再将这个有效的CLK与Qp->Dc的数据进行时序分析。我是这么理解的!
我是认为源同步时钟系统是应该数据线稍比时钟线短一些为好,因为一般的时序要求中,好象都是建立时间要长一些,而保持时间均较短,甚至有的时序要求保持时间最小可以到0。
还有一个问题,就是“传输延时”,如果联系到实际的PCB板上的走线,不知这传输延时该如何计算?我现在估算就使用走线长度和信号传输速率的比值来算。还有,请问一下,信号传输速率与线上的分布电感、分布电容有关系吗?还是只影响其上升、下降沿?

你的理解是对的,
至于传输延时,其实我前面这样提法有点不正确,
标准的传输延时的定义是:propagation delay,指传输线上的信号传播延时,一般只于线长,信号的传播速度有关,与传输线本身的电感和电容无关,但和传输线上分布的负载数目及电容电感有关,比如传输线上分布均匀的容性负载情况下,会使传输线单位长度等效的电容增加,而电感不变,这就会造成传输延时增大。实际中如果走线的拓补结构不是很复杂(仅仅是点对点连接,中间无负载)则传输延时可以通过用走线长度和信号传输速率来计算。
上升沿的影响主要是负载,如果传输线上存在着分布的电容,就会造成等效负载增大,引起上升沿变缓。

[此贴子已经被阿鸣于2002-8-21 11:27:05编辑过]

曾经整理过一点计算时序方面的东西:
主要有下面两种情况,更高的串行数据传输是靠将时钟和数据一起编码实现的。
1.传统的同步技术,也就是前面一直在讨论的,工作在“绝对”时钟的情况下,系统中采用同一个时钟,设计传统同步接口的主要工作是如何在系统中分配时钟,使得时钟线等长以减少skew,信号传输时延或者说飞行时间增加了信号的建立时间,限制了系统的速度,时序分析如下面两张图,时序方程就不再贴了
抱歉,图不太会贴
2.源同步技术:
源同步技术是指数据和时钟/锁存并行传输。由于源同步接口信号工作在“相对”的时钟系统下,这样对全局系统时钟的skew要求就可降低,在时序方程中就不需要flight time(飞行时间)这一变量。源同步技术中,走线长、Tco、器件本身的快慢不是影响接口速度的因素。影响速度的最主要因素是数据与时钟/锁存信号之间的skew,对数据和时钟/锁存信号间skew的约束是仿真中最主要做的工作。时序公式为:
           建立时间:
               Tvb_min+Tft_clk_min-Tft_data_max-Tsetup-Tsetup_margin>0
           保持时间:
               Tva_min-Tft_clk_max+Tft_data_min-Thold-Thold_margin>0

实际的PCB板上的走线延时与时序方程中的flight time是不一样。信号的传输速率与线上的分布电感、分布电容应该有关系,既然影响了上升、下降沿,那么得到的时间也必然是受到影响的,因为时间点都是根据各种阈值电平定义的。

谢谢阿鸣和yezhang的回复!
不过有个问题请教yezhang:为什么说在源同步时钟系统的时序方程中就不要flight time呢?虽然这种情况下时钟和数据是并行传输的,但它们还是会由于走线长度等因素引起时序差的,除非你说把这个因素算到Skew中了。
信号的传输速率与分布电容、电感可能有一点点关系吧,可能在一般的设计中都将它忽略了,但是否有一个量化的数值呢?
另外,对于flight time,我现在还是不大明白!根据上一页最后那张图,它与传输延迟(tpd)定义是不一样,但似乎也相差不大。因为要与实际的PCB走线长度联系上,我就必须用传输延迟,flight time在实际中不知道怎么应用?
还有,我在另外一篇文档中有看到如下图和解释,它所说的flight time好象就是tpd?
[upload=jpg]uploadImages/200282113382721636.jpg[/upload]

xiechengmin,
yezhang说在源同步时钟系统的时序方程中就不要flight time,是因为源同步时钟系统中时钟时钟和数据线始终是等长的,只存在两者之间的相对偏差(Skew),但和本身传输的长度无关。
理论上Flight time和传输延迟(tpd)的区别在于,tpd仅仅是考虑传输线走线延时,不考虑上升时间,而fight time不但包含走线延时,还包括上升时间或下降时间,传输延时其实更深的考虑应该用电磁场传播的理论来解释,它只和介质的节电常数Er有关,如果对于一定长度的理想的传输线模型,只要它所处的介质是均匀的,其传播延时肯定不变的,无论阻抗如何,还是传输线忽宽忽窄,都没有影响,但如果传输线上存在均匀分布的电容,即单位长度电容变大,但电感不变,这时候传播延迟=Squall root(LC)就变大了,其实也可以分析为等效的介电常数发生了变化(变大),传播延迟的另外一个通用公式标明只与Er有关。
对于时序计算来说,传播延迟可以不用考虑,我们最重要的是关注包含上升时间的Flight time。当然,对于有些资料,它就把Flight time定义为Tpd,这不是很严谨的。比如Intel就是将Flight time定义为tpd,但有时也称为Flight time,而Jedec则是将它定义为T net_delay,但他们说的这些都是指Flight time而不是线上的传输延时,因为实际情况中我们几乎没有必要考虑信号的走线延时,不然通过长度就能计算也就不用靠仿真了。其实任何标称都无所谓,没有人约定一定要怎么写,只要理解它实际的含义就可以了。
Cadence里面是将传输延时和Flight time分开定义的,我觉得这样能对理论的理解更清晰,所以比较接受。


[此贴子已经被阿鸣于2002-8-21 15:16:58编辑过]

主要问题是现在我还不知道如何将这些理论应用到实际中!比如我现在算出了Flight time max和min值。可是下一步就不知道干什么了?
举个较简单的例子吧!比如一片带PCI接口的CPU(如Motorola的MPC8245),通过其PCI接口直接接一个网卡芯片(如RTL8139),这时如何进行此系统的PCI接口的时序分析?
这应该算是源同步时钟系统了。这时,Tco应该就没有了吧?即Tco=0。然后将其他参数带入时序公式,最后将Flight time的Max和Min值都算出来了。接下去该干什么?

接下去就是仿真你的走线,让你的实际走线的Flight time满足最大/最小Flight time之内。或者通过最大/最小Flight time经过仿真算出实际走线长度的范围,布线时不能超过这个范围就行了,但是计算长度时,不能用传输速率的公式,一定要仿真确定。

另外CPU(ICH)控制PCI好像不是源同步,其实就目前系统设计而言,可能利用源同步的主要是数据总线,并且有专门的源同步信号,而不是利用系统的时钟。对整个系统而言还是采用的是普通的时序,所有器件的时钟都是同步的,下图是Intel815ep控制芯片对时序的假设,所有的时钟理想的情况都是同步的零skew,但由于PCI的频率较低,时序窗口很大,所以允许ICH的时钟和PCI器件的时钟存在+/-2ns的偏差,计算时序的时候,应该是利用标准的时序约束方程,不是源同步:
[upload=jpg]uploadImages/200282118145540297.jpg[/upload]

谢谢!
我原来的想法可能都太过考虑传输线的长度对时序的影响程度了,实际上传输线的长度差可能对时序的影响只是很小的一个因素吧!
还有就是上面的这个例子,PCI如果在发送数据时,数据AD0~AD31和PCI CLK均由CPU输出,为什么不能认为时源同步时钟呢?另外,这时Tco应该就不存在了吧?

虽然时钟从CPU内部输出,其实其内部包含很多控制模块,包括控制内存的MCH,控制PCI的ICH等,也有PLL,DLL等,PLL将时钟发生器的时钟分为若干CLOCK输出控制外部器件,比如66MHz的PCI时钟,也可以再经过DLL分频为133MHz内存控制时钟,其内部的MCH和ICH等模块也是由系统时钟控制,因为PLL可以调节相位,只要调整反馈线的长度(可以看看Motorola的MPC8245芯片上是不是有个时钟信号反馈线?)就可以比较容易的保证到各个器件的时钟和系统时钟同步。所以虽然CLOCK是CPU产生的,但是其内部的电路还比较复杂,很多保证到各个控制模块的时钟同步都是在其内部实现的,我想对于低速的PCI控制,没有必要使用源同步技术,它一般都是针对频率较高(和时钟频率相同)的数据传输才会使用,毕竟源同步在芯片内部还要加一些数字延时器等功能模块,普通时序能满足要求的情况下何必再使用更高成本的新的技术。我到目前为止还没看到整个系统完全是源同步设计的例子,只看到数据总线使用源同步,而地址/控制线还都是普通时序系统,所以如果芯片中数据线是源同步传输,最显著的特点是有一个源同步时钟信号,但为了区别于系统时钟,这个信号一般不被称为时钟信号,而是数据读写探针(Data strope),这个DQS信号和数据信号同时产生,为了便于控制时序,在布线的时候要严格保持数据线和源同步时钟结构,线长都相同,即Flight time相同,由于Tco也基本一样,所以两个信号几乎是同相位的,只是在接收端将源同步时钟信号延迟1/4周期,这样就能保证在数据信号中央部位读取。如果除了AD0~AD31找不到类似ADS信号名的源同步时钟信号,那么我想这个肯定不是源同步时钟系统。
如果确信只是普通的时钟系统,那就容易了,时钟线只要调整长度保证和系统时钟同步就行,实际操作我猜应该是保证CPU上的时钟反馈线长和输出到PCI的时钟信号线长度大致相等,或参考Datasheet。以后考虑数据线的时序的时候就不用再关心数据线和时钟信号的线长差异了,而是和时钟周期有关。

[此贴子已经被阿鸣于2002-8-21 22:08:41编辑过]

[此贴子已经被阿鸣于2002-8-21 22:11:46编辑过]

是啊!CPU内部的一大堆电路我都没有考虑到。但是如果在做仿真的时候,芯片内部的这些信号流程、延时等等我们都不知道啊!
但是我如果知道了它的输出时序参数,应该就可以不必去管它内部的电路了吧?比如我现在知道了从PCI输出的时钟和数据线之间的时序参数(即它们时序关系的Max、Min值),而我还知道接收端的时序要求(即建立时间、保持时间的要求)。输出端到接收端之间没有任何驱动等器件,直接用Trace连接。这时,分析这个接口连接之间的时序关系的话,以上的时序公式就用不着了吧?这时影响时序的最大因素就是传输线的长度差了?是否可以通过以上给定的参数,计算出实际要求的传输线长度差?

所以首先要看各个控制芯片的datasheet或者Layout guideline等等,应该会提到时钟控制。比如上面说的815ep芯片,它就明显的提到时钟到ICH和PCI的目标延时为0,至于它是怎么实现时钟同步的我们根本不用管,PCI规范上肯定会告诉你时钟线应该多长的,我们就认为只要按照这个标准长度去布时钟线,就可以实现Driver和Receiver时钟同步,然后就应该采用标准的时序计算啊。
你说的“PCI输出的时钟和数据线之间的时序参数(即它们时序关系的Max、Min值),”应该指Tco,又知道了接收端的时序要求拿很简单啦,假设CPU的Tco为1ns~2ns,PCI器件的Tco为1ns~5ns,PCI器件接受端需要的建立时间为3ns,保持时间为2ns,而控制器作为接受端是建立时间为2ns,保持时间为1ns,时钟周期为15ns(66MHz)暂时不考虑时钟skew,jitter和串扰影响,则分为两个过程(数据线是双向传输的)计算:
1.CPU-->CI,
Tfight_max=15-Tco_max(CPU)-Tsetup_require(PCI)=15-2-3=10ns,
Tfight_min=Thold_require(PCI)-Tco_min(CPU)=2-1=1ns
2.PCI-->CPU
Tfight_max=15-Tco_max(PCI)-Tsetup_require(CPU)=15-5-2=8ns,
Tfight_min=Thold_require(CPU)-Tco_min(PCI)=1-1=0ns
最终的Fight time(max)取两个中最小的8ns,Flight time(min)取最大的1ns,所以得到约束条件为1ns~8之间,然后通过仿真得到实际的线长约束。如果考虑到时钟的偏差,比如PCI时钟可能有+/-2ns的skew,则约束长度被进一步限制为2(0+2)~6(8-2)ns,如果再考虑到其它干扰因素影响大概1ns,则最大/最小flight time只能为3~5ns。这里算出的是实际的传输线的总的延时(包含上升时间的影响),而不是和时钟线的长度差。

最后算出来的3~5ns的传输线总延时。为什么还有最小值3ns呢?难道传输线总延时小于3ns还不行?
这个时序问题确实很难理解!现在渐渐地有些明白,但最好还是再搞一些实例进行仿真、分析以后可能会更明白些吧!再此多谢阿鸣给予的大力帮助!谢谢!

这是考虑的很保守的情况,考虑到时钟偏差很大,实际不会有这么大,但肯定有个最小值,这是保证有足够的保持时间裕量。所以说走线不能太长也不能太短。

哇!几位高手的讲解真是精彩,不过我还是看得一头雾水!看来我还得加把劲.

确实很精彩,慢慢消化

天啊!象在看天书
我要啃书去了

好帖子

应该顶上来

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top