EEPW论坛

 源同步接口的时序模型

         自从对时序分析理论有深入学习以后，回头看看过去的一些设计中，其实还是存在不少问题的。重新拿起之前在VXP306板子上做的三星的K4S641632 SDRAM做的一些测试（这块板子的电源芯片烧了，一直没买到芯片换，只能闲置着了），后来移植到了自己做的EPM570板子上了，因为之前刚做好的时候测试，一直发现个“奇怪”的问题，也就是数据收发会间隔的在高位出现“0”，似乎有一定的规律，时间忙那块板子停下快半年没动了。现在忽然想拿它做测试好好分析一些SDRAM的时序。所以就有了下文。

         这个EPM570是MAX II中资源较少的，但是做SDRAM的封装还是可以凑和的。不够因为我在里面做了一个数据写模块，串口发模块，资源占用也超了80%，这是不利因素之一。二是MAX II系列CPLD不支持Fast input/output register，也没有内部的PLL，所以在特权同学的《读SRAM时序约束分析》中使用的EPM240是不足以胜任这样的“快速”存储器操作的（但是是用的50M的速率，后来根据系统状态妥协了改成25M），这个EPM570也有同样的劣势。但是实践上以后可以换器件（或者在Quartus II换器件分析），理论一定要先行。

         此外，特权同学找来了之前细读过的altera官方提供的应用笔记AN433，《Constraining and Analyzing Source-Synchronous Interfaces》，和这个应用笔记相对应的在altera官方网站的培训教程里你可以找到英文的视频版本。特权同学都认真的学习过，感兴趣的朋友可以看一下，呵呵，讲的远比我详细透彻。特权同学只是希望拿个SDRAM模型做个具体问题具体分析的范例。

源同步接口时序模型

         所谓源同步接口的概念是指与FPGA接口的外部器件的数据源和时钟源一样都是来自FPGA内部。一般异步RAM（SRAM）的读写由WE#,OE#控制，和数据地址有一定的时序要求，但是个人感觉建模上好像不是和源同步接口很吻合，因为我们实际设计中很难把WE#,OE#信号当时钟控制。而典型的源同步接口当属SDRAM，很经典的数据和时钟接口控制。

         上面就是一个源同步接口的模型，一般我们假定FPGA是Transmitter。这个Clock在FPGA内部的走线或延时是可以根据设计需要进行调整的，最方便快捷而且高效稳定的调整当属PLL。而数据和时钟的关系一般是中心对齐方式，如下：

         上图是单时钟沿采样模型（SDR SDRAM），下图是时钟双沿采样模型（DDR SDRAM）。也就是说，对于接收方而言，它一般是在Clock的上升沿或者下降沿采样data总线。如果有些器件的时序是边沿对齐（即数据和时钟同时变化），那么这个器件一定是在内部做了一些时钟的偏移工作，最终采样时刻的clock\data关系一定是中心对齐的模型。

         关于源同步接口的时序约束一般有三种：

1.       时钟clock约束；

2.       IO的input / output delay约束；

3.       时序例外。

（这里先假设你对SDRAM的接口和操作有一定的了解。具体可以参考我们分析的SDRAM芯片K4S641632的datasheet。）

时钟约束在我们的SDRAM模型中针对的是SDRAM的输入时钟sdr_clk，IO口的约束主要包括地址总线sdr_ab、数据总线sdr_db以及块地址信号sdr_bank，还有一些控制接口如sdr_cs_n,sdr_we_n,sdr_ras_n,sdr_cas_n；而时序例外我想对于SDRAM时钟有效信号sdr_cke除了上电等待的200us是低电平，其它时候都拉高了，所以可以设置为false路径。其实对于我的设计中sdr_cs_n也和sdr_cke一样，只有上电时等待的200us内为高（无效），此后一直出于片选状态，所以也可以设置为false路径。当然了设置为false路径我也必须充分考虑这个路径在跳变的那一个状态如果时序违规（即超出一个时钟周期），那么会不会对系统的性能造成影响。如果会，那么它就不应该是flase路径，但是特权同学分析了下，发现不存在这样的问题。设置flase路径注意是让实现工具在布局布线时不考虑这个路径，那么在同等条件下，就可以把一些走线资源让给关键路径，帮助达到时序收敛。说白了，时序例外无非就是在允许的条件下放松时序要求，从而整体上提高时序性能。

         关于源同步接口的分析方法，altera介绍了以系统为中心的方法和以FPGA为中心的方法。以系统为中心的分析，注意是针对FPGA与外部器件接口，外部器件的时序以及PCB板的走线延时等参数都明确的情况，例如我们的SDRAM接口设计宜采用此方法分析。而以FPGA为中心的分析方法是在假设外部与FPGA接口的器件的任何参数你不明确的情况下，来你来做时序约束分析，这个方法适合于让你来设计诸如SDRAM器件本身。

         下面分析的方法是以系统为中心。

         中央对齐方式的建立时间时序分析模型如下，实线为同沿传输分析，虚线为异沿传输分析。

         中央对齐方式的保持时间时序分析模型如下，实线为同沿传输分析，虚线为异沿传输分析。

         一般而言，如果你的设计中只采用同沿传输方式，那么你必须对异沿传输方式做一个false的例外约束；而相反的，如果你的设计中只采用异沿传输方式，那么你必须对同沿传输方式做一个false的例外约束。对于我的设计中，需要对异沿传输方式做一个false例外。

源同步输出

         时钟的产生方式有很多，上面也介绍过，比较稳定可控的是PLL时钟，或者内部逻辑比如状态机等产生的时钟，再或者直接使用系统输入时钟（正向或者反向）。该设计中由于器件所限，只能采取将输入时钟方向的方式产生SDRAM的时钟。基本的路径模型如下：

         时钟的约束，包括creat clock/creat generated clock等，具体参考特权同学以前的博文。而我们的sdr_clk时钟是FPGA系统主时钟的反向，所以可以做如下约束：

         不知道为什么，如果用gengerated clock命令产生的以clk为源时钟的生成时钟TimeQuest总是给出警告，认为该语句无效，可能是因为这个sdr_sdram与clk只是一个逻辑取反的关系，无法作为衍生时钟的关系。所以特权同学只能使用creat clock命令生成一个rise time="10",fall time="20"的20ns的时钟。

create_clock -name {sys_clk} -period 20.000 -waveform { 0.000 10.000 } [get_ports {clk}]

create_clock -name {sdr_clk} -period 20.000 -waveform { 10.000 20.000 } [get_ports {sdram_clk}]

时序分析中涉及的一些output delay的计算公式：

Output max delay = max trace delay for data + tsu of external device – min trace delay for clock

Output min delay = min trace delay for data –th of external device – max trace delay for clock

         这些公式的具体分析这里不提了，可以参考官方的相关文档或者特权同学关于timequest的博文。Output max delay主要用于setup时间分析，而output min delay主要用于hold时间分析。

         由于output clock（作为SDRAM时钟）是data clk（FPGA输入时钟）的反向，那么这个output clk除了有一定的逻辑延时外，加上reg2pin的延时，那么最后在输出端口相当于下面的模型了。因为SDRAM的数据锁存等操作还是使用的sdr_clk的上升沿，所以对于output delay的时序分析中launch edge到latch edge应该如下的红实线所示了。

         由于使用sdr_clk的latch edge无法得到想要clock network latency，所以使用chip planner查看了从sys_clk到sdr_clk的pin2pin的延时。

         在SDC中添加了该时钟网络延时：

set_clock_latency -source   2.425 [get_clocks {sdr_clk}]

那么接下来的时序收敛与否就在于查看时序分析报告，如果这些SDRAM相关的setup slack和hold slack都是正值，那么说明你的SDRAM控制所需要的建立保持时间是满足要求的。但是一般最理想的状态是setup slack和hold slack保持平衡，这样的对于有效的数据采样窗口是很有利的。尤其对于高速接口更是如此，至于低速接口也许这个slack的要求低一些。为了保持两个slack的平衡，我们一般会调整SDRAM的时钟sdr_clk以到达我们的需要。

源同步输入

         Altera的介绍里说明的是这样一个源同步输入的模型，似乎时钟是由外部信号驱动的，但是我们的SDRAM模型中不是这样，在FPGA内部锁存数据时使用的还是FPGA内部的主时钟clk，但是其分析的过程其实和之前特权同学的SRAM里的差不多，具体就不讨论了。