이 페이지는 timing에 대한 일련의 페이지 에 속합니다. 이전 페이지에서는 timing constraints에 대한 기본 이론을 살펴보았습니다. 다음 단계는 이 이론이 어떻게 적용되는지 보는 것입니다.
개요
이 페이지에서는 clock의 주파수를 정의하는 가장 중요한 timing constraint를 소개합니다. 그 다음에는 timing report의 path분석에 대한 자세한 예가 나옵니다.
timing report분석의 세부 사항은 고급 주제로 보일 수 있지만 그렇지 않습니다. timing constraints 의 목적은 design에 대한 도구의 timing 분석을 제어하고 충족해야 하는 정확한 요구 사항을 설정하는 것입니다. 그래서 timing constraints를 이해하기 위해서는 timing analysis를 들여다볼 필요가 있다. 그리고 timing analysis는 timing reports에 표시됩니다.
또한 timing constraints를 작성하는 것만으로는 충분하지 않습니다. 이러한 constraints가 design에서 올바르게 작동하는지 확인할 수 있는 것이 중요합니다. 이러한 검증은 timing report에 대한 깊은 이해가 있어야만 가능합니다. 이러한 이해 없이는 목적을 달성하지 못하는 timing constraints 에 실수로 의존하고 logic design이 제대로 작동하지 않는 이유를 궁금해하기 쉽습니다.
모든 FPGA 도구는 timing reports를 텍스트 파일로 생성하며, 여기에 표시된 reports가 바로 그것입니다. 이 도구에는 동일한 정보를 볼 수 있는 그래픽 인터페이스도 있습니다. 이 그래픽 인터페이스는 때로는 도움이 되고 때로는 혼란스러우므로 텍스트 reports 로 작업하는 것이 중요한 첫 번째 단계입니다.
period constraint
가장 유용한 timing constraint는 period constraint입니다. clock signal의 빈도에 대한 도구를 알려줍니다.
예를 들어 logic design이 이 Verilog module로만 구성되어 있다고 가정합니다.
module top(
input clk,
input foo,
output reg bar_reg);
reg foo_reg;
reg bar;
always @(posedge clk)
begin
foo_reg <= foo;
bar <= !foo_reg;
bar_reg <= bar;
end
endmodule
Verilog 에서 @clk이 clock로 사용되고 이 signal이 외부 port (즉, FPGA의 물리적 pin 에 연결됨)라는 것이 분명합니다.
@clk의 주파수가 250 MHz (4 ns)인 경우 다음과 같은 timing constraint가 필요합니다.
create_clock -period 4 -name clk [get_ports clk]
이 command는 다음을 의미합니다. " I/O port 에는 @clk라고 하는 clock이 있습니다. 이 clock의 period는 4 ns입니다. 이 clock을 참조할 다른 timing constraints가 있으면 이를 위해 'clk'라는 이름을 사용할 것입니다."
노트:
- "period" 매개변수의 값은 clock의 clock period 여야 합니다. "추가 안전"(overconstraining)에 대해 더 작은 값을 선택하지 마십시오. 절대 그럴 이유가 없어야 합니다. 이 작업이 도움이 된다면 해결해야 할 다른 문제가 있는 것입니다.
- asynchronous reset을 사용하는 경우 create_clock은 이 reset signal의 timing 요구 사항 위반으로부터 flip-flop을 보호 하지 못할 수 있습니다. 이것은 다른 페이지 에 설명되어 있습니다.
Timing analysis
이제 @foo_reg 에서 시작하여 @bar에서 끝나는 path 의 setup 요구 사항에 대한 Vivado의 timing analysis를 살펴보겠습니다. 즉, 이것은 이 Verilog expression의 결과인 path 입니다.
bar <= !foo_reg;
여기에 표시된 timing analysis는 다음 순서로 timing report 에 나타나는 세 부분으로 구성됩니다.
- path의 timing analysis요약 및 일부 추가 정보가 포함된 header.
- clock edge 에서 안정적인 logic state가 두 번째 flip-flop 의 input (이 예에서는@bar )에 나타날 때까지 걸리는 시간을 계산합니다.
- timing 요구 사항을 충족하기 위해 두 번째 flip-flop 의 input이 안정적이어야 하는 경우를 찾는 계산입니다.
이 세 부분은 아래에 별도로 표시되고 설명되어 있습니다. timing report에서는 이 부분 사이에 눈에 보이는 구분선이 없다는 점에 유의하세요. 특히 timing report 에서는 두 번째 부분이 끝나고 세 번째 부분이 시작되는 곳이 명확하지 않습니다. 이 report 의 독자는 세 번째 부분의 시작을 내용에서 인식해야 합니다.
Vivado의 timing report가 여기에 표시되어 있지만, Quartus 와 다른 여러 FPGA 도구는 동일한 방법론을 채택합니다. 다른 도구의 timing reports 에 쓰여진 정보는 일반적으로 약간 다르게 표시됩니다. 그러나 이러한 reports 의 이론은 동일합니다. 따라서 이 예를 살펴보면 다른 FPGA 도구에도 도움이 됩니다.
timing report의 첫 번째 부분은 건너뛰고, 처음 두 부분을 논의한 후 이 부분으로 돌아오겠습니다. 이 순서대로 report를 설명하는 것이 더 쉽습니다. 하지만 먼저 몇 가지 일반적인 단어를 말씀드리겠습니다.
timing analysis의 전략
이전 페이지 에서 보여드린 단순한 static timing analysis 와 달리 실제 timing analysis는 clock의 불완전성을 고려해야 합니다. 이를 위해 delay 계산은 clock의 원점(예: clock의 물리적 input pin )에서 시작됩니다. 이는 data path의 delay 만 고려하는 단순 data path delay 계산( 이전 페이지 참조 )과 다릅니다.
따라서 이론적 실험은 이제 다음과 같습니다. clock의 원점에서 clock edge 와 함께 스톱워치를 시작합니다. 이 clock edge가 첫 번째 flip-flop 로 이동하여 활성화하는 동안 이 스톱워치가 계속되도록 하십시오. 이 flip-flop이 output을 업데이트할 때 시간을 계속 측정하고 업데이트된 signal을 따라 목적지까지 가십시오. 이 signal이 두 번째 flip-flop에 도달하면 스톱워치를 중지합니다.
다음 단계는 결과가 좋은지 확인하는 것입니다. tsu 요구 사항의 경우 이는 signal이 다음 clock edge에 비해 충분히 빨리 도착했음을 의미합니다.
그러나 이것은 두 번째 flip-flop의 clock edge 입니다. 언제 도착할까요?
이를 확인하기 위해 clock의 원점에서 다음 clock edge 와 함께 스톱워치가 다시 시작됩니다. 이 두 번째 clock edge가 두 번째 flip-flop에 도달하면 스톱워치가 중지됩니다. 따라서 시작점은 같지만 clock edge는 나중에 있고 clock edge 의 목적지는 다릅니다.
이 이론적 실험 후에 clock edge가 두 번째 flip-flop에 도착하는 시기를 알 수 있습니다. tsu 요구 사항을 충족하려면 이 flip-flop의 input이 이 clock edge와 관련하여 충분히 초기에 안정적이어야 합니다.
첫 번째 이론적 실험의 스톱워치는 data가 두 번째 flip-flop에서 안정적인 시기를 보여줍니다. 두 번째 실험의 스톱워치는 clock edge가 동일한 flip-flop에 도착하는 시기를 보여줍니다. 남은 것은 이 두 숫자를 비교하고 차이가 tsu에서 요구하는 것보다 큰지 확인하는 것입니다.
clock 와 관련된 불확실성은 두 이론적 실험에서 최악의 시나리오를 적용할 수 있기 때문에 이 방법을 고려할 수 있습니다. setup time 계산의 경우 모든 delays 의 상한값이 스톱워치를 사용한 첫 번째 실험 계산에 사용됩니다. 결과적으로 계산은 signal이 두 번째 flip-flop의 input 에 도착할 수 있는 가장 늦은 시간을 보여줍니다. 그러나 스톱워치를 사용한 두 번째 실험에서는 모든 delays 의 하한값을 사용했습니다. 결과는 두 번째 clock edge가 두 번째 flip-flop에 도착할 수 있는 가장 빠른 시간입니다.
따라서 signal은 최대한 늦게 도착하고 clock edge는 최대한 빨리 도착하는 시나리오에 대한 계산이 이루어집니다. 이러한 조건에서 setup time 요구 사항이 충족되면 이 요구 사항이 항상 충족된다는 데 의심의 여지가 없습니다.
hold time 계산의 경우 반대입니다. 최소 delays는 첫 번째 실험에 사용하고 최대 delays는 두 번째 실험에 사용합니다.
source path 계산
위에서 언급했듯이 timing report 의 첫 번째 부분은 나중에 표시됩니다. 이제 timing analysis의 두 번째 부분을 살펴보겠습니다. source path 계산. 두 개의 segments로 구성됩니다.
- Source Clock Path는 FPGA의 clock input pin의 rising edge 에서 시작하여 이 rising edge가 @foo_reg의 clock input 에 도달하면 끝납니다.
- Data Path는 @bar의 data input 에서 signal이 새로운 값으로 업데이트될 때까지 여정을 계속합니다. 이 segment는 이전 페이지 에 표시된 간단한 static timing analysis 에 해당합니다.
이 두 segments는 함께 FPGA의 외부 clock pin 에 있는 rising edge 에서 data가 두 번째 flip-flop에 도달할 때까지의 시간을 계산합니다.
이것은 timing report의 관련 부분입니다.
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk rise edge) 0.000 0.000 r
AG12 0.000 0.000 r clk (IN)
net (fo=0) 0.000 0.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 0.738 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.105 0.843 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 0.892 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.839 1.731 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 1.832 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.389 3.221 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF2_SLICEL_C_Q)
0.138 3.359 f foo_reg_reg/Q
net (fo=1, routed) 0.241 3.600 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.244 3.844 r bar__0_i_1/O
net (fo=1, routed) 0.046 3.890 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
이 부분의 각 행은 logic element 또는 wire를 나타냅니다. "Delay type"가 "net"일 때 행은 wire에 해당합니다. 이런 종류의 모든 delays는 routing delays입니다. 즉, signal이 한 logic element 에서 다른 logic element 로 전파되는 데 걸리는 시간입니다.
"Incr" 열은 path 의 각 요소가 기여하는 delay 의 양을 보여줍니다. "Path" 열에는 해당 지점까지의 총 delay이 표시됩니다.
가운데 수평선은 Source Clock Path 의 끝이자 Data Path의 시작을 나타냅니다. 이제 이 두 paths의 delays 에 대해 자세히 살펴보겠습니다.
첫 번째 7개의 delays는 AG12 인 input pin와 관련이 있습니다(이것은 이 pin의 물리적 위치입니다). 이 report에 따르면, 이 pin 와 관련된 input pin 와 logic은 총 1.731 ns의 delay 에 기여합니다.
global clock buffer는 input 에서 output로 또 다른 0.101 ns를 제공합니다. 그 다음에는 global clock의 routing delay이 이어지며 이는 상대적으로 많은 수입니다. 1.389 ns. 이것은 clock signal이 @foo_reg의 clock input에 도달하는 데 걸리는 시간입니다. delay이 이렇게 큰 이유는 global clock buffer 와 clock tree가 이 signal을 배포하는 데 사용되기 때문입니다. 이러한 routing resources는 clock을 FPGA 의 대부분에 동일한 delay을 사용하여 모든 대상에 배포하기 위한 것입니다. 따라서 이 예에서와 같이 clock이 몇 개의 목적지에 도달하는 경우에도 큰 delay이 있습니다( clock 의 fan-out는 3에 불과함).
이 시점에서 clock은 마침내 flip-flop을 포함하는 slice 에 도달했습니다. 이 예에서는 SLICE_X49Y58 입니다. 따라서 Source Clock Path의 끝입니다. report 의 수평선은 Data Path의 시작을 나타냅니다. 이전 페이지 의 예에서, 여기서 간단한 static timing analysis가 시작됩니다.
오른쪽의 Netlist Resources 열에서 수평선 위의 행에 "foo_reg_reg/C"라고 표시되고 이 행 바로 뒤에 "foo_reg_reg/Q"라고 표시됩니다. 따라서 수평선 뒤의 행은 확실히 @foo_reg의 flip-flop ( C 에서 Q로)의 clock to output delay 입니다. 이 delay은 0.138 ns입니다. "FDRE"는 Data, Reset 및 Enable이 있는 Flip-flop을 의미합니다.
그 다음에는 routing delay 에서 LUT (0.241 ns), propagation delay 내부의 LUT (0.244 ns) 및 routing delay 에서 두 번째 flip-flop (0.046 ns)가 이어집니다. 모든 것이 하나의 slice에 들어 있기 때문에 routing delays는 매우 작습니다.
이 부분을 요약하면 clock edge가 외부 pin 에서 첫 번째 flip-flop의 clock input 로 이동하는 데 3.221 ns가 필요했습니다. 그런 다음 업데이트된 signal이 두 번째 flip-flop의 input (3.890 − 3.221 = 0.669 ns)에 도착할 때까지 0.669 ns가 걸렸습니다. 전체적으로 외부 pin 의 clock edge 에서 최종 목적지(두 번째 flip-flop의 data input)에 있는 안정적인 signal 까지의 시간은 3.890 ns 였습니다(기껏해야 이것은 최악의 경우 계산임).
이제 이것이 충분히 빨리 이루어졌는지 물어볼 때입니다. setup time 요구 사항이 충족되었습니까?
Destination Clock Path
이 두 번째 계산의 목적은 clock edge가 외부 pin 에서 두 번째 flip-flop의 clock input로 얼마나 빨리 이동할 수 있는지 알아보는 것입니다.
clock path의 대상은 두 번째 flip-flop입니다. 이것은 대상이 첫 번째 flip-flop인 이전 계산의 clock path와 혼동해서는 안 됩니다.
다른 주목할만한 차이점이 있습니다.
- clock path 만 계산됩니다. 즉, 이전 계산과 비교하여 수평선까지 segment 만 고려됩니다.
- 이론적 스톱워치는 0이 아니라 4 ns에서 시작합니다. 이 계산의 목적은 data signal이 setup time 요구 사항을 충족할 만큼 일찍 도착하는지 알아내는 것이기 때문입니다. 따라서 계산은 두 번째 clock edge에서 시작하는데, 이는 clk 에 대한 timing constraint 에 따르면 4 ns 입니다(즉, 위에 표시된 create_clock command ).
- 이 segment 에 있는 각 구성 요소의 delays는 더 작습니다. 두 flip-flops가 동일한 slice에 있기 때문에 clock paths는 두 계산에서 정확히 동일합니다(보통 그렇지 않음). 아래에서 이에 대해 자세히 알아보세요.
- 이 계산의 마지막 세 행(clock pessimism, clock uncertainty 및 Setup_DFF2_SLICEL_C_D)은 logic 구성 요소가 아니라 timing parameters입니다.
timing analysis (Destination Clock Path)의 세 번째 부분은 다음과 같습니다.
(clock clk rise edge) 4.000 4.000 r
AG12 0.000 4.000 r clk (IN)
net (fo=0) 0.000 4.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 4.515 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.066 4.581 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 4.615 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.722 5.337 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 5.428 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.218 6.646 clk_IBUF_BUFG
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism 0.527 7.173
clock uncertainty -0.035 7.138
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 7.205 bar_reg__0
-------------------------------------------------------------------
required time 7.205
arrival time -3.890
-------------------------------------------------------------------
slack 3.315
도구는 @foo_reg 와 @bar를 동일한 slice에 배치하기로 선택했기 때문에 이 특정 사례에서 이 분석의 clock path는 첫 번째 분석과 동일합니다. 따라서 logic elements 의 시퀀스가 수평선까지 이전 분석과 완전히 동일함을 쉽게 알 수 있습니다. 이 순서 후에 계산을 조정하는 두 개의 timing parameters가 있습니다. Clock pessimism 및 clock uncertainty. 이에 대해서는 이 페이지 하단에서 별도로 설명합니다.
이 계산의 마지막 행 하나 전에 두 번째 clock edge가 도착할 수 있는 가장 빠른 시간이 있습니다. 첫 번째 clock edge이후의 7.138 ns . setup time 요구 사항은 data signal이 이 clock edge이전에 안정적이어야 한다는 것입니다. tsu는 얼마를 지정합니다. 따라서 data가 안정되어야 하는 최신 시간을 얻기 위해 clock의 도착 시간에서 tsu를 뺍니다.
위의 예에서 tsu는 음수이고 −0.067 ns와 같습니다. 따라서 최종 결과는 7.138 − (−0.067) = 7.205 ns입니다. 즉, data는 첫 번째 clock edge이후 7.205 ns 이전에 두 번째 flip-flop 에서 안정적이어야 합니다.
이전 계산에서 결과는 최악의 경우 data가 이 clock edge이후 3.890 ns 로 안정적이었습니다. 여백이 있으면 충분합니다. 요구 사항과 보장되는 것의 차이는 7.205 − 3.890 = 3.315 ns입니다. 즉, slack은 3.315 ns입니다.
timing analysis요약
이제 path의 timing report의 첫 부분으로 돌아갈 시간입니다. 이 부분은 위에서 보여드린 계산 전에 나오며 주요 결과를 요약합니다. 또한 이 header는 이 계산에 나타나는 몇 가지 값을 명확히 합니다.
path 의 timing analysis는 다음과 같이 시작됩니다.
Slack (MET) : 3.315ns (required time - arrival time)
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Path Group: clk
Path Type: Setup (Max at Slow Process Corner)
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Logic Levels: 1 (LUT1=1)
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns)
Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
이 부분은 여러 가지 정보로 구성되어 있으므로 하나씩 살펴보겠습니다. 따라서 첫 번째 행부터 시작합니다.
Slack (MET) : 3.315ns (required time - arrival time)
이것은 timing constraint가 달성되었고(met), 남은 시간이 있었다는 것(slack), 3.315 ns를 말합니다.
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
이 행은 어떤 data path가 검사되는지를 나타냅니다. 이것은 이 path ( Source 및 Destination)의 시작 위치와 끝 위치로 정의됩니다. data path는 @foo_reg의 clock input 인 foo_reg_reg/C에서 시작합니다. 이 path는 bar_reg__0/D의 data input 에서 끝납니다.
또 다른 것은 "clk"가 언급되고, 그 waveform이 설명된다는 것입니다. "clk"는 create_clock와 함께 clock 에 주어진 이름을 나타냅니다. 이 예에서 "clk"는 clock signal의 이름이기도 합니다. 하지만 timing constraint의 "-name" parameter 에 다른 이름이 사용되면, 그 이름은 signal의 이름과 상관없이 timing report에 나타납니다. 이것은 이 timing report예에서 "clk"가 언급된 모든 곳에 해당합니다.
Path Group: clk
여기서 Path Group은 "clk"로, 이 path를 검토하는 이유가 동명의 timing constraint 임을 나타냅니다.
Path Type: Setup (Max at Slow Process Corner)
Path Type은 Setup입니다. 이는 setup time 요구 사항이 검토되었음을 의미합니다. "Max at Slow Process Corner"는 data path (첫 번째 계산)에 대한 계산에 최대 delays가 사용되었음을 의미합니다. 이 맥락에서 Corner 의 의미는 아래에 설명되어 있습니다.
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
위에서 설명한 두 가지 이론적 실험 각각에 대해 시작되는 가상 스톱워치가 있음을 상기하십시오. "Requirement"는 이 스톱워치가 시작되는 시간 차이입니다. 이 경우 timing constraint에 필요한 clock period는 4 ns입니다.
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Data Path Delay은 첫 번째 계산에서 수평선 이후의 모든 delays 의 합계입니다(즉, data path의 delays ).
이 행에서 delay은 logic 와 route에 대해 별도로 표시되어 있습니다. 이는 logic elements 에 얼마나 많은 시간을 소비하고 이 logic elements사이에서 wires 에 얼마나 많은 시간을 소비하는지 보여줍니다. 일반적인 경험 법칙은 delay 의 대략 60%가 logic에 있고 나머지는 routing에 있어야 한다는 것입니다. 따라서 이 예에서 path는 정상적인 상황을 보여줍니다.
routing의 delay이 훨씬 더 큰 비율을 차지하는 경우 특히 path가 timing constraint를 달성하지 못하는 경우 문제가 있음을 나타낼 수 있습니다. 이에 대한 자세한 내용은 다음 페이지 의 thold분석에 대해 설명하는 섹션에서 설명합니다.
Logic Levels: 1 (LUT1=1)
data path는 단일 LUT로 구성되므로 logic levels 의 수는 1입니다.
Clock Path Skew: -0.048ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.646ns = ( 6.646 - 4.000 )
Source Clock Delay (SCD): 3.221ns
Clock Pessimism Removal (CPR): 0.527ns
Clock Path Skew는 동일한 clock edge가 두 flip-flops에 도착하는 시간의 차이입니다. 이것은 하나의 clock path에서 최대 delays를 사용하고 다른 clock path에서 최소 delays를 사용한다는 사실을 포함하여 계산된 최악의 경우입니다. 이러한 행 뒤에 있는 산술을 설명하는 아래 "Clock pessimism removal" 섹션을 참조하십시오.
Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.000ns
Phase Error (PE): 0.000ns
아래의 "Clock uncertainty" 섹션을 참조하십시오. 이 행은 clock uncertainty가 계산된 방법을 보여줍니다. 이 계산 결과 0.035 ns는 비현실적으로 낙관적입니다. 이것은 timing constraint에 jitter가 지정되지 않았기 때문에 발생했으며, 따라서 도구는 jitter가 0이라고 가정했습니다. 그 외에도 외부 clock이 직접 사용되므로(즉, FPGA내부에 PLL이 없음) jitter가 설명할 소스가 거의 없습니다.
timing constraint에서 외부 clock의 jitter를 지정하지 않는 것은 실수이지만 일반적으로 이렇게 지정됩니다. jitter는 일반적으로 timing 계산에서 고려되는 다른 항목에 비해 작기 때문에 이것은 거의 문제의 원인이 아닙니다.
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
이들은 clock buffer 의 output 에서 flip-flops의 clock inputs각각에 이르기까지 clock signal 자체의 delays 입니다. 이 예에서는 이러한 숫자에서 얻을 수 있는 정보가 많지 않습니다.
Multi-corner timing analysis
모든 logic elements 의 delay은 몇 가지 알려지지 않은 매개변수(예: 온도 및 supply voltage)에 따라 달라집니다. 또한 "process"라는 용어는 FPGA생산 중 부정확성을 나타내는 데 사용됩니다. FPGA가 datasheet을 준수하는지 확인하기 위해 모든 FPGA를 테스트했지만 각 logic element의 동작과 관련하여 여전히 약간의 불확실성이 있습니다.
FPGA 도구는 "corners"라고 하는 몇 가지 극단적인 시나리오에서 각 path 에 대해 timing analysis를 수행합니다. 예를 들어, 하나의 시나리오는 가장 빠른 process 와 결합된 허용되는 최저 온도일 수 있습니다(즉, FPGA가 낮은 delays로 제조된 경우). 두 번째 시나리오는 가장 빠른 process와 결합된 최고 온도일 수 있습니다. 세 번째와 네 번째 시나리오는 가장 느린 process로 이를 반복합니다.
따라서 이 예에서 timing analysis는 두 매개변수의 극한 조건에 대해 수행됩니다. 온도 및 process. 이것은 four-corner timing analysis라고합니다. 그러나 이것은 multi-corner timing analysis를 수행할 수 있는 많은 가능성 중 하나일 뿐입니다. 각 FPGA 도구는 timing analysis를 다른 방식으로 수행합니다.
그러나 도구가 검사하기 위해 선택한 corners 에 관계없이 최악의 경우는 항상 timing analysis의 결과로 간주됩니다. 즉, 도구는 각 corner에 대해 slack을 계산하며 가장 낮은 slack이 중요합니다.
도구는 각 FPGA에 대해 적절한 multi-corner timing analysis를 수행하도록 프로그래밍되어 있으므로 이 주제를 깊이 이해할 필요가 없습니다. 그러나 timing report를 읽을 때 단일 corner와 관련이 있는지 또는 모든 corners 의 요약인지(즉, 최악의 경우) 확인하는 것이 중요합니다. 특히 Quartus와 혼동할 가능성이 있습니다.
다음은Clock pessimism removal 및 Clock uncertainty 에 대해 설명합니다. 이들은 비교적 고급 주제입니다. timing 계산의 더 자세한 세부 사항에 관심이 없다면 이 시리즈의 다음 페이지 로 건너뛰어도 됩니다.
Clock pessimism removal
두 flip-flops가 동일한 slice에 있는 우연의 일치로 인해 clock path delays 의 계산을 비교할 수 있습니다(즉, clock edge가 slice에 도달할 때까지의 시간). 두 번째 계산에서는 계산이 4 ns 에서 시작하여 6.646 ns에서 끝나므로 6.646 − 4 = 2.646 ns가 므로 이 시간은 2.646 ns입니다. 이전 계산에서 결과는 3.221 ns였습니다. 0.575 ns의 이 차이.
이러한 차이가 나는 이유는 첫 번째 계산에서 최대 delays를 사용하고 두 번째 계산에서 최소 delays를 사용했기 때문입니다. 최소 delays 와 최대 delays 의 차이는 delays가 제조 공정의 자연스러운 부정확성으로 인해 정확하게 알려지지 않았다는 사실을 나타냅니다. 따라서 clock path 에서 첫 번째 flip-flop 까지가 clock path 에서 두 번째 flip-flop까지 완전히 다른 경우 최악의 경우를 고려해야 합니다. 이 최악의 경우는 첫 번째 path 의 모든 delays가 허용되는 최대값이고 두 번째 path 의 모든 delays가 허용되는 최소값인 경우입니다. clock pessimism라고 합니다.
이는 하나의 물리적 FPGA 와 다른 물리적 FPGA 사이의 온도 또는 차이와 관련이 없습니다. 두 계산 모두 동일한 온도 및 제조 공정에 대해 이루어집니다. 이러한 차이는 segment 의 각 delay 에는 FPGA의 사양 내에 있는 tolerance가 있기 때문입니다.
그러나 clock path가 두 paths에서 동일할 때 clock pessimism이 계산의 일부인 이유는 무엇입니까? 대답은 이렇게 하는 것이 실수라는 것입니다. 이것이 Destination Clock Path에 "clock pessimism"라는 제목의 행이 있는 이유입니다. 이 행은 이 실수를 보완하기 위해 delay 에 0.527 ns를 추가합니다. 제목은 실제로 "clock pessimism removal"(CPR)여야 합니다.
따라서 clock pessimism removal 의 기본 아이디어는 두 계산에서 동일한 clock path 부분에서 최소 delay 와 최대 delay 사이의 불필요한 차이를 제거하는 것입니다. 도구는 두 계산의 clock paths를 비교하고 두 paths에 공통인 segment를 찾습니다. delays (공유 segment)의 모든 차이점의 합은 제거해야 하는 clock pessimism 입니다.
위에서 언급했듯이 clock paths 의 차이점은 0.575 ns였습니다. 그런데 적용된 clock pessimism은 바로 0.527 ns였습니다. 따라서 감소는 0.048 ns에 의해 더 작았습니다. 그 이유는 slice 내부에 두 계산에 공통적이지 않은 clock path 의 작은 segment가 있기 때문입니다. slice 내부의 한 wire는 첫 번째 flip-flop 로 가고 두 번째 wire는 두 번째 flip-flop로 간다. 이 두 wires 의 delays는 다를 수 있다.
Clock uncertainty
timing 계산에서 0.035 ns는 clock path계산에서 줄었습니다. 이것은 timing 계산을 더 엄격하게 만듭니다.
Clock uncertainty는 각 두 clock edges사이의 시간에 대해 임의적인 모든 것을 설명합니다. 이 임의성을 clock jitter라고 하며 다양한 노이즈 소스와 전자 장치의 임의 동작의 결과입니다.
계산에서 0.035 ns 의 감소는 timing constraint (create_clock)에서 clock period가 4 ns 로 정의되지만 실제로는 이 clock period가 임의적이라는 사실을 나타냅니다. 결과적으로 두 clock edges 사이의 시간이 더 짧아질 수 있습니다. 얼마나 더 짧습니까? 이 계산에서는 두 clock edges 사이의 시간이 3.965 ns (4−0.035 = 3.965 ns)보다 작지 않을 것이라고 가정했습니다.
이 가정이 입증되었습니까? clock jitter 에 대한 추정은 timing constraints에 대한 이 논의의 범위를 훨씬 넘어서는 복잡한 주제이기 때문에 어려운 질문입니다. 그럼에도 불구하고 timing constraints와 관계없이 clock jitter가 logic design에서 다양한 문제의 원인이 될 수 있으므로 이 주제를 더 연구하는 것이 좋습니다.
이것으로 clock period constraint에 대한 두 페이지 중 첫 번째 페이지를 마칩니다. 다음 페이지 에서 배울 내용이 더 있습니다...