I***a
发帖数: 704 | 1 Quartus II的Timing Analyzer给了这样的结果:
worse-case tsu: 7.152ns
worst-case tco: 14.204 ns
worst-case th: -1.128ns
Clock Setup: 287.89MHz(period = 3.357 ns)
请问最大可用的时钟频率是多少？Thanks. |
r*********i
发帖数: 67 | 2 光考虑tsu的话，如果你想保持至少1ns的th, f = 1/(7.152+1)nS.
考虑tco的话，f 最高 1/14.204nS
你期望达到的频率是288MHz，那几乎5倍高了。你要努力优化你的设计了。 |
I***a
发帖数: 704 | 3 1.不考虑tco,
最大频率 = 1/(worse-case tsu - worst-case th)?
2.tco 为什么会这么大
我的所有输出pin都是直接register输出.
tco = register本身的tco + longest clock delay of clock tree.
register本身的tco 应该很小
我用的register才320位，clock tree delay 会有14.204 ns的延时？
clock delay指的是clock tree的latency吧
3. quartus 哪里可以显示fmax?
4. 很明显这个design我没有办法提高时钟频率了，因为critical path的delay是3.357 ns，
但是时钟分配网络的延时是14.204 ns, 我要优化设计，就必须减少使用的register, 这个无法实现。
谢谢 |
a*****u
发帖数: 157 | 4 Fmax在综合报告里面直接就有啊。要看详细的时序分析，用report timing。
你对时序分析的理解有点问题。clock tree delay是不会contribute to critical
path的。原因很简单，你的data launch和data latch的clock都有经历clock tree
delay，所以影响critical path上的timing的只有clock tree的skew。jitter是时钟源
的问题，跟clock tree莫有虾米关系，不过SDC里面都是当成uncertainty的。 |
I***a
发帖数: 704 | 5 worse-case tsu: 7.152ns
worst-case tco: 14.204 ns
worst-case th: -1.128ns
Clock Setup: 287.89MHz(period = 3.357 ns)
根据这几个条件，你认为的Fmax 是多少？
你说的综合报告里的Fmax就是上面的287.89MHz，
”你的data launch和data latch的clock都有经历clock tree
你没有考虑输入pin和clock之间的时序关系(tsu, th), 输出pin和clock之间的时序关系(tco)，你只考虑了内部的时序关系。
如果你用clock period = 3.357 ns, 输入pin的数据在下降沿变化，tsu = 7.152 ns的话， 输入pin的数据还没等被latch, 就变了。tsu = 14.204 ns的话, 一个上升沿过后, 14.204 ns后才在输出pin得到对应的数据 |
I***a
发帖数: 704 | 6 这个是详细的tco时序报告: PIN_C20的cell delay和interconnect delay 怎么分别是2
.103 ns 和8.358 ns ？为什么这么大？thanks.
Info: tco from clock "CLK" to destination pin "S[23]" through register "S[23
]~reg0" is 14.204 ns
Info: + Longest clock path from clock "CLK" to source register is 3.644
ns
Info: 1: + IC(0.000 ns) + CELL(0.904 ns) = 0.904 ns; Loc. = PIN_Y37;
Fanout = 1; CLK Node = 'CLK'
Info: 2: + IC(0.360 ns) + CELL(0.000 ns) = 1.264 ns; Loc. = CLKCTRL_
G3; Fanout = 104; COMB Node = 'CLK~clkctrl'
Info: 3: + IC(1.731 ns) + CELL(0.649 ns) = 3.644 ns; Loc. = LCFF_X65
_Y3_N13; Fanout = 1; REG Node = 'S[23]~reg0'
Info: Total cell delay = 1.553 ns ( 42.62 % )
Info: Total interconnect delay = 2.091 ns ( 57.38 % )
Info: + Micro clock to output delay of source is 0.099 ns
Info: + Longest register to pin delay is 10.461 ns
Info: 1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. = LCFF_X65
_Y3_N13; Fanout = 1; REG Node = 'S[23]~reg0'
Info: 2: + IC(8.358 ns) + CELL(2.103 ns) = 10.461 ns; Loc. = PIN_C20
; Fanout = 0; PIN Node = 'S[23]'
Info: Total cell delay = 2.103 ns ( 20.10 % )
Info: Total interconnect delay = 8.358 ns ( 79.90 % )
Info: tsu for register "PED:pe0|Cr[1]" (data pin = "X[0]", clock pin = "CLK"
) is 7.152 ns |
r*********i
发帖数: 67 | 7 Your timing is bad. I suspect you are contraining too much or too little.
How did you specify your constraints? Do you have a .sdc file or you set the
constraints through Quartus GUI?
You need to constrain every signal. Otherwise, the tool will do whatever it
wants to do. You need to properly constrain signals which are really
critical. For signals where timing doesn't matter, just specify a very loose
constraint.
There is a chapter on timing analysis in Quartus manual, or some app notes
on timing. You may want to spend a day or two to go through it first. It
helped me to understand timing a lot when I started to design FPGAs. |
I***a
发帖数: 704 | 8 我对这个问题的理解是：
1。我没有对输入pin的tsu和输出pin的tco加任何约束, 导致Quartus II在自动
floorplan和pin assignment的时候把design里的输出register和分配的输出pin之间隔
得很远, 所以有了8.358ns的interconnect delay, 再加上3.644
ns的 clock tree delay 和2.103 ns 的输出pad的delay, 总计 14.204 ns
的超大tco.
2. 对设计内部而言, 最大时钟频率是287.89MHz(period = 3.357 ns),
假设输入pin是在下降沿变化，输出pin是在下一个上升沿读取,
tsu必须小于3.357 ns/2, tco必须小于3.357 ns |
a*****u
发帖数: 157 | 9 I thought you just want to evaluate your logic design, so i didn't consider
the input delay. if you consider this, you will need to set the input delay
of pins in your sdc.
in this case, i don't think you can evaluate the Fmax without the knowladge
of the timing of input signals. and you will also need to consider your
board level design. |
r*********i
发帖数: 67 | 10 1. you are sort of right. However, 14.204 = 3.644 + 0.099 + 10.461.
Image that there is some logic first, then a register(FlipFlop), then the
output pad. 3.644 is the delay of the logic in front. Then the delay in the
FF (from d to q you know) is 0.099. Then 10.461 is the time from the
register output to the output pad. All other numbers are just the breakdown
of the three numbers. 3.644 is not the clock tree delay. All these are
relative to the clock at the input. You should not worry about clock tree
delay here, I think.
What is the clock frequency you specified as a constraint? If you didn't
even specify that, 287.89MHz probably was assigned by the tool.
Near the end of the timing report, you should see a number which tells you
what's the maximum frequency the design can reach with your current
constraints.
If all the constraints are satisfied, this frequency is usually higher than
your specified clock frequency. If they are not all satisfied, this
frequency is usually lower than your specified clock frequency.
2. At which edge does your output change?
【在 I***a 的大作中提到】
: 我对这个问题的理解是：
: 1。我没有对输入pin的tsu和输出pin的tco加任何约束, 导致Quartus II在自动
: floorplan和pin assignment的时候把design里的输出register和分配的输出pin之间隔
: 得很远, 所以有了8.358ns的interconnect delay, 再加上3.644
: ns的 clock tree delay 和2.103 ns 的输出pad的delay, 总计 14.204 ns
: 的超大tco.
: 2. 对设计内部而言, 最大时钟频率是287.89MHz(period = 3.357 ns),
: 假设输入pin是在下降沿变化，输出pin是在下一个上升沿读取,
: tsu必须小于3.357 ns/2, tco必须小于3.357 ns
|
I***a
发帖数: 704 | 11 1. 3.644 ns is the clock tree delay
" Info: + Longest clock path from clock "CLK" to source register is 3.644
ns "
http://www.altera.ru/Disks/Altera%20Documentation%20Library/literature/an/an123.pdf
page 3:
tCO = Clock Delay + Micro tCO + Data Delay
In my case;
Clock Delay = 3.644 ns (can be minimized by setting tCO constraint)
Micro tCO = 0.099 ns (intrinsic, cannot change)
Data Delay = 10.461 ns (can be minimized by setting tCO constraint, in RTL
no logic)
in total, tCO = 14.204 ns
2. rising edge
the
breakdown
【在 r*********i 的大作中提到】
: 1. you are sort of right. However, 14.204 = 3.644 + 0.099 + 10.461.
: Image that there is some logic first, then a register(FlipFlop), then the
: output pad. 3.644 is the delay of the logic in front. Then the delay in the
: FF (from d to q you know) is 0.099. Then 10.461 is the time from the
: register output to the output pad. All other numbers are just the breakdown
: of the three numbers. 3.644 is not the clock tree delay. All these are
: relative to the clock at the input. You should not worry about clock tree
: delay here, I think.
: What is the clock frequency you specified as a constraint? If you didn't
: even specify that, 287.89MHz probably was assigned by the tool.
|
r*********i
发帖数: 67 | 12 You are right in both 1 and 2. My memory is getting fuzzy. I haven't done
FPGA design for a while.
Seems like this fmax 287 MHz is calculated based on the clock tree delay. If
you really run your design that fast, you have very little room for tsu. So
you didn't specify any constraint?
【在 I***a 的大作中提到】
: 1. 3.644 ns is the clock tree delay
: " Info: + Longest clock path from clock "CLK" to source register is 3.644
: ns "
: http://www.altera.ru/Disks/Altera%20Documentation%20Library/literature/an/an123.pdf
: page 3:
: tCO = Clock Delay + Micro tCO + Data Delay
: In my case;
: Clock Delay = 3.644 ns (can be minimized by setting tCO constraint)
: Micro tCO = 0.099 ns (intrinsic, cannot change)
: Data Delay = 10.461 ns (can be minimized by setting tCO constraint, in RTL
|
I***a
发帖数: 704 | 13 not any constraint.
I just want to do some post-simulation on a RTL design and estimate the fmax.
fmax 287 MHz is calculated based on the critical path and clock tree skew.
If
So
【在 r*********i 的大作中提到】
: You are right in both 1 and 2. My memory is getting fuzzy. I haven't done
: FPGA design for a while.
: Seems like this fmax 287 MHz is calculated based on the clock tree delay. If
: you really run your design that fast, you have very little room for tsu. So
: you didn't specify any constraint?
|
r*********i
发帖数: 67 | 14 Interesting. I have never run a design without constraints. Doesn't look
like the tool is giving you the answer you want though.
fmax.
【在 I***a 的大作中提到】
: not any constraint.
: I just want to do some post-simulation on a RTL design and estimate the fmax.
: fmax 287 MHz is calculated based on the critical path and clock tree skew.
:
: If
: So
|
