首页资源分类FPGA/CPLD > Riple - TimeQuest一定要搞定

Riple - TimeQuest一定要搞定

已有 445526个资源

下载专区

FPGA/CPLD热门资源

本周本月全部

文档信息举报收藏

标    签:RipleTimeQuest一定要搞定

分    享:

文档简介

Riple - TimeQuest一定要搞定

文档预览

TimeQuest 一定要搞定 Riple 著 http://blog.ednchina.com//14956/category.aspx .COM 缺氧® 整理 一 为什么一定要搞定 最近一段时间以来一直在尝试使用 TimeQuest。胡乱配置了一通,屡屡失败。于是下定决心,从基本 概念开始,力争把 TimeQuest 这个简化版的 PrimeTime 搞定。 时序分析在 ASIC 设计中的重要性毋须多说(我也不甚了解)。在 FPGA 设计中,很少进行细致全面的 时序约束和分析,Fmax 是最常见也往往是一个设计唯一的约束。这一方面是由 FPGA 的特殊结构决定的, 另一方面也是由于缺乏好用的工具造成的。好的时序约束可以指导布局布线工具进行权衡,获得最优的器 件性能,使设计代码最大可能的反映设计者的设计意图。 花些功夫在静态时序分析上既可以保证设计质量,也可以促使设计者再认识自己的代码。这后一点,对 于我们这些逻辑设计初学者来说,尤为重要。从门级(在 Altera 的 FPGA 器件中是 LE 级)再认识自己的 代码,可以更深入地体会语言的特点,也可以更深入地理解综合工具对语言的处理,对于设计能力的提高 帮助很大。 TimeQuest 是 Altera 在 6.0 版的软件中加入的具备 ASIC 设计风格的静态时序分析(STA)工具。通过 初步试用和观看网络教程,我感觉 TimeQuest 确实比 Timng Analyzer 功能强大一些,而且使用界面比较 友好,易于进行深入的时序约束和结果分析。 TimeQuest 采用 Synopsys Design Constraints(SDC)文件格式作为时序约束输入,不同于 Timing Analyzer 采用的 Quartus Settings File(QSF)约束文件。这正是 TimeQuest 的优点:采用行业通用的约 束语言而不是专有语言,有利于设计约束从 FPGA 向 ASIC 设计流程迁移;有利于创建更细致深入的约束 条件。 对于时序分析,我刚刚入门;采用 TimeQuest 进行约束输入也是第一次。在这一系列的博客里面,我 计划记录自己在学习中获得的知识要点和实践中遇到的各种问题,既是自己的学习笔记,也希望对他人的 工作有所助益,更希望大家提出批评意见,共同进步。 二 时序基本概念 以下内容译自 Quartus II Version 7.0 Handbook, Volume 3:Verification 的 6-13:Timing Analysis Overview 部分。 TimeQuest 需要读入布局布线后的网表才能进行时序分析。读入的网表是由以下一系列的基本单元构成 的: 1. Cells:Altera 器件中的基本结构单元。LE 可以看作是 Cell。 2. Pins:Cell 的输入输出端口。可以认为是 LE 的输入输出端口。注意:这里的 Pins 不包括器件的输入 输出引脚,代之以输入引脚对应 LE 的输出端口和输出引脚对应 LE 的输入端口。 3. Nets:同一个 Cell 中,从输入 Pin 到输出 Pin 经过的逻辑。特别注意:网表中连接两个相邻 Cell 的 连线不被看作 Net,被看作同一个点,等价于 Cell 的 Pin。还要注意:虽然连接两个相邻 Cell 的连线不被 看作 Net,但是这个连线还是有其物理意义的,等价于 Altera 器件中一段布线逻辑,会引入一定的延迟(IC, Inter-Cell)。 4. Ports:顶层逻辑的输入输出端口。对应已经分配的器件引脚。 5. Clocks:约束文件中指定的时钟类型的 Pin。不仅指时钟输入引脚。 6. Keepers:泛指 Port 和寄存器类型的 Cell。 7. Nodes:范围更大的一个概念,可能是上述几种类型的组合,还可能不能穷尽上述几种类型。 下面这幅图给出了一个时序网表的示例,展示了基本单元中的一部分。 有了网表的基本单元,我们就可以描述 TimeQuest 进行时序分析的对象:Edges。 Edges:Port-Pin,Pin-Pin,Pin-Port 的连接关系都是 Edges。注意,这里的 Pin-Pin 连接关系既包括 Cell 内部的连接(Net),也包括相邻 Cell 外部的 Pin-Pin 连接。 Edges 根据起止路径分为三类。 1. Clock paths:从 Clock Port 或内部生成的 clock Pin 到寄存器 Cell 的时钟输入 Pin。 2. Data paths:从输入 Port 到寄存器 Cell 的数据输入 Pin,或从寄存器 Cell 的数据输出 Pin 到另一个 寄存器 Cell 的数据输入 Pin。 3. Asynchronous paths:从输入 Port 到寄存器 Cell 的异步输入 Pin,或从寄存器 Cell 的数据输出 Pin 到另一个寄存器 Cell 的异步输入 Pin。 下面这幅图给出了三种不同的 Edges。 还要注意这样一组概念,这里的 edge 指的是时钟沿: 1. Launch Edge:前级寄存器发送数据对应的时钟沿,是时序分析的起点。 2. Latch Edge:后级寄存器捕获数据对应的时钟沿,是时序分析的终点。 下面这幅图给出了发送、捕获时钟沿的示意图。 有了上述的诸多概念,我们就可以得到时序分析公式的基本项了: 1. Data Arrival Time:Launch Edge + 前级寄存器 Clock path 的延时 + 前级寄存器 Cell 从时钟 Pin 到数据输出 Pin 的 Net 延时(uTco) + Data path 的延时。 2. Data Required Time:Latch Edge + 后级寄存器 Clock path 的延时(+ uTh)或(- uTsu)。 3. Clock Arrival Time:Latch Edge + 后级寄存器 Clock path 的延时。 三 时序分析基本公式 以下内容译自 Quartus II Version 7.0 Handbook, Volume 3:Verification 的 6-28:Clock Analysis 部分。 TimeQuest 静态时序分析的对象包括:寄存器和寄存器之间的路径、I/O 之间、I/O 和寄存器之间的路 径、异步复位和寄存器之间的路径。TimeQuest 根据 Data Arrival Time 和 Data Required Time 计算出时 序余量(Slack)。当时序余量为负值时,就发生了时序违规(Timing Violation)。 需要特别指出的一点是:由于时序分析是针对时钟驱动的电路进行的,所以分析的对象一定是“寄存 器-寄存器”对。在分析涉及到 I/O 的时序关系对时,看似缺少一个寄存器分析对象,构不成“寄存器-寄 存器”对,其实是穿过 FPGA 的 I/O 引脚,在 FPGA 外部虚拟了一个寄存器作为分析对象。 一、 建立时间(Setup Time)检查: 遵循的原则是信号从 Launch edge 开始计时,经过一系列的时序路径,到达后级寄存器的数据输入 Pin 的速度不能太慢,时间不能太长,否则会侵占后级寄存器数据输入 Pin 相对于 Latch edge 的建立时间。 刚好满足后级寄存器建立时间的数据到达时间是 Data Required Time(相对于 Latch edge 计算),实际 的数据到达时间是 Data Arrival Time(相对于 Launch edge 计算)。显然,在建立时间检查中,Data Arrival Time 要小于 Data Required Time,否则就会造成建立时间违规。也就是说,Data Required Time 是 Data Arrival Time 的最大值。二者之差就是建立时间的时序余量。 1)寄存器-寄存器(Register-to-Register)路径检查: Clock Setup Slack = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay Source Register +μtco + Register-to-Register Delay Data Required Time = Clock Arrival Time – μtsu – Setup Uncertainty Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 2)输入引脚-寄存器(Pin-to-Register)路径检查: Clock Setup Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + Input Maximum Delay of Pin + Pin-to-Register Delay Data Required Time = Clock Arrival Time – μtsu Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 3) 寄存器-输出引脚(Register-to-Pin)路径检查: Clock Setup Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtco + Register-to-Pin Delay Data Required Time = Clock Arrival Time – Output Maximum Delay of Pin Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 从上面三组公式可以看出:Data Arrival Time 的前两项是相同的;Data Required Time 的第一项是相 同的;Clock Arrival Time 的公式是相同的。 所以,第一组公式可以归纳如下: Clock Setup Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = 时钟到达前级寄存器的时刻 + 前级寄存器时钟到后级寄存器数据输入的延迟 Data Required Time = 时钟到达后级寄存器的时刻 – 后级寄存器的建立时间 其中,后两个公式的第二项在其他情况下适当修改即可。 这就和一些书中讲到时序分析时采用的公式一致了。 report_timing -from [get_registers reg1] -to [get_registers reg2] -setup -npaths 1 -panel_name "Report Timing" 二、 保持时间(Hold Time)检查: 遵循的原则是信号从 Launch edge 开始计时,经过一系列的时序路径,到达后级寄存器的数据输入 Pin 的速度不能太快,时间不能太短,否则会侵占后级寄存器数据输入 Pin 相对于上一个 Latch edge 的保 持时间。刚好满足后级寄存器保持时间的数据到达时间是 Data Required Time(相对于 Latch edge 计算), 实际的数据到达时间是 Data Arrival Time(相对于 Launch edge 计算)。显然,在保持时间检查中,Data Arrival Time 要大于 Data Required Time,否则就会造成保持时间违规。也就是说,Data Required Time 是 Data Arrival Time 的最小值。二者之差就是保持时间的时序余量。 相对于建立时间检查,保持时间检查稍微难懂一些。二者都是同步逻辑设计中对同一个规则的不同解 释:当前时钟沿发出的数据要在下一个时钟沿被正确捕获,不能晚,也不能早。晚了,会造成下一个时钟 沿的建立时间违规,当前时钟沿发送的数据不能被下一个时钟沿捕获;早了,会造成上一个时钟沿发送的 数据保持时间违规,上一个时钟沿发送的数据不能被当前时钟沿正确捕获。 二者在计算公式上的区别在于 Slack 计算公式中减数与被减数关系。 1)寄存器-寄存器(Register-to-Register)路径检查: Clock Hold Slack = Data Arrival Time – Data Required Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register +μtCO + Register to Register Delay Data Required Time = Clock Arrival Time + μtH + Hold Uncertainty Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 2)输入引脚-寄存器(Pin-to-Register)路径检查: Clock Setup Slack Time = Data Arrival Time – Data Required Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + Input Minimum Delay of Pin + Pin to Register Delay Data Required Time = Clock Arrival Time + μtH Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 3) 寄存器-输出引脚(Register-to-Pin)路径检查: Clock Setup Slack Time = Data Arrival Time – Data Required Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtCO + Register to Pin Delay Data Required Time = Clock Arrival Time – Output Minimum Delay of Pin Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 需要注意的是,上面公式中的 Latch Edge 实际对应的是上一个 Launch Edge。所以,当 Launch Clock 和 Latch Clock 是同一个时钟时,上述公式中的 Latch Edge 等于 0;当前级和后级时钟不同时,还需要具 体计算 Latch Edge 的取值。 report_timing -from [get_registers reg1] -to [get_registers reg2] -hold -npaths 1 -panel_name "Report Timing" 三、 恢复时间(Recovery Time)检查: 遵循的原则是异步控制信号变化的时刻不能介于寄存器的 Latch edge 和相应的建立时间之间,否则会 导致寄存器的建立时间违规,数据输出进入亚稳态。即从前级寄存器的 Launch edge 开始计时,经过一系列 的时序路径,前级寄存器数据输出到达后级寄存器异步控制 Pin 的速度不能太慢,时间不能太长,否则会 破坏后级寄存器在 Latch edge 的数据建立时间。该检查主要应用于异步控制信号由有效电平向无效电平转 换的时刻,在该时刻破坏数据建立时间会导致亚稳态;在异步控制信号由无效电平向有效电平转换的时刻 破坏数据的建立时间不会造成亚稳态。 从上述定义,可以得到和建立时间检查类似的公式。 1)寄存器-寄存器(Register-to-Register)路径检查: Recovery Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtCO + Register to Register Delay Data Required Time = Clock Arrival Time – μtSU Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 2)输入引脚-寄存器(Pin-to-Register)路径检查: Recovery Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Maximum Input Delay + Port to Register Delay Data Required Time = Clock Arrival Time – μtSU Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register report_timing -from [get_ports async_rst] -to [get_registers reg2] -recovery -npaths 1 -panel_name "Report Timing" 四、 移除时间(Removal Time)检查: 遵循的原则是异步控制信号变化的时刻不能介于寄存器的 Latch edge 和相应的保持时间之间,否则会 导致寄存器的保持时间违规,数据输出进入亚稳态。即从前级寄存器的 Launch edge 开始计时,经过一系列 的时序路径,前级寄存器数据输出到达后级寄存器异步控制 Pin 的速度不能太快,时间不能太短,否则会 破坏后级寄存器在上一个 Latch edge 的数据保持时间。该检查主要应用于异步控制信号由有效电平向无效 电平转换的时刻,在该时刻破坏数据保持时间会导致亚稳态;在异步控制信号由无效电平向有效电平转换 的时刻破坏数据的保持时间不会造成亚稳态。 从上述定义,可以得到和保持时间检查类似的公式。 1)寄存器-寄存器(Register-to-Register)路径检查: Removal Slack Time = Data Arrival Time – Data Required Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtCO of Source Register + Register to Register Delay Data Required Time = Clock Arrival Time + μtH Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 2)输入引脚-寄存器(Pin-to-Register)路径检查: Removal Slack Time = Data Arrival Time – Data Required Time Data Arrival Time = Launch Edge + Input Minimum Delay of Pin + Minimum Pin to Register Delay Data Required Time = Clock Arrival Time + μtH Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register report_timing -from [get_ports async_rst] -to [get_registers reg2] -removal -npaths 1 -panel_name "Report Timing" 五、多周期路径(Multicycle Paths)检查: 在上述的建立、保持时间检查中,都假设数据从 Launch edge 开始发送,在 Latch edge 被捕获;Launch edge 和 Latch edge 是相邻最近的一对时钟沿。在多周期路径检查中,仍然采用 Launch edge 和 Latch edge 的概念;但是 Launch edge 和 Latch edge 不再是相邻的一对时钟沿,而是间隔一定时钟周期的一对时钟 沿,间隔的时钟周期个数由用户指定。 在同步逻辑设计中,通常都是按照单周期关系考虑数据路径的。但是往往存在这样的情况:一些数据 不需要在下一个时钟周期就稳定下来,可能在数据发送后几个时钟周期之后才起作用;一些数据经过的路 径太复杂,延时太大,不可能在下一个时钟周期稳定下来,必须要在数据发送后数个时钟周期之后才能被 采用。针对这两种情况,设计者的设计意图都是:数据的有效期在以 Lauch edge 为起始的数个时钟周期 之后的 Latch edge。这一设计意图不能够被时序分析工具猜度出来,必须由设计者在时序约束中指定;否 则,时序约束工具会按照单周期路径检查的方式执行,往往会误报出时序违规。 不设置多周期路径约束的后果有两种:一是按照单周期路径检查的结果,虚报时序违规;二是导致布 局布线工具按照单周期路径的方式执行,虽然满足了时序规范,但是过分优化了本应该多个周期完成的操 作,造成过约束(Over-Constrain)。过约束会侵占本应该让位于其他逻辑的布局布线资源,有可能造成 其他关键路径的时序违规或时序余量变小。 在多周期路径的建立时间(Setup Time)检查中,TimeQuest 会按照用户指定的周期数延长 Data Required Time,放松对相应数据路径的时序约束,从而得到正确的时序余量计算结果;在保持时间(Hold Time)检查中,TimeQuest 也会相应地延长 Data Required Time,不再按照单周期路径的分析方式执行(不 再采用 Launch edge 最近的时钟沿,而是采用 Latch edge 最近的时钟沿),这就需要用户指定保持时间 对应的多周期个数。TimeQuest 计算 Hold Time 的缺省公式等同于 PrimeTime。PrimeTime 会采用建立时 间检查对应时钟沿的前一个时钟沿进行保持时间检查,并多会造成保持时间检查违规,需要用户指定保持 时间检查对应的时钟沿为 Launch edge 最近的时钟沿。(西电出版社《数字 IC 系统设计》p189) TimeQuest 缺省的 Hold Time 检查公式是需要用户修改的——针对 Setup Time 多周期路径的设置也 会影响到 Hold Time 的检查。究其原因,多周期路径是为了解决信号传播太慢的问题,慢到一个周期都不 够,所以要把 Setup Time 的检查往后推几个周期——扩大 Setup Time 检查的时间窗口。而 Hold Time 检 查信号是否传播得太快,如果把检查时刻往后推,就缩小了 Hold Time 检查的时间窗口。 ―信号跳变抵达窗口‖:对 Latch 寄存器来说,从 previous 时钟对应的 Hold Time 开始,到 current 时 钟对应的 Setup Time 结束。 ―信号电平采样窗口‖:对 Latch 寄存器来说,从 current 时钟对应的 Setup Time 开始,到 current 时 钟对应的 Hold Time 结束。 Launch 寄存器必须保证驱动的信号跳变到达 Latch 寄存器的时刻恰好处于―信号跳变抵达窗口‖内,才 能保证不破坏 Latch 寄存器的―信号电平采样窗口‖。 时序检查的目的就是确认信号跳变发生在―信号跳变抵达窗口‖内,而不会发生在―信号电平采样窗口‖ 内。 多周期路径的设置是通过延后 Setup Time 检查的时刻,扩大了―信号跳变抵达窗口‖,放松了时序约束。 通过窗口的概念,也很容易理解延后 Hold Time,就会缩小―信号跳变抵达窗口‖。 背景资料: Specify multicycle set-up paths constraints Specifying multicycle hold requirements constraints 随文附上一个 ,可以采用上面的命令执行并观察结果。该实例改编自 Altera 的 multicycle_exception。 该实例由两个级联寄存器构成。 学习时序分析一定要学会察看 Technology Map Viewer。 四 取值为负数的建立时间 在前面的一篇文章中,给出了建立时间检查的基本公式: 1)寄存器-寄存器(Register-to-Register)路径检查: Clock Setup Slack = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay Source Register +μtco + Register-to-Register Delay Data Required Time = Clock Arrival Time – μtsu – Setup Uncertainty Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 2)输入引脚-寄存器(Pin-to-Register)路径检查: Clock Setup Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + Input Maximum Delay of Pin + Pin-to-Register Delay Data Required Time = Clock Arrival Time – μtsu Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 3) 寄存器-输出引脚(Register-to-Pin)路径检查: Clock Setup Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtco + Register-to-Pin Delay Data Required Time = Clock Arrival Time – Output Maximum Delay of Pin Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register 在前两组公式中,Data Required Time 计算公式的第二项都是 -uTsu。 但是在 TimeQuest 中对两级级联寄存器的时序分析中,执行 report_timing -from [get_ports data_in] -to [get_registers reg1] -setup -npaths 1 -panel_name "Report Timing"却得到了如下图 所示的结果,请注意图中 Data Required Time 的第三行中 reg1 的 uTsu 取值: 在 Incr 一列中,reg1 的 uTsu 取值为 0.036ns,在计算公式中作为正数值计入了 Data Required Time 的结果中。 发现这一现象以后,经过分析,我认为有两种可能: 1. 计算公式正确,但是 TimeQuest 计算错误。 2. 计算公式正确,uTsu 的真实取值是负数,在上图中负负为正,TimeQuest 计算正确。 我一直倾向于后一种可能,毕竟 TimeQuest 是 Altera 的一个招牌工具,这样明显的错误早就该解决 了。但是从 Setup 时间的定义上看,uTsu 又不可能是负值。 后一种可能虽然更合理,但是又没有充足的证据证明这一点,这一数据是 Altera 给定的,原值是正是 负无从知晓,在 help 里查也没查到,所以我一直对于 TimeQuest 存有怀疑。 直到今天,我偶然想起前些天计算一个输出引脚的建立时间余量时,在同样的位置看到过一个取值为 负的数据。这样看来,Incr 一列中,不是只能有正数值,也可以有负数值。 如果这个负值是我指定的,在 Incr 一列中出现负值就不奇怪了;但是我很清楚地记得,没有什么特殊 条件导致我会在时序约束中采用负值。那么,这个负号应该是 TimeQuest 在计算中刻意加入的。负号可以 加入,自然也可以去除,上图中 uTsu 的负号就可能是 TimeQuest 去除的。 下面,让我们通过输出引脚的建立时间检查(公式 3)来证明一下: 仍然以两级级联寄存器为例,计算公式重写如下: 3) 寄存器-输出引脚(Register-to-Pin)路径检查: Clock Setup Slack Time = Data Required Time – Data Arrival Time Data Arrival Time = Launch Edge + Clock Network Delay to Source Register + μtco + Register-to-Pin Delay Data Required Time = Clock Arrival Time – Output Maximum Delay of Pin Clock Arrival Time = Latch Edge + Clock Network Delay to Destination Register Data Required Time 中第二项是可以人为指定的。我们通过 set_output_delay -add_delay -max -clock clk_in 2.000 [get_ports data_out]来指定 Output Maximum Delay of Pin 的取值为 2ns。 执行 TimeQuest 建立时间检查命令 report_timing -from [get_registers reg2] -to [get_ports data_out] -setup -npaths 1 -panel_name "Report Timing"。得到如下图所示的结果: 可以看到,我们在时序约束中指定的输出引脚延时 2ns 被作为负数加入了 Data Required Time 的计 算公式中。这样一来,TimeQuest 的计算和上面的计算公式就一致了。 同理,在 reg1 的建立时间余量计算中,uTsu 原本是负值,经过计算公式中的一次负号变换,就作为 正数加入了 Data Required Time 的计算公式中。 这样看来,在 Altera 的器件中,uTsu 是作为负值提供给 TimeQuest 进行计算的。这一 负值是器件本身的特性,还是为了补偿计算误差的需要有意加入的,还需要进一步的考证。 相关链接: 请问负的 hold 时间和建立时间一般由什么引起的? 优化逻辑分析仪对高速系统的建立/保持时间的调节 google 上搜索 negative setup time could anybody give me a clear picture of negative setup and negative hold ? DAtum [Timinganalysis] Negative setup and hold Negative setup and Negative hold Calculating the setup and hold times at the pins of a chip 很好的公式推导 Negative setup time and postive hold time? Method of HDL simulation considering hard macro core with negative setup/hold time 上午给 Altera 发了一个 Service Request,下午就得到了回复: 但是这个回复没有解决我的疑惑,还要继续问: 隔了一个周末,正当我为自己是否说错了话而忐忑时,回复出来了。 感谢 Roger,TimeQuest 在这一点上是没错的。负的建立时间是特定时序模型的特点,模型在器件上不 同的位置具有不同的特征参数。负的建立时间和寄存器靠近引脚有关。我们不必关心,交给工具去处理好 了。 五 时序约束和分析流程 TimeQuest 的约束和分析流程是与 Quartus II 的编译流程紧密结合的。如下图所示: TimeQuest 进行约束和分析的对象都来自 Quartus II 编译流程各阶段的编译结果。二者对应关系如下: 1. 分析与解析 Start Analysis & Elaboration -> RTL Viewer Quartus II 编译的第一步是纯粹的―逻辑综合‖,虽然经过了逻辑优化,但是生成的数据库并不对应 FPGA 器件的物理结构,生成的网表中节点的名称也不与 FPGA 器件的 Cell 名称对应。由于 TimeQuest 进行约 束和分析的对象是 FPGA 器件的底层物理单元,所以这一步编译过程完成后不能进行 TimeQuest 时序约束 和分析。 这一步在 TimeQuest 操作流程中没有实际意义。 2. 分析与综合(与映射) Start Analysis & Synthesis -> Technology Map Viewer(Post-Mapping) -> Create Timing Netlist(Post-Map), Specify Timing Constraints, Early Timing Estimate 这一编译步骤的名称虽然是―分析与综合‖,但是在―综合‖后还进行了一步―映射‖(Mapping)。Start Analysis & Synthesis = Start Analysis & Elaboration + Mapping。这一步完成后生成的数据库已经对应了 FPGA 器件的物理结构,可以供 TimeQuest 进行时序约束之用。由于―映射‖过程实际是预先布局过程,―映 射‖后的数据库包含了 FPGA 底层 Cell 的位置信息和 Cell 本身的时序信息,TimeQuest 根据这一数据库生 成的时序网表中的节点与 FPGA 底层 Cell 是对应的。由于预先布局尚未执行时序驱动的布局和布线工作, 也没有读入引脚位置等约束信息,这时的网表不包含布线信息,而且布局结果也会在 P&R 后发生变化,所 以不能获得准确的时序分析结果。在这一步进行的时序分析是 Early Timing Estimate,只是根据 Cell 本身 的时序信息和由预布局结果得来的 Cell 之间的位置关系进行的―估计‖。 这一步在 TimeQuest 操作流程中的意义在于可以进行时序约束和时序预估。 3. 适配(P&R) Start Fitter -> Technology Map Viewer, Chip Planner -> Create Timing Netlist(Post-Fit), Generate Timing Reports 这一步骤的名称―适配‖对应的操作是―布局和布线‖(P&R)。这一步骤是在上一个步骤获得时序约束信 息后进行的,Fitter 会努力按照时序约束的要求进行布局和布线优化。这一步骤获得的数据库包含了 Cell 的位置、Cell 本身的时序信息和 Cell 之间连线资源的分布和时序信息,TimeQuest 根据这一数据库生成的 网表就是 FPGA 最终实现结果的时序网表,可以反映最终实现结果的时序特性。此时进行的时序分析才是 最准确的。 这一步在 TimeQuest 操作流程中的意义在于可以进行最终的时序分析,并检查适配结果是否满足了时 序约束的要求。(如文章开头引用的 Quartus II Help 文档给出的流程图所示,在这一步才执行时序约束也 是可以的,但是如果不指出在第 2 步就可以进行时序约束,会产生―先有鸡还是先有蛋‖的矛盾,这一点就 是 Altera 文档误导读者之处。此外,在这一步才执行时序约束会重复执行 P&R 操作,浪费编译时间。) 在上述流程的每一步中,都有 Netlist Viewer 与编译和时序分析的对应关系。根据这一对应关系,设计 者可以借助 Netlist Viewer 工具观察编译生成的网表,间接观察和分析 TimeQuest 生成的对应的时序网表。 Netlist Viewer 实现了 TimeQuest 时序约束对象的可视化。 在上述操作流程的最后一步,还可以通过 Chip Planner 直观察看设计在 FPGA 中的实现情况,并且与 TimeQuest 的时序分析报告一一对应。Chip Planner 实现了 TimeQuest 时序分析结果的可视化。 相关链接:在线观看 Chinese Version: Validating Performance with the TimeQuest Static Timing Analyzer,离线观看 Chinese Version: Validating Performance with the TimeQuest Static Timing Analyzer 关键路径中的时序分析工具对设计成败至关重要 附图:TimeQuest 操作流程。 六 图解 Setup Time 时序余量计算 一图胜千言。Quartus II 7.2 版的 TimeQuest Timing Analysis 工具中新添加了―波形察看‖功能,可以帮 助设计者更直观地理解特定路径上寄存器之间的时序关系。 对于时序分析初学者来说,理解时序分析的公式与实际器件的物理特性之间的对应关系是一大难点,这 一难点也是掌握时序分析方法的关键点。借助 TimeQuest 的 Waveform 视图,再结合 Quartus 的其他视图 工具,理解这一难点就容易多了。 下面就是一个简单的 Setup Time 时序分析的图解: 图一:查看 RTL Viewer。图中 start_sync 引脚是本设计的输入引脚。之所以命名为_sync,是因为在这 个简化了的局部的设计中,start_sync 虽然是 FPGA 的输入引脚,但是可以认为在 FPGA 外部驱动这一引 脚的电路是与本设计同步的。对于 start_sync 信号,只要设置适当的 input_delay 约束,就可以进行时序 分析。另外,在图中还有一个引脚是 ack_async,之所以命名为_async,是因为该引脚是一个异步输入引 脚,在 FPGA 外部驱动这一引脚的电路与本设计的时钟关系不确定。对于 ack_async 信号,没有必要进行 时序分析(需要设置 false_path 约束),而且还需要进行跨时钟域信号传播的两级同步处理。start_sync 是本示例时序分析的起点。 图二:查看 Technology Map Viewer。图中具有双层结构的模块是 FPGA 器件一个 Logic Cell 的示意图, 这个 Logic Cell 对应了设计中的 sreg.01 寄存器和其次态逻辑。从该图中可以看出,典型的 LC 由实现组合 逻辑的 LUT(内层框内图形)和实现时序逻辑的 REG(外层 D 触发器)构成。本文举例进行时序分析的 对象是从―FPGA 输入引脚 start_sync‖到―sreg.01 的 REG 寄存器 D 输入端‖之间的路径。 图三:查看 Chip Planner 视图。图中所示是 start_sync 所在的 I/O Cell 与 sreg.01 所在的 Logic Cell 之 间的 Inter-Cell 延时,该延时值为 3.940ns,在图六的时序分析计算公式中会引用。在图四和图五中分别给 出了 I/O Cell 和 Logic Cell 的内部视图。 图四:查看 start_sync 输入引脚的 I/O Cell。图中所示是 start_sync 所在的 I/O Cell 的 Resource Property Editor 视图。从图中可以看出,由于 FPGA 的 I/O 是可编程的,所以该 Cell 由输出电路和输入电路两部分 组成。图中蓝色部分的起点是引脚的 Pad 所在之处,Pad 的左边是输出电路,右边是输入电路。蓝色部分 是实际使用到的电路——start_sync 引脚的输入电路逻辑。这部分电路会引入一定的延时,在图六的时序 分析计算公式中会引用。 图五:查看 sreg.01 寄存器的 Logic Cell。图中所示是 sreg.01 所在的 Logic Cell 的 Resource Property Editor 视图。与图二相对应,该图中蓝色部分是实际使用到的电路——LUT + REG。其中四输入 LUT 部分 和 REG 之前的选择电路会引入延时,在图六的时序分析计算公式中会引用。 图六:查看 start_sync 输入引脚与 sreg.01 寄存器的 Report Setup Timing 结果。该图是在 TimeQuest 中执行 report_timing -from_clock {CLK} -to_clock {CLK} -from {start_sync} -to {try1:inst|sreg.01} -setup -npaths 10 -detail path_only -panel_name {Report Timing}命令得到的。从右上角开始,按照顺时针顺序 分为四个部分。第一象限列出了时序分析所需要的各项参数取值;第二象限是时序分析结果的统计数据; 第三象限是根据第一象限参数计算得到的时序分析结果;第四象限是波形图,详见图七。在该图中,我们 主要关心第一和第三象限的内容。 第一象限上半部分是 Data Arrival Path 各组成部分延时的详细列表。行 3 对应手工设置的 Input_delay, 2ns;行 4 对应 I/O Cell 内部电路的门延时,1.135ns;行 5 对应图三中示出的 I/O Cell 与 Logic Cell 之间 的 Inter-Cell 线延时,3.940ns;6 对应 Logic Cell 内部电路的门延时,0.238ns。(行 4、行 5、行 6 之和 组成了图七中的 Data Delay 时间) 第一象限下半部分是 Data Required Path 各组成部分延时的详细列表。行 1 对应 CLK 的周期,10ns; 行 2 对应时钟网络延时,2.389ns;行 4 对应 REG 的 Setup Time,0.029ns。该 Logic Cell 的建立时间是 一个正数值。 第三象限给出了该路径的 Setup Time Slack 的计算结果。由 Setup Time余量的计算公式(Data Required Time - Data Arrival Time)可以得出行 6(12.360ns)与行 5(7.313ns)之差为 Slack 计算结果:5.047ns。 图七:查看 start_sync 输入引脚与 sreg.01 寄存器的 Setup Time Slack 计算图解。该图示出了 start_sync 到 sreg.01 寄存器 D 输入端之间的时序关系。其中豆绿色部分是 Setup Time Slack,Data Required Time 由 Input Delay 和 Data Delay 组成,Data Arrival Time 由 Setup Relationship、Clock Delay 和 uTsu 组成。 这幅图清晰地示出了 Launch Edge 和 Latch Edge 的概念和相互关系,Data Required Time 和 Data Arrival Time 的计算和相互关系,还有 Clock Skew 对时序的影响,以及―正‖的 Setup Time 的特性。这幅图是对图 六中的 Timeing Report 的直观解释。 PS:在前面几篇关于 Timing Analysis 的文章中,我使用的 TimeQuest 工具还是 7.2 以前的版本,那时还 没有察看 waveform 的功能。那时虽然把时序分析结果的统计数据采用扇形图表示,但是对于理解时序分 析的原理没有什么太大的帮助。7.2 版的这一改进还是非常有用的。 七 由 QSF 生成 SDC QSF 是 Quartus Settings File 的缩写,包含了一个 Quartus 工程的所有约束,包括工程信息、器件信息、 引脚约束、编译约束和用于 Classic Timing Analyzer 的时序约束。 SDC 是 Synopsys Design Constraints 的缩写,该文件用于 TimeQuest Timing Analyzer 的时序约束和定 制报告。 在 TimeQuest 中把 Classic Timing Analyzer 的约束语句转换为 SDC 是很容易的。在 Constraints 菜单下, 执行 Generate SDC File from QSF 即可。 以 Quartus II 安装路径下的\qdesigns\fir_filter 项目为例,QSF 文件中关于时序约束的语句如下: # 约束 clk 为 100MHz 的时钟。 set_global_assignment -name FMAX_REQUIREMENT "100 MHz" -section_id clocka set_instance_assignment -name CLOCK_SETTINGS clocka -to clk # 约束 clkx2 为 clk 的二倍频时钟,相位偏移 0.5ns set_global_assignment -name BASED_ON_CLOCK_SETTINGS clocka -section_id clockb set_global_assignment -name DIVIDE_BASE_CLOCK_PERIOD_BY 2 -section_id clockb set_global_assignment -name OFFSET_FROM_BASE_CLOCK "500 ps" -section_id clockb set_instance_assignment -name CLOCK_SETTINGS clockb -to clkx2 # 约束所有从 clk 到 clkx2 的时序路径为 Multicycle,取值 2 set_instance_assignment -name MULTICYCLE 2 -from clk -to clkx2 由该组 QSF 约束转换得到的 SDC 约束如下: # Original Clock Setting Name: clocka create_clock -period "10.000 ns" \ -name {clk} {clk} # Original Clock Setting Name: clockb create_generated_clock -multiply_by 2 -offset "0.500 ns" \ -source clk \ -name {clkx2} \ {clkx2} # ** Multicycles # QSF: -name MULTICYCLE 2 -from clk -to clkx2 set_multicycle_path -end -setup -from [get_clocks {clk}] -to [get_clocks {clkx2}] 2 set_multicycle_path -end -hold -from [get_clocks {clk}] -to [get_clocks {clkx2}] 1 从上面的例子可以看出,SDC 比 QSF 简洁了些,在 Multicycle 的约束上也清晰明确了些。 八 图解 Multicycle Path 时序余量计算 QSF 是 Quartus Settings File 的缩写,包含了一个 Quartus 工程的所有约束,包括工程信息、器件信息、 引脚约束、编译约束和用于 Classic Timing Analyzer 的时序约束。 SDC 是 Synopsys Design Constraints 的缩写,该文件用于 TimeQuest Timing Analyzer 的时序约束和定 制报告。 在 TimeQuest 中把 Classic Timing Analyzer 的约束语句转换为 SDC 是很容易的。在 Constraints 菜单下, 执行 Generate SDC File from QSF 即可。 以 Quartus II 安装路径下的\qdesigns\fir_filter 项目为例,QSF 文件中关于时序约束的语句如下: # 约束 clk 为 100MHz 的时钟。 set_global_assignment -name FMAX_REQUIREMENT "100 MHz" -section_id clocka set_instance_assignment -name CLOCK_SETTINGS clocka -to clk # 约束 clkx2 为 clk 的二倍频时钟,相位偏移 0.5ns set_global_assignment -name BASED_ON_CLOCK_SETTINGS clocka -section_id clockb set_global_assignment -name DIVIDE_BASE_CLOCK_PERIOD_BY 2 -section_id clockb set_global_assignment -name OFFSET_FROM_BASE_CLOCK "500 ps" -section_id clockb set_instance_assignment -name CLOCK_SETTINGS clockb -to clkx2 # 约束所有从 clk 到 clkx2 的时序路径为 Multicycle,取值 2 set_instance_assignment -name MULTICYCLE 2 -from clk -to clkx2 由该组 QSF 约束转换得到的 SDC 约束如下: # Original Clock Setting Name: clocka create_clock -period "10.000 ns" \ -name {clk} {clk} # Original Clock Setting Name: clockb create_generated_clock -multiply_by 2 -offset "0.500 ns" \ -source clk \ -name {clkx2} \ {clkx2} # ** Multicycles # QSF: -name MULTICYCLE 2 -from clk -to clkx2 set_multicycle_path -end -setup -from [get_clocks {clk}] -to [get_clocks {clkx2}] 2 set_multicycle_path -end -hold -from [get_clocks {clk}] -to [get_clocks {clkx2}] 1 从上面的例子可以看出,SDC 比 QSF 简洁了些,在 Multicycle 的约束上也清晰明确了些。 图一、查看 Multicycle 约束为 0 的 Hold Time 时序余量计算 图二、查看 Multicycle 约束为 1 的 Hold Time 时序余量计算 图三、查看 Multicycle 约束为 2 的 Hold Time 时序余量计算 AN 481: Applying Multicycle Exceptions in the TimeQuest Timing Analyzer 九 看懂时序波形图 时序分析和时序约束在很多朋友看来是 FPGA 设计中的―高级‖技术,是可以―明天再学‖的功课。想一想,我 们设计的每一个正确运行的数字电路在每一个 ps 内都正在我们有意或者无意设定的时序约束范围内运行 着——时序分析这门所谓―高级‖的技术,体现的正是数字电路运行的基本原理。我们今天放弃学习的科目, 正是我们最需要学习的―基本‖技术。 我学习时序分析和约束只是刚刚入门。从我学习时序分析的经历看来,学习使用时序分析工具并不难,有 文档可以参考,有例子可以实践,EDA 工具本来就是方便设计者使用的,好学好用是理所应当的;理解时 序分析的概念和原理确实有一定难度,强记几个公式不难,依样画葫芦把数值代入公式得到与时序分析结 果相符的数值也是小学水平,可是在实践中,却总是难以理清这些数值之间的关系,―打哪儿指哪儿‖容易, ―指哪儿打哪儿‖太难。知其然而不知其所以然,这是我最初面对那些时序分析计算结果时的感受。带着这 样的感受,我一直徘徊在时序分析技术的门外。 直到最近一段时间以来,才逐渐摆脱了这种不踏实、不自信的感受。这是得益于反复观察和分析 TimeQuest 中的 Waveform 视图。从这一自学过程中, 总结出学习时序分析原理的一个关键点:在脑海中建立时序分 析公式与实际电路物理属性之间的映射关系。建立了这种映射关系,才能理解时序分析公式的意义和来历, 才能做到知其所以然,才能做到定性和定量地分析电路的时序性能。 时序波形图是建立这一映射关系的好帮手。波形图对于理解电路运行时序的重要性,恐怕所有做过仿真的 朋友都深有体会。为什么波形图如此重要,因为硬件电路是并行运行的。即使一个最简单的同步电路中也 会有两个以上的信号在同时变化和相互作用。人脑并不擅长处理并行过程,这需要太多的内存来记忆中间 变量,需要太多的循环来更新这些变量。人的注意力很难保持太长时间,稍不留神,头脑中的并行仿真过 程就失败了。这也是为什么我们需要仿真工具的原因,保留我们的精力去做更重要和更具创意的事,让电 脑代替人脑做我们不擅长的工作。 在网上常见的讲解时序分析概念的文章中, 最常见到的是电路的时序路径图,即一条时序路径是由哪些基 本传播路径组成的。这样的时序路径图只能定性地示意时序分析公式的原理,难以定量地辅助设计者完成 时序分析公式的计算。在这样的学习过程中,我的思维直接从电路图跳跃到了公式,缺少了一个中间环节 ——波形图。这是造成我知其然不知其所以然的原因。我上面分析了波形图对于定量理解电路行为的重要 性,那么为什么这些文章中不包含一幅波形图呢?原因很简单,不容易画。正如电路仿真需要 EDA 一样, 把一幅波形图画得清晰准确也需要电脑的辅助。 TimeQuest 中自动生成的时序波形图很好地解决了―缺少波形图‖这一自学时序分析原理过程中的问题。在 TimeQuest 中,时序波形图与时序分析公式是一一对应的,看着波形图去逐项理解时序分析公式中的各个 元素是再容易不过了。 在下面这幅时序波形图中,我们可以看到 10 个波形,相应地表示了 10 组电路物理属性之间的关系。对于 缺少训练的头脑(我的头脑就是其中之一)来说,包含这么多信息的波形是很难在思维中模拟出来的。这 些波形准确地表示了实际电路的物理特性,至于是否能够清晰地反映电路的时序关系,还需要读者逐君自 己花些力气。 人脑不擅长模拟复杂的并行时序关系,这是事实。不过话又说回来,上面这幅波形图也没有太复杂到哪里 去。看懂它不是难事,只要加以练习,掌握它甚至在设计和分析电路的思维活动中灵活使用它也不会太难。 我们这些逻辑设计工程师已经花费了很多时间在―基本功‖的学习和熟练上,在这门既―基本‖又―高级‖的功夫 上也不应该太惜力啊!

Top_arrow
回到顶部
EEWORLD下载中心所有资源均来自网友分享,如有侵权,请发送举报邮件到客服邮箱bbs_service@eeworld.com.cn 或通过站内短信息或QQ:273568022联系管理员 高进,我们会尽快处理。