이 페이지는 timing에 대한 일련의 페이지 에 속합니다. timing constraints 에 대한 이론과 clock period constraint에 대한 첫 페이지에 대한 간략한 소개가 끝나면 이제 이 constraint에 대한 몇 가지 현실적인 시나리오를 살펴볼 차례입니다.
다음 단계: PLL사용
이전 페이지 에 표시된 예에서 외부 clock pin은 logic에 직접 연결되었습니다. 대부분의 실제 designs에서는 logic에서 사용되는 clock을 만드는 데 일종의 PLL이 사용됩니다. 이렇게 하는 가장 확실한 이유는 logic이 외부 clock의 주파수와 다른 주파수를 필요로 하기 때문입니다. 그러나 PLL을 사용하면 외부 clock , 특히 jitter의 결함을 제거하여 도움이 될 수도 있습니다.
다음과 같이 Verilog 코드를 사용하여 PLL을 design 에 추가할 수 있습니다.
module top(
input clk,
input foo,
output reg bar_reg
);
reg foo_reg;
reg bar;
wire pll_clk;
clk_wiz_0 pll_i
(.clk_in1(clk),
.clk_out1(pll_clk));
always @(posedge pll_clk)
begin
foo_reg <= foo;
bar <= !foo_reg;
bar_reg <= bar;
end
endmodule
앞의 예와 같지만 이번에는 flip-flops의 clock이 @clk이 아닌 @pll_clk 입니다. PLL은 Verilog 코드에서 clk_wiz_0라는 이름의 module 로 사용되는 Vivado의 Clocking Wizard IP에 의해 생성됩니다.
이 예에서 Clocking Wizard는 250 MHz reference clock을 수용하고 output port (예: @clk_out1)에서 125 MHz clock을 생성하도록 구성되었습니다. 예제를 간단하게 유지하기 위해 clk_wiz_0 에는 reset input 또는 "locked" output이 없습니다. 대부분의 실제 designs 에서는 이러한 ports를 활성화하고 사용하는 것이 좋습니다.
clk_wiz_0 의 또 다른 특징은 phase alignment 옵션이 활성화되어 있어 @pll_clk의 clock edges를 @clk의 clock edges 와 정렬한다는 것입니다. 이 옵션은 design 에 외부 clock와 동기식인 I/O ports가 있을 때 유용합니다. 활성화된 phase alignment덕분에 외부 clock 와 내부 clock 간의 timing 관계를 예측할 수 있습니다. 이는 외부 clock와 관련된 timing 요구 사항을 충족해야 하는 I/O ports 에 유용합니다.
Xilinx의 용어를 정확히 말하자면 Xilinx의 FPGAs 에는 두 가지 유형의 PLLs가 있습니다. 한 유형은 PLL 라고 하고 두 번째 유형은 MMCM라고 합니다. 차이점은 이 예제와 관련이 없습니다. clk_wiz_0은 MMCM이 지만 명확성을 위해 PLL라는 용어로 언급하겠습니다.
여기서 PLL 에 대해 언급된 모든 내용은 시장의 모든 FPGAs 에 적용된다는 점을 다시 한 번 언급할 가치가 있습니다. 이 예는 Vivado로 표시되지만 clk_wiz_0 와 정확히 동일한 기능을 수행하는 PLL은 모든 FPGAs에 대해 생성될 수 있습니다.
PLL와 timing constraint
PLL 와 함께 timing constraints 에 대해 알아야 할 가장 중요한 점은 그것에 대해 특별히 할 일이 없다는 것입니다. timing constraint는 외부 pin (이 예에서는@clk )와 관련하여 작성되며 PLL이 다른 주파수로 clock을 생성하는 경우 이를 고려하는 것이 도구의 작업입니다.
다시 말할 가치가 있습니다. PLL을 사용하기 때문에 timing constraint를 추가로 작성할 필요가 절대 없어야 합니다. 그렇게 해야 할 필요성을 느낀다면 design에 문제가 있을 가능성이 높으며 추가 timing constraint 로 문제를 "수정"해도 실제 문제가 해결되지 않습니다.
이전과 마찬가지로 timing constraint는 다음과 같습니다.
create_clock -period 4.000 -name clk [get_ports clk]
Quartus를 사용하는 사용자는 이 페이지에 설명된 함정을 알고 있어야 합니다.
PLL와 timing report
이제 이전 페이지 의 예와 동일한 path 의 timing report를 살펴보겠습니다. 유일한 차이점은 위와 같이 PLL이 추가되었다는 것입니다. 여기서 관련 path 의 분석은 timing report에 나타나는 것과 동일한 순서로 표시됩니다. 먼저 분석을 요약하면 다음과 같습니다.
Slack (MET) : 7.288ns (required time - arrival time) Source: foo_reg_reg/C (rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_0 {rise@0.000ns fall@4.000ns period=8.000ns}) Destination: bar_reg__0/D (rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_0 {rise@0.000ns fall@4.000ns period=8.000ns}) Path Group: clk_out1_clk_wiz_0 Path Type: Setup (Max at Slow Process Corner) Requirement: 8.000ns (clk_out1_clk_wiz_0 rise@8.000ns - clk_out1_clk_wiz_0 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): -0.715ns = ( 7.285 - 8.000 ) Source Clock Delay (SCD): -0.616ns Clock Pessimism Removal (CPR): 0.051ns Clock Uncertainty: 0.062ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.071ns Discrete Jitter (DJ): 0.103ns 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)
몇 가지 주목할만한 차이점이 있습니다. 먼저 Requirement는 이전의 4 ns가 아닌 8 ns입니다. 이것은 PLL의 output이 125 MHz가 기 때문에 예상됩니다. 이 도구는 8 ns와 동일한 clock period를 사용하여 이 output용으로 추가 timing constraint를 자동으로 생성했습니다. clock period가 4 ns 만큼 길어지고 data path가 그대로 유지됨에 따라 slack은 약 4 ns증가했습니다.
자동 timing constraint 의 또 다른 표시는 Path Group이 이 report에서 "clk_out1_clk_wiz_0"라고 말한다는 것입니다. 이전에는 "clk"였습니다. 사실, 이 report 에서는 이전에 "clk"였던 모든 곳에서 "clk_out1_clk_wiz_0"라고 말합니다. timing report 에서 자동 timing constraints 의 표현은 여러 개의 clocks의 맥락에서 아래에서 논의됩니다.
PLL 의 작은 결과는 Clock Uncertainty가 0.062 ns로 올라갔다는 것입니다. 이전 예에서는 0.035 ns 였습니다. 이는 Discrete Jitter가 이제 0이 아닌 0.103 ns가 기 때문입니다.
이제 timing analysis 자체로 넘어가겠습니다. 이번에는 Source Clock Path, Data Path , Destination Clock Path가 함께 표시되며, 실제 report에 나타나는 것과 똑같습니다.
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_0 rise edge)
0.000 0.000 r
AG12 0.000 0.000 r clk (IN)
net (fo=0) 0.000 0.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 0.738 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.105 0.843 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 0.892 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.975 1.867 pll_i/inst/clk_in1_clk_wiz_0
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-4.474 -2.607 r pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.501 -2.106 pll_i/inst/clk_out1_clk_wiz_0
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 -2.005 r pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.389 -0.616 pll_clk
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF2_SLICEL_C_Q)
0.138 -0.478 f foo_reg_reg/Q
net (fo=1, routed) 0.241 -0.237 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.244 0.007 r bar__0_i_1/O
net (fo=1, routed) 0.046 0.053 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_0 rise edge)
8.000 8.000 r
AG12 0.000 8.000 r clk (IN)
net (fo=0) 0.000 8.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 8.515 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.066 8.581 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 8.615 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.873 9.488 pll_i/inst/clk_in1_clk_wiz_0
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-3.934 5.554 r pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.422 5.976 pll_i/inst/clk_out1_clk_wiz_0
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 6.067 r pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=3, routed) 1.218 7.285 pll_clk
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism 0.051 7.336
clock uncertainty -0.062 7.274
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 7.341 bar_reg__0
-------------------------------------------------------------------
required time 7.341
arrival time -0.053
-------------------------------------------------------------------
slack 7.288
이전 예와 비교할 때 paths에는 단 한 가지 차이점이 있습니다. PLL ( report에서는 MMCME3_ADV_X1Y0 로 나타남)는 외부 clock pin 와 global clock buffer사이에 삽입되었습니다.
이 PLL은 극적인 효과가 있습니다. source clock path에서 PLL의 delay은 −4.474 ns가 고 destination clock path 에서는 동일한 delay이 −3.934 ns입니다. 이 네거티브 delay은 PLL이 clock edge를 조정하여 global clock이 input pin에서 clock 보다 약간 빠르다는 사실을 나타냅니다. global clock buffer 의 output 에서 clock의 총 delay은 source clock path에서 −0.616 ns 입니다. 동일한 delay은 destination clock path의 7.285 ns 입니다. 이것은 두 번째 clock edge 보다 빠른 0.715 ns 입니다( 8 ns에서).
즉, 외부 clock pin 와 global clock ( logic로 전달됨)는 두 clock paths에서 거의 동일한 시차를 가집니다. 하나의 clock path는 최대 delays로 계산하고 두 번째 clock path는 최소 delays로 계산했지만 전체 결과는 거의 동일합니다.
이것은 우연이 아닙니다. PLL은 global clock output을 reference로 사용하므로 global clock buffer의 input 의 phase는 clock input pin와의 관계를 보장하도록 조정됩니다. 최소 delays 와 최대 delays 의 차이는 PLL로 보완됩니다. timing 계산은 가장 빠른 경우와 가장 느린 경우의 차이가 0.1 ns에 불과하다는 사실로 이를 반영합니다. PLL (0.575 ns, 이전 페이지 의 "Clock pessimism removal" 참조)가 없었기 때문에 이전 예제에서의 이러한 차이는 훨씬 더 컸습니다.
global clock이 외부 input이전에 0.6 ns 정도로 조정되고 다른 값이 아닌 이유는 다른 이야기입니다. 이렇게 하면 많은 경우에 I/O pins 와 관련된 timing constraints를 쉽게 달성할 수 있으므로 도구가 자동으로 이 선택을 수행합니다. 그럼에도 불구하고 모든 FPGAs 에는 이 delay을 조작할 수 있는 옵션이 있습니다.
related clocks2개
종종 logic design 에는 둘 이상의 clock이 필요합니다. FPGA design 에 여러 개의 clocks가 존재한다는 것은 clock domains소개 에서 논의된 고유한 주제입니다. clock domains 와 timing라는 두 가지 주제는 분리할 수 없으므로 여기에서 계속하기 전에 해당 소개 를(간략하게) 읽는 것이 좋습니다. 이 두 주제 사이의 긴밀한 관계로 인해 해당 소개와 이 일련의 페이지 사이에 약간의 중복이 있습니다.
아래 논의에서 " signal X는 @clk와 동기식입니다"와 같은 표현을 자주 사용합니다. 이것은 X가 "clk"라는 이름을 가진 clock 의 rising edge 에 대한 응답으로만 값을 변경하는 flip-flop 의 output 라는 것을 의미합니다( asynchronous resets는 제외하지만 관련이 없음). 당연히 2개의 signals가 동일한 clock에 응답하는 flip-flops 의 outputs 라면 이 2개의 signals는 "동일한 clock와 동기화"됩니다.
이제 동일한 PLL에서 생성되는 두 개의 clocks를 살펴보겠습니다. 대부분의 경우 이 두 clocks가 related clocks로 간주되기 때문에 이는 흥미롭습니다. 이것이 흥미로운 이유를 이해하기 위해 이러한 clocks중 하나와 동기화된 flip-flop이 하나 있고 다른 flip-flop이 두 번째 clock와 동기화되어 있다고 가정해 보겠습니다. 이 경우 동일한 clock와 동기화된 것처럼 두 flip-flops 사이에 signals를 연결하는 것이 좋습니다. FPGA 도구는 이 경우 timing 요구 사항이 충족되도록 합니다.
여러 clocks로 작업하는 방법에 대한 더 나은 이해를 위해 related clocks 및 unrelated clocks에 대한 별도의 페이지 가 있습니다. 해당 페이지는 clock domain crossing에 대한 소개입니다. 여기서는 related clocks의 timing 측면, 특히 이러한 clocks와 관련된 timing report 에 초점을 맞춥니다.
아래의 timing reports를 제작하기 위해 예제에서는 다른 PLL (즉, Clocking Wizard IP)를 사용했습니다. 이 새로운 PLL 의 이름은 clk_wiz_1입니다. 다음 Verilog 코드가 사용되었습니다.
module top(
input clk,
input foo,
output reg bar_reg
);
reg foo_reg;
reg bar;
wire pll_clk_8, pll_clk_6;
clk_wiz_1 pll_i
(.clk_in1(clk),
.clk_out1(pll_clk_8),
.clk_out2(pll_clk_6));
always @(posedge pll_clk_8)
foo_reg <= foo;
always @(posedge pll_clk_6)
begin
bar <= !foo_reg;
bar_reg <= bar;
end
이전과 마찬가지로 이 PLL (즉, @clk)의 input은 250 MHz가 지만 두 개의 outputs가 있습니다. 하나는 125 MHz 에서 실행되는 @pll_clk_8에 연결됩니다(즉, clock period는 8 ns가 므로 signal의 이름입니다). 이것은 이전 예제의 @pll_clk와 정확히 같습니다. 두 번째 output은 대략 166.67 MHz인 6 ns와 동일한 clock period가 있는 @pll_clk_6에 연결됩니다.
@pll_clk_8 및 @pll_clk_6은 동일한 PLL에서 생성되므로 related clocks입니다.
clk_wiz_1 에는 특히 이전 예와 일관성을 유지하기 위해 phase alignment 옵션도 활성화되어 있습니다. 그리고 그것에 대해 의심이 가는 경우: 여전히 이전과 동일한 timing constraint가 하나만 있습니다.
create_clock -period 4.000 -name clk [get_ports clk]
clock summary이해하기
모든 clocks 에 대한 정보는 timing report의 시작 부분에 요약되어 있습니다. 저는 지금 이 문제를 제기하는데, clock이 두 개 이상일 때 clock summary가 더 흥미롭기 때문입니다. 모든 FPGA 도구는 report에서 이런 종류의 요약을 생성하며, 이 부분을 살펴보는 것이 항상 좋은 생각입니다.
-------------------------------------------------------------------------
| Clock Summary
| -------------
-------------------------------------------------------------------------
Clock Waveform(ns) Period(ns) Frequency(MHz)
----- ------------ ---------- --------------
clk {0.000 2.000} 4.000 250.000
clk_out1_clk_wiz_1 {0.000 4.000} 8.000 125.000
clk_out2_clk_wiz_1 {0.000 3.000} 6.000 166.667
clkfbout_clk_wiz_1 {0.000 2.000} 4.000 250.000
이 부분의 가장 큰 장점은 이해하기 쉽고 timing constraints와 관련하여 가장 일반적인 실수를 확인하기 쉽다는 것입니다. clock 의 주파수가 올바른 경우.
이 clock summary는 timing constraint가 올바르게 해석되었음을 보여줍니다. clk라는 이름으로 정의된 하나의 외부 clock이 있으며 해당 clock period는 4 ns입니다. 또한 세 가지 파생 clocks가 있습니다. clk_out1_clk_wiz_1, clk_out2_clk_wiz_1 및 clkfbout_clk_wiz_1. 이름에서 알 수 있듯이 clk_wiz_1라는 이름의 PLL 때문에 자동으로 생성되었습니다.
처음 두 clocks (clk_out1_clk_wiz_1 및 clk_out2_clk_wiz_1)는 PLL의 두 outputs 입니다. 세 번째 clock (clkfbout_clk_wiz_1)는 PLL 에서 global clocks 의 phase를 외부 clock로 조정하는 데 사용됩니다. clkfbout_clk_wiz_1은 @clk와 동일한 주파수를 가집니다.
phase alignment 옵션이 활성화되면 PLL의 feedback clock (clkfbout_clk_wiz_1)가 global clock buffer에 연결됩니다. PLLs는 항상 input clock 와 feedback clock 간에 동기화되므로(이러한 clocks를 정렬하거나 둘 사이에 고정된 delay을 유지함으로써) clkfbout_clk_wiz_1이 global clock 라는 사실은 또한 input clock 와 다른 output clocks간에 알려진 delay을 보장합니다.
clk_out1_clk_wiz_1, clk_out2_clk_wiz_1 및 clkfbout_clk_wiz_1은 실제로 존재하는 clocks를 정의하지 않는다는 점에 유의해야 합니다. 이들은 timing 계산을 위해 소프트웨어에서 사용하는 clocks 의 기호일 뿐입니다. 이 clocks가 이론적이라는 것을 보여주는 한 가지는 clock summary에 표시된 waveforms입니다. 이러한 waveforms는 각 clocks의 duty cycle을 반영합니다. 그러나 4개의 clocks (clk 및 3개의 이론적 clocks) 모두 정확히 0 ns에서 rising edge를 갖는다는 것은 아무 의미가 없습니다. 특히 이 4개의 clocks가 완벽하게 정렬된다는 의미 는 아닙니다 . 정렬되어 있어도 timing 계산을 통해 볼 수 있으며 실제 정렬은 완벽하지 않습니다.
이러한 이론적인 clocks가 사용되는 방법은 이러한 clocks중 2개를 포함하는 timing 계산과 관련하여 아래에서 설명합니다.
이러한 이론적 clocks 에 대한 또 다른 중요한 점은 생성을 위한 명시적인 timing constraint가 없다는 것입니다. clk_out1_clk_wiz_* 생성은 design의 sources 나 도구로 생성한 파일 어디에도 존재하지 않습니다. 대부분의 경우 clock path 의 delays는 이러한 방식으로 올바르게 설명되지 않기 때문에 이러한 timing constraint를 작성하려고 시도하는 것은 올바르지 않습니다. 이러한 constraints가 작성되면 도구에서 clocks 사이의 상대 timing이 잘못 계산되고 related clock domains 사이의 paths가 올바르게 계산되지 않습니다.
따라서 다시 한 번 말하지만 timing constraint 하나만 자동으로 모든 PLL의 output clocks에 대해 timing constraints를 생성해야 합니다.
두 개의 related clocks가 있는 timing report
위의 Verilog 코드에서 알 수 있듯이 @foo_reg은 @pll_clk_8와 동기화되고 @bar는 @pll_clk_6와 동기화됩니다. 따라서 @bar를 업데이트한다는 설명에는 clock domain crossing이 포함됩니다.
bar <= !foo_reg;
2개의 clocks는 related clocks가 므로 도구는 다음 계산을 통해 @bar의 timing 요구 사항이 충족되도록 합니다( tsu의 경우).
Slack (MET) : 0.475ns (required time - arrival time)
Source: foo_reg_reg/C
(rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_1 {rise@0.000ns fall@4.000ns period=8.000ns})
Destination: bar_reg__0/D
(rising edge-triggered cell FDRE clocked by clk_out2_clk_wiz_1 {rise@0.000ns fall@3.000ns period=6.000ns})
Path Group: clk_out2_clk_wiz_1
Path Type: Setup (Max at Slow Process Corner)
Requirement: 2.000ns (clk_out2_clk_wiz_1 rise@18.000ns - clk_out1_clk_wiz_1 rise@16.000ns)
Data Path Delay: 1.160ns (logic 0.307ns (26.466%) route 0.853ns (73.534%))
Logic Levels: 1 (LUT1=1)
Clock Path Skew: -0.250ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): -0.681ns = ( 17.319 - 18.000 )
Source Clock Delay (SCD): -0.600ns = ( 15.400 - 16.000 )
Clock Pessimism Removal (CPR): -0.169ns
Clock Uncertainty: 0.182ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE
Total System Jitter (TSJ): 0.071ns
Discrete Jitter (DJ): 0.103ns
Phase Error (PE): 0.120ns
Clock Net Delay (Source): 1.369ns (routing 0.002ns, distribution 1.367ns)
Clock Net Delay (Destination): 1.208ns (routing 0.002ns, distribution 1.206ns)
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_out1_clk_wiz_1 rise edge)
16.000 16.000 r
AG12 0.000 16.000 r clk (IN)
net (fo=0) 0.000 16.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.738 16.738 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.105 16.843 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.049 16.892 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.975 17.867 pll_i/inst/clk_in1_clk_wiz_1
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0)
-4.438 13.429 r pll_i/inst/mmcme3_adv_inst/CLKOUT0
net (fo=1, routed) 0.501 13.930 pll_i/inst/clk_out1_clk_wiz_1
BUFGCE_X1Y1 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.101 14.031 r pll_i/inst/clkout1_buf/O
X2Y0 (CLOCK_ROOT) net (fo=1, routed) 1.369 15.400 pll_clk_8
SLICE_X49Y58 FDRE r foo_reg_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y58 FDRE (Prop_EFF_SLICEL_C_Q)
0.139 15.539 f foo_reg_reg/Q
net (fo=1, routed) 0.807 16.346 foo_reg
SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O)
0.168 16.514 r bar__0_i_1/O
net (fo=1, routed) 0.046 16.560 p_0_in
SLICE_X49Y58 FDRE r bar_reg__0/D
------------------------------------------------------------------- -------------------
(clock clk_out2_clk_wiz_1 rise edge)
18.000 18.000 r
AG12 0.000 18.000 r clk (IN)
net (fo=0) 0.000 18.000 pll_i/inst/clkin1_ibuf/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 18.515 r pll_i/inst/clkin1_ibuf/INBUF_INST/O
net (fo=1, routed) 0.066 18.581 pll_i/inst/clkin1_ibuf/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 18.615 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O
net (fo=1, routed) 0.873 19.488 pll_i/inst/clk_in1_clk_wiz_1
MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT1)
-3.890 15.598 r pll_i/inst/mmcme3_adv_inst/CLKOUT1
net (fo=1, routed) 0.422 16.020 pll_i/inst/clk_out2_clk_wiz_1
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 16.111 r pll_i/inst/clkout2_buf/O
X2Y0 (CLOCK_ROOT) net (fo=2, routed) 1.208 17.319 pll_clk_6
SLICE_X49Y58 FDRE r bar_reg__0/C
clock pessimism -0.169 17.150
clock uncertainty -0.182 16.967
SLICE_X49Y58 FDRE (Setup_DFF2_SLICEL_C_D)
0.067 17.034 bar_reg__0
-------------------------------------------------------------------
required time 17.034
arrival time -16.560
-------------------------------------------------------------------
slack 0.475
앞서 언급했듯이 timing 계산은 가상의 스톱워치가 clock edges와 함께 시작되는 가상의 실험입니다. 이전 예에서 이 스톱워치는 0 ns에서 시작되었습니다. 그러나이 계산에서는 16 ns에서 clock edge 로 시작합니다. 두 clocks 의 clock periods가 같지 않기 때문입니다. 계산은 첫 번째 clock 와 두 번째 clock사이의 최악의 조합에서 이루어집니다.
첫 번째 clock의 rising edges는 0 ns, 8 ns, 16 ns, 24 ns 등에 있습니다. 두 번째 clock의 rising edges는 0 ns, 6 ns, 12 ns, 18 ns, 24 ns 등에 있습니다. 따라서 첫 번째 clock 와 두 번째 clock 사이의 가장 작은 시간 간격은 첫 번째 clock의 16 ns 와 두 번째 clock의 18 ns입니다. 이것이 이 timing 계산이 조사하는 상황입니다.
이것은 data path가 500 MHz와 같은 대략적인 2 ns로 제한된다는 것을 의미합니다. 이것은 매우 엄격한 요구 사항이지만 data path에는 LUT가 하나만 있고 두 flip-flops는 동일한 slice에 있기 때문에 이 목표를 쉽게 달성할 수 있었습니다. 그러나 이 예는 related clocks에 대해 함께 잘 작동하는 주파수를 선택하는 것이 중요한 이유를 보여줍니다. 종종 하나의 clock주파수가 다른 clock주파수의 배수로 선택됩니다. 이렇게 하면 이 예제의 2 ns 간격과 같은 시나리오를 피할 수 있습니다.
그런데 함께 잘 작동하는 주파수를 선택하는 것이 불가능하다면 해결책은 clocks를 unrelated clocks로 취급하는 것 입니다.
파생된 clocks
앞서 clk_out1_clk_wiz_1 와 clk_out2_clk_wiz_1이 이론상 clocks라고 언급한 바 있는데, 이 사실이 timing report에 반영된 방식은 다음과 같습니다. 두 paths 모두 외부 pin (AG12)를 시작점으로 계산됩니다. 그게 어떻게 말이 됩니까? 실제로 이 pin 의 signal은 reference clock이 며 이 두 clocks중 어느 것도 아닙니다.
clk_out1_clk_wiz_1을 예로 들어 보겠습니다. 계산 이면의 아이디어는 외부 pin에 125 MHz가 있는 clock이 있는 것처럼 가장하는 것입니다. 실제로 clock 와 125 MHz는 PLL의 output , 즉 MMCME3_ADV_X1Y0의 output 에만 존재합니다. 그러나 timing 계산에서 PLL의 주파수 조작을 포함하는 대신 이론적 clock이 대신 사용됩니다. 이 clock 에는 0 ns에서 시작하는 이상적인 waveform이 있습니다. PLL은 clock의 주파수를 변경하지 않고 delays만 추가하는 것처럼 취급됩니다.
따라서 이론적 clock (예: clk_out1_clk_wiz_1)는 clock (주파수, duty cycle, jitter 등)의 waveform을 정의합니다. 그러나 이 이론적 clock은 FPGA에서 실제 signals 로 존재하는 다른 clocks 와의 timing 관계를 정의하지 않습니다.
그렇다면 @pll_clk_6 와 @pll_clk_8이 실제로 정렬되어 있다는 것을 어떻게 알 수 있습니까? 답은 실제 timing 와 이러한 clocks의 이상적인 timing을 비교하는 데 있습니다. 예를 들어 clk_out1_clk_wiz_1의 이론적 clock edge는 위의 계산에서 16 ns 에 있습니다. 반면 clk_out2_clk_wiz_1의 clock edge는 18 ns에 있고 나중에 2 ns에 의해 결정됩니다. 이제 global clock tree의 outputs 와 clock edges를 비교해 보겠습니다. 첫 번째 clock의 clock edge는 timing report에 따르면 15.400 ns에 도착합니다. 두 번째 clock edge의 경우 report는 17.319 ns라고 합니다. 따라서 계산에 따르면 시간 차이는 2 ns가 아닌 1.919 ns 입니다. 이는 이상적인 차이보다 0.081 ns 작을 뿐입니다. 따라서 clocks는 확실히 정렬됩니다.
clock이 하나만 있었던 이전 예와 비교해 보겠습니다. 두 clock edges 간의 이상적인 시차는 clock period, 즉 8 ns였습니다. 그러나 관련 timing report (위 참조)에 따르면 첫 번째 clock edge는 −0.616 ns에, 두 번째 clock edge는 7.285 ns에 도착했습니다. 이상적인 시차는 8 ns였지만 실제로는 7.901 ns였다. 따라서 두 번째 clock edge는 0.099 ns의 예상보다 빨랐습니다.
따라서 두 개의 related clocks를 사용하는 경우 이상적인 시차에서 벗어나는 전환은 0.081 ns입니다. 단 하나의 clock로 이 전환은 0.099 ns와 거의 동일했습니다. 두 경우 모두 이러한 전환의 이유는 첫 번째 clock edge 에 대한 계산이 최대 delays로 이루어지고 최소 delays가 두 번째 clock edge에 사용되기 때문입니다.
따라서 결론은 @pll_clk_6 와 @pll_clk_8이 마치 하나의 clock인 것처럼 거의 동일한 정밀도로 정렬된다는 것입니다.
이러한 clocks는 PLL의 phase alignment를 활성화하는 옵션 없이도 상호 정렬되었을 것입니다. PLL 의 outputs는 일반적으로 어떻게든 정렬됩니다. 이 정렬은 fanout와 관계없이 delays가 거의 동일한 global clock buffers를 사용하여 보장됩니다. 즉, 이러한 각 clock buffers가 몇 개의 logic elements 에 연결되어 있는지는 중요하지 않으며, PLL의 output 에서 대상까지의 delay은 거의 동일합니다.
related clocks에 대해 배운 것
이 timing report 의 분석은 두 related clock domains 사이의 path가 clock domain내부의 path 와 거의 동일하다는 것을 보여줍니다. 하지만 정확히 똑같지는 않습니다. 특히 Clock Uncertainty는 clock 마다 고유한 jitter가 있고 정렬도 완벽하지 않기 때문에 0.062 ns 에서 0.182 ns로 올라갔습니다.
이 timing report는 또한 두 clocks 의 정렬이 timing 계산에 어떻게 반영되는지 보여주었습니다.
FPGA design에 clock domain crossings가 있는 경우 timing report에서 이러한 clocks 간의 상호 작용을 조사하는 것이 좋습니다. 목적은 도구가 예상대로 clocks를 처리하는지 확인하는 것입니다. 확인해야 할 가장 중요한 두 가지 사항은 다음과 같습니다.
- logic이 두 개의 clocks를 related clocks로 간주하는 경우: 이러한 clocks사이의 모든 paths 에서 timing 계산이 있는지 확인합니다.
- logic이 두 개의 clocks를 unrelated clocks로 간주하는 경우: 이 두 clocks사이의 paths 에서 timing 계산이 이루어지지 않았는지 확인합니다.
Vivado는 design의 clock domain crossings와 각 crossing이 도구에서 처리되는 방식을 그래픽으로 표시하는 Clock Interaction Report를 생성할 수 있습니다. 다른 FPGA 도구에는 유사한 기능이 있습니다(예: Quartus Pro의 CDC Viewer). 가능하면 이 보고서를 만들고 검토하는 것이 좋습니다.
살펴볼 또 다른 사항은 clocks가 정렬되었는지 여부입니다. design이 정렬되지 않은 clock을 실수로 사용하면 timing constraints를 구현하는 데 불필요한 어려움이 발생할 수 있습니다. 예를 들어 @clk 와 @pll_clk_8사이에 path가 있는 경우 도구는 timing constraints를 적용하므로 이 path가 안정적으로 작동하는지 확인합니다. 그러나 @clk은 PLL에 들어가는 reference clock이 고 @pll_clk_8은 이 PLL의 output 입니다. 따라서 이 두 clocks는 정렬되지 않습니다. 결과적으로 이 path용 timing constraints를 달성하기 위해 도구가 불필요하게 열심히 작동할 수 있습니다. 다른 paths는 이러한 불필요한 노력으로 인해 timing constraints를 달성하지 못할 수 있습니다.
그리고 다시 한 번 clock domains 의 주제는 이 페이지 시리즈 에서 다룹니다.
thold 도 중요합니다
지금까지 보여드린 모든 timing 계산은 tsu 요구 사항과 관련이 있습니다. 도구가 timing constraints를 달성하지 못하는 경우 거의 항상 하나 이상의 path가 tsu에 대한 요구 사항을 달성하지 못하기 때문에 이 요구 사항에 초점을 맞추는 것이 당연합니다.
그럼에도 불구하고 thold를 염두에 두는 것이 중요합니다. 이 요구 사항을 충족하기 위해 도구는 때때로 routing delay을 추가하여 인위적으로 data path 의 속도를 늦춥니다. 따라서 thold 요구 사항이 timing constraints를 달성하지 못한 이유로 거의 언급되지 않더라도 이 요구 사항이 실패의 숨겨진 원인이 될 수 있습니다.
실제로, 두 개의 flip-flops사이를 연결하는 wire 의 routing delay 에도 관련된 일이 발생했습니다. clock하나만 포함된 모든 timing reports 에서 이 wire는 동일한 slice (SLICE_X49Y58) 안에 있었습니다. 따라서 이 wire 의 delay은 이 모든 reports에서 0.241 ns 였습니다. 하지만 두 개의 clocks가 path에 포함되었을 때 이 delay은 0.807 ns로 올라갔습니다.
설명은 0.241 ns가 동일한 slice에 배치된 두 개의 flip-flops 사이에서 달성할 수 있는 최소 delay 라는 것입니다. 더 긴 delay (0.807 ns)는 이 wire의 다른 routing 의 결과입니다. 이것은 우연히 일어난 것이 아닙니다. 이 도구는 thold 요구 사항을 충족하기 위해 의도적으로 이 매우 긴 routing을 만들었습니다. 이는 report의 "Data Path Delay" 행에도 반영되어 있습니다. logic 용 delay은 그냥 26.5%가 고 나머지는 routing입니다. 그것만으로도 무슨 일이 일어났다는 신호입니다. 아래에서 이에 대해 자세히 알아보세요.
thold 요구 사항 분석
이 페이지 시리즈의 이론적 페이지 에서 thold는 clock edge이후 에 두 번째 flip-flop 의 data input이 안정적이어야 하는 시간이라는 점을 상기하십시오. thold가 위반되는 상황을 설명하겠습니다. clock edge가 첫 번째 flip-flop에 도착하고 두 번째 flip-flop 도 거의 동시에 clock edge를 수신합니다(이러한 clock edges는 동일한 clock 또는 다른 clocks에서 올 수 있음). clock edge에 대한 응답으로 첫 번째 flip-flop은 delay (clock-to-output)에 이어 output을 업데이트합니다. 그러나 업데이트된 값은 두 번째 flip-flop 에 너무 일찍 도달합니다. 결과적으로 이 flip-flop은 이전 값을 안정적으로 샘플링하지 않습니다. 새로운 가치는 두 번째 flip-flop이 clock edge에 대한 반응을 마치기 전에 도착했습니다. 즉, thold 요구 사항을 위반한 것입니다.
동일한 clock이 두 flip-flops와 함께 사용되는 경우 이는 주로 clock skew로 인해 발생할 수 있습니다. clock edge가 첫 번째 flip-flop보다 일찍 도착하면 첫 번째 flip-flop이 output을 너무 일찍 변경할 가능성이 있습니다. 그러면 업데이트된 signal이 thold 요구 사항을 위반할 만큼 빠르게 두 번째 flip-flop 에 도달할 가능성이 열립니다. flip-flops에 모두 도달하는 것은 동일한 clock edge가 므로 clock의 주파수나 clock jitter의 양 모두에 의미가 없습니다. 다른 delay (즉, clock skew)만이 역할을 합니다.
하지만 아래의 timing analysis 의 경우 두 개의 clocks가 포함된 마지막 예를 따르겠습니다. @pll_clk_8 및 @pll_clk_6. 하나의 clock이 있는 timing analysis는 비슷하지만 그다지 흥미롭지는 않습니다. 하나의 clock로 thold 요구 사항을 충족하기가 너무 쉽기 때문입니다.
그래서 우리가 살펴볼 timing report는 두 개의 related clocks용으로 만들어졌습니다. 이 두 clocks는 주파수가 다르며, 이전과 마찬가지로 첫 번째 clock의 clock edge 와 두 번째 clock의 clock edge시간 사이에는 서로 다른 조합이 있습니다. 그러나 tsu에 대한 계산과 달리 thold 에 대한 최악의 경우는 두 clock edges가 모두 0 ns에 있는 경우입니다. thold 위반은 두 clock edges가 거의 동시일 때 발생하므로 이보다 더 나쁜 조합은 없습니다.
따라서 이러한 통찰력을 바탕으로 timing report를 살펴보겠습니다.
Slack (MET) : 0.093ns (arrival time - required time) Source: foo_reg_reg/C (rising edge-triggered cell FDRE clocked by clk_out1_clk_wiz_1 {rise@0.000ns fall@4.000ns period=8.000ns}) Destination: bar_reg__0/D (rising edge-triggered cell FDRE clocked by clk_out2_clk_wiz_1 {rise@0.000ns fall@3.000ns period=6.000ns}) Path Group: clk_out2_clk_wiz_1 Path Type: Hold (Min at Fast Process Corner) Requirement: 0.000ns (clk_out2_clk_wiz_1 rise@0.000ns - clk_out1_clk_wiz_1 rise@0.000ns) Data Path Delay: 0.458ns (logic 0.104ns (22.707%) route 0.354ns (77.293%)) Logic Levels: 1 (LUT1=1) Clock Path Skew: 0.127ns (DCD - SCD - CPR) Destination Clock Delay (DCD): -0.542ns Source Clock Delay (SCD): -0.248ns Clock Pessimism Removal (CPR): -0.421ns Clock Uncertainty: 0.182ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.071ns Discrete Jitter (DJ): 0.103ns Phase Error (PE): 0.120ns Clock Net Delay (Source): 0.495ns (routing 0.002ns, distribution 0.493ns) Clock Net Delay (Destination): 0.576ns (routing 0.002ns, distribution 0.574ns) Location Delay type Incr(ns) Path(ns) Netlist Resource(s) ------------------------------------------------------------------- ------------------- (clock clk_out1_clk_wiz_1 rise edge) 0.000 0.000 r AG12 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 pll_i/inst/clkin1_ibuf/I AG12 INBUF (Prop_INBUF_HRIO_PAD_O) 0.339 0.339 r pll_i/inst/clkin1_ibuf/INBUF_INST/O net (fo=1, routed) 0.025 0.364 pll_i/inst/clkin1_ibuf/OUT AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.015 0.379 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 0.405 0.784 pll_i/inst/clk_in1_clk_wiz_1 MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT0) -1.721 -0.937 r pll_i/inst/mmcme3_adv_inst/CLKOUT0 net (fo=1, routed) 0.167 -0.770 pll_i/inst/clk_out1_clk_wiz_1 BUFGCE_X1Y1 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.027 -0.743 r pll_i/inst/clkout1_buf/O X2Y0 (CLOCK_ROOT) net (fo=1, routed) 0.495 -0.248 pll_clk_8 SLICE_X49Y58 FDRE r foo_reg_reg/C ------------------------------------------------------------------- ------------------- SLICE_X49Y58 FDRE (Prop_EFF_SLICEL_C_Q) 0.049 -0.199 f foo_reg_reg/Q net (fo=1, routed) 0.343 0.144 foo_reg SLICE_X49Y58 LUT1 (Prop_D5LUT_SLICEL_I0_O) 0.055 0.199 r bar__0_i_1/O net (fo=1, routed) 0.011 0.210 p_0_in SLICE_X49Y58 FDRE r bar_reg__0/D ------------------------------------------------------------------- ------------------- (clock clk_out2_clk_wiz_1 rise edge) 0.000 0.000 r AG12 0.000 0.000 r clk (IN) net (fo=0) 0.000 0.000 pll_i/inst/clkin1_ibuf/I AG12 INBUF (Prop_INBUF_HRIO_PAD_O) 0.595 0.595 r pll_i/inst/clkin1_ibuf/INBUF_INST/O net (fo=1, routed) 0.042 0.637 pll_i/inst/clkin1_ibuf/OUT AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O) 0.022 0.659 r pll_i/inst/clkin1_ibuf/IBUFCTRL_INST/O net (fo=1, routed) 0.457 1.116 pll_i/inst/clk_in1_clk_wiz_1 MMCME3_ADV_X1Y0 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT1) -2.474 -1.358 r pll_i/inst/mmcme3_adv_inst/CLKOUT1 net (fo=1, routed) 0.209 -1.149 pll_i/inst/clk_out2_clk_wiz_1 BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O) 0.031 -1.118 r pll_i/inst/clkout2_buf/O X2Y0 (CLOCK_ROOT) net (fo=2, routed) 0.576 -0.542 pll_clk_6 SLICE_X49Y58 FDRE r bar_reg__0/C clock pessimism 0.421 -0.121 clock uncertainty 0.182 0.061 SLICE_X49Y58 FDRE (Hold_DFF2_SLICEL_C_D) 0.056 0.117 bar_reg__0 ------------------------------------------------------------------- required time -0.117 arrival time 0.210 ------------------------------------------------------------------- slack 0.093
먼저 몇 가지 분명한 차이점이 있습니다. Path Type은 이전의 Setup이 아니라 Hold입니다. 예상됩니다. 그런 다음 setup path에 대해 말한 것과 반대인 "Min at Fast Process Corner"라고 표시됩니다. 이 계산에서는 data path의 최대 delays가 아닌 최소 delays를 사용합니다. 이는 data input이 너무 일찍 변경되는 상황에 대한 최악의 경우 계산에 적합합니다.
Requirement는 0 ns로, hold path에 일반적입니다. clocks 의 주파수는 여기에서 역할을 하지 않습니다. 검토되는 시나리오는 두 clocks가 동시에 rising edge를 갖는 경우입니다.
clock paths의 경우 source clock path 에 있는 각 구성 요소의 delays는 destination clock path 의 동일한 delays 보다 일관되게 짧습니다(더 길지는 않음). 다시 한 번 이것은 이 계산의 목적과 일치합니다. 왜냐하면 최악의 경우는 clock edge가 두 번째 flip-flop에 도착하는 것과 관련하여 data가 너무 일찍 변경되는 경우이기 때문입니다. 이전 페이지 에서 Multi-corner timing analysis 에 대해 설명했습니다.
하지만 이 timing report 의 가장 중요한 점은 slack이 작다는 것입니다. 0.093 ns만. 이는 도구가 요구 사항을 충족하기 위해 노력해야 함을 나타내는 경우가 많습니다. 그러나 작은 slack이 반드시 해결해야 할 문제가 있음을 나타내는 것은 아닙니다.
timing analysis가 thold용으로 만들어지면 소형 slack이 꽤 흔합니다. 그렇다면 이 path가 의심스러운 이유는 무엇입니까? 주로 위에서 언급한 것처럼 동일한 slice (SLICE_X49Y58)의 두 flip-flops 사이에 있는 더 큰 routing delay 때문입니다. place and route의 초기 단계에서 소프트웨어가 이 두 flip-flops사이에서 thold 요구 사항을 충족하지 못하는 오류를 감지했을 가능성이 있습니다. 그래서 이것은 어떻게 수정 되었습니까?
thold 요구 사항을 충족하지 못한다는 것은 data signal이 두 번째 flip-flop의 clock edge 에 비해 너무 일찍 도착한다는 의미입니다. 이는 data path에 인위적으로 delay을 추가하여 수정합니다. 결과적으로 data input은 두 번째 flip-flop에서 조금 더 나중에 값을 변경합니다. 이 도구는 아마도 두 flip-flops 사이의 배선을 더 길게 만들었을 것입니다. 이것은 routing delay을 증가시키고 thold의 문제를 해결합니다. 이러한 delay 의 증가는 tsu 요구 사항을 충족하는 데 문제를 일으킬 수 있었지만 이 경우에는 그러한 문제가 없었습니다. timing constraint는 이 path를 위해 달성되었습니다. (즉, tsu 및 thold 에 대한 요구 사항이 모두 충족됨).
그럼에도 불구하고 이 예는 thold 로 문제를 해결해야 할 필요성이 어떻게 tsu와 무관해 보이는 문제를 일으킬 수 있는지 보여줍니다. 이것은 logic delay 와 routing delay 사이의 path의 비율이 정말 낮을 때 염두에 두어야 할 사항입니다. 물론 큰 routing delay, 특히 높은 fan-out에 대한 다른 가능한 이유가 있습니다. 그러나 fan-out가 낮을 때(이 경우 fan-out가 1인 경우) thold 문제를 해결하기 위해 도구에서 의도적으로 큰 routing delay을 삽입했는지 물어볼 가치가 있습니다.
그런데 왜 clocks가 두 개인 경우에만 thold 에 문제가 있었을까요? 대답은 두 개의 clocks를 사용하는 경우 clock edges가 두 개의 flip-flops각각에 도착하는 시점에 대한 불확실성이 더 크다는 것입니다. 여러 요인, 특히 clock skew 및 jitter가 이러한 불확실성에 기여합니다. thold 에 대한 계산은 0 ns 에서 0 ns로 이루어지기 때문에 이 계산은 clock edges가 도착하는 시기에 대한 작은 불확실성에 더 민감합니다.
따라서 두 개의 related clocks 와 관련된 불확실성은 종종 thold 요구 사항을 충족하기 위해 수정 조치가 필요합니다. 물론 이러한 수정은 도구에 의해 자동으로 이루어집니다. 그럼에도 불구하고 timing constraints를 달성하는 데 문제가 있을 때 이러한 수정 사항을 인식하는 것이 중요합니다.
요약
이 시리즈의 마지막 두 페이지는 특정 timing constraint의 결과인 timing reports 의 몇 가지 예를 보여줍니다. 이 모든 timing reports는 logic의 구체적이고 간단한 예와도 관련이 있습니다. 이 예제가 timing의 기본 사항을 이해하는 데 도움이 되었기를 바랍니다.
이 시점에서 하나 이상의 LUT를 포함하는 paths 에 동일한 원칙이 어떻게 적용되는지 확인하려면 자신의 design의 timing reports를 살펴보는 것이 좋습니다.
다음 페이지에서는 timing 문제와 해결 방법에 대한 논의를 시작합니다.