Altera FPGA时序分析详述：TimeQuest入门与实践指南

需积分: 9 159 浏览量更新于2024-07-21 收藏 3.8MB PDF 举报

Altera FPGA 时间quest分析是针对Altera公司FPGA（Field-Programmable Gate Array）设计者的重要工具，它在FPGA开发过程中扮演了关键角色，用于确保设计的时序性能满足系统需求。时间quest，即TimeQuest，是一个功能强大的工具，用于进行高级综合后的时间和面积分析，包括延迟、功耗和时钟树分析等。文档详细介绍了TimeQuest用户指南的第1.1版，发布日期为2010年12月9日，作者Ryan Scoville是一位经验丰富的设计者，他在帮助他人解决时间quest相关问题的过程中，意识到需要一个集中整理的资源来分享他的学习心得。这份文档旨在成为一个一站式学习资料，尽管目前仍有一些部分缺失，但核心内容已经相当全面，足以满足大部分用户的日常使用需求。文档建议读者： 1. 使用书签功能：为了更有效地导航，用户应利用文档中的书签标记重要的知识点，因为许多示例可能需要前后关联的内容。虽然文档中已经添加了超链接，但书签可以帮助用户快速定位到相关章节。 2. 开始阅读“入门”部分：这个部分包含了时间quest的基本概念和设置步骤，以及如何开始一个项目分析。对于初次接触TimeQuest的用户来说，这是了解工具的基础。文档深入探讨了以下关键知识点： - **时序分析原理**：如何通过TimeQuest分析设计中的路径延迟，确保信号在预定时间内正确传输，避免潜在的设计错误。 - **逻辑优化**：通过分析报告理解设计中的瓶颈，进行逻辑优化，如布线优化、级联或阵列化等。 - **时钟树分析**：检查时钟网络的延迟和扇出，确保时钟同步和稳定性。 - **功耗管理**：识别功率消耗高的区域，有助于实现低功耗设计。 - **仿真与实际硬件行为比较**：使用TimeQuest与门级仿真工具进行对比，验证设计的预期行为。 - **性能指标**：学习如何解读和优化关键性能指标，如最大频率、最小时钟周期等。随着时间的推移，作者计划持续更新文档，填补遗漏的部分，使其成为FPGA设计者进行时序分析的权威参考。掌握TimeQuest分析对于任何进行Altera FPGA设计的人来说，都是提升设计质量和效率不可或缺的技能。

As can be seen, we just described a circuit outside the FPGA. We also now have a

FPGA.

Step 3) Determine the default setup and hold relationship between the

FPGA clock and virtual clock

This step requires the user to determine the setup and hold relationship between the clock

inside the FPGA and the virtual external clock. This is usually very straightforward, as in most

cases the launch clock and latch clock have the same period and are edge aligned, and hence

have a setup relationship equal to the clock period, and a hold relationship of 0ns, as shown in

the top-left example:

For I/O, the virtual clock will be the launch clock for input constraints, and the latch

clock for output constraints. I've shown a few more cases, but won't delve into too much detail

on how to determine the setup and hold relationship, which is covered in-depth in Timing

Analysis Basics.

Rather than delve into calculating the relationship, I'll show how TimeQuest will show

the relationship it is using, and hence the user doesn't have to figure it out beforehand. For

example, a user might have a 100MHz clock coming into the FPGA, which goes through a PLL

and drives data out at 100Mbps. After following the previous steps, the user creates a 10ns

external clock and applies it to the output ports like so:

create_clock -period 10.0 -name tx_clk_ext

set_output_delay -clock tx_clk_ext -max 0.0 [get_ports {TX_DATA[*] TX_PAR}]

set_output_delay -clock tx_clk_ext -min 0.0 [get_ports TX_DATA[*] TX_PAR}]

In this example, they've created a virtual clock called tx_clk_ext. They also said the ports

TX_DATA[*] and TX_PAR drive external registers clocked by tx_clk_ext, and the max and min

delay to those registers is 0.0ns. Since the internal clock also has a period of 10.0ns, and neither

is phase-shifted, then the default setup relationship is 10.0ns and the default hold relationship is

0.0ns. If the user is unsure of this, they can read in the .sdc file using the iterative method and

run report_timing to those ports. In TimeQuest's pull-down menu: Reports -> Custom Reports -

> Report Timing. Simply put the virtual clock name, tx_clk_ext, in the To Clock section, and run

report_timing twice, once for setup and once for hold. In this example, I got the following two

reports:

The left panel is the setup analysis, and the Relationship column, shown in red, is 10ns.

This is expected, as we have a 10ns clock feeding another 10ns clock. Below the Summary of

Paths is the detail for the first path. The 10ns is used such that the launch edge time is 0ns and

the latch edge time is 10ns. Likewise for hold analysis, the relationship is 0ns. The launch edge

time is 0ns and the latch edge time is 0ns.

So what is this really saying? When the launch clock comes into the FPGA, travels to the

source register, which is the output register in this case, then through the output port to the

external register, it must get there in greater than 0ns(the hold relationship) and less than

10ns(the setup relationship). Since our external -max and -min delays are 0ns, i.e. there is no

external delay, than the delay within the FPGA must be greater than 0ns and less than 10ns. At

this point, we have a full constraint that TimeQuest can analyze, but it is probably not the

analysis we want.

Step 4) Add multicycles

This step is usually unnecessary. But if step 3) resulted in a default analysis that is

incorrect, the user may want to modify the setup and hold relationships with multicycles. The

most common cases for this are when the user wants to open the window or shift the window.

Note that we are not accounting for external delays like the Tsu or Tco of an external device or

board delays, as that will be done in step 5. This step is just to make sure the clock relationships

are correct.

An example would be interfacing to a flash device that takes multiple clock cycles to

perform each operation, than the user may want to open the window. An example may look like

so:

set_multicycle_path -setup -to [get_ports {FLASH_DATA[*]}] 4

set_multicycle_path -hold -to [get_ports {FLASH_DATA[*]}] 3

These two assignments tell TimeQuest that there are 4 clock cycles for the

FLASH_DATA to get out of the FPGA. So if the original setup and hold relationships were

10ns and 0ns, they would now be 40ns and 0ns(assuming the clock period is 10ns).

If the clock inside the FPGA has a phase-shift, generally through a PLL, and the external

clock does not, then the user may want to shift the window. For example, if the FPGA clock

feeding an output register were phase-shifted -500ps in order to help meet output timing, the

default setup relationship would be 500ps. To shift the window, the user would add:

set_multicycle_path -setup -to [get_ports {FLASH_DATA[*]}] 2

or:

set_multicycle_path -setup -from [get_clocks {pll|clk[0]} -to [get_clocks clk_ext] 2

The first one modifies the clock relationship on the output path, while the second one

modifies all relationships between these clocks. Either one of these will work as long as they

cover what the user wants covered. If the clocks have a 10ns period, the multicycle will modify

the setup relationship from 0.5ns to 9.5ns, and the hold relationship from -9.5ns to 0.5ns.

Note that if the FPGA clock were phase-shifted forward a little, then a multicycle would

most likely not be necessary. If the default setup relationship were 10ns, and the source clock

inside the FPGA were phase-shifted 500ps forward, then the default relationship would become

9.5ns, which is probably what the user wants.

Inputs work the opposite, whereby if the user phase-shifts the latching clock inside the

FPGA forward a little, then they probably want a multicycle to shift the window, but if they

phase-shift the clock back, they probably do not. This is easily seen by drawing the launch and

latch clock waveforms, as explained in the section on default setup and hold, specifically the

affect of phase-shifts.

Step 5) Modify the -max and -min delays to account for external delays.

Now that we have the correct setup and hold relationship, it is time to modify the -max

and -min values. They are currently set to 0, which means there is no external delay to the

data window is used by the external device and board delays, only leaving part of the data

window for the FPGA. The -max and -min values account for these external delays. Let's see

how they affect the analysis before determining how they account for external delays.

With both -max and -min at 0, we are stating that there are no external delays, and

basically have no affect on the analysis. As the -max value gets larger, it cuts into our setup

relationship. So if the our default setup relationship were 10ns, and the -max output delay were

4ns, that would mean the FPGA must get it's data out in less than 6ns to meet timing. Note the

setup relationship is still 10ns, but the FPGA's delay plus the external delay must be less than

that. So the larger -max gets, the more quickly the FPGA needs to get its data out and the harder

it is to meet timing. As the -max value gets larger, the FPGA needs a faster Tco.

The -min value is often more confusing because it works in the opposite way, whereby

the smaller it gets, the harder it is to meet timing. If the hold relationship is 0ns, and the -min

value was -1ns, then the only way to meet timing would be for the FPGA to get its data out in

more than 1ns. Looking at this through waveforms:

The top waveform shows the default relationships, while the second waveform shows

what happens after accounting for the external delays. Rather than the FPGA needing to get it's

data out between 0ns and 10ns, it must now get out between 1ns and 6ns. Likewise, for internal

paths, if a user entered similar external delays:

剩余132页未读，继续阅读

altera_jack

粉丝: 0
资源: 1

Altera FPGA时序分析详述：TimeQuest入门与实践指南

ALTERA FPGA: 数据需求时间与STA——Setup/Hold解析

FPGA技术探索：瞎搞Time_Quest_第一章解析

Altera Cyclone器件Timequest实例详解（QII53018-11.1.0）

Quest Performance Analysis for Oracle

瞎搞Time_Quest_和无责任的笔记_第一章_fpga_

瞎搞Time_Quest_和无责任的笔记_第一章

quest

Quest

Quest-For-Gab-Time

quest:Quest编程语言

最新资源