이 페이지는 타이밍(timing)에 관한 연재 글 모음의 일부입니다. 이전 페이지에서는 타이밍 제약 조건(timing constraints)의 이론적 기초를 살펴보았습니다. 이제는 이 이론이 실제로 어떻게 적용되는지 알아볼 차례입니다.
개요
이 페이지에서는 클록의 주파수를 규정하는 가장 중요한 타이밍 제약 조건을 소개합니다. 이어서 타이밍 리포트가 하나의 경로(path)를 어떻게 분석하는지 자세한 예를 들어 살펴봅니다.
타이밍 리포트의 분석 내용은 고급 주제처럼 보일 수 있지만 사실 그렇지 않습니다. 타이밍 제약 조건은 툴이 설계를 타이밍 분석할 때 그 방향을 제어하고, 충족해야 할 정확한 요구사항을 설정하는 데 목적이 있습니다. 따라서 타이밍 제약 조건을 이해하려면 타이밍 분석 자체를 들여다봐야 합니다. 그리고 그 타이밍 분석은 타이밍 리포트에 나타납니다.
게다가 타이밍 제약 조건을 그냥 작성하기만 해서는 부족합니다. 이 제약 조건이 실제 설계에서 제대로 동작하는지 확인할 수 있어야 합니다. 그러한 확인은 타이밍 리포트를 깊이 이해해야만 가능합니다. 그러한 이해가 없으면 목적을 달성하지 못하는 타이밍 제약 조건을 잘못 의존하게 되기 쉽고, 나중에 로직 설계가 왜 제대로 동작하지 않는지 의아해하게 됩니다.
모든 FPGA 툴은 타이밍 리포트를 텍스트 파일로 만들어 내며, 여기서 보여 주는 리포트가 바로 그런 파일입니다. 툴에는 똑같은 정보를 그래픽 인터페이스로 보여 주는 기능도 있습니다. 이 그래픽 인터페이스는 때로 도움이 되고 때로 혼란스러울 수 있으므로, 우선 텍스트 리포트로 작업하는 것이 중요한 첫 단계입니다.
주기 제약 조건
가장 유용한 타이밍 제약 조건은 주기 제약 조건입니다. 이것은 클록 신호의 주파수를 툴에 알려 줍니다.
예를 들어, 로직 설계가 아래 Verilog 모듈 하나로만 이루어져 있다고 가정해 보겠습니다.
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 신호가 클록으로 사용되고, 이 신호가 외부 포트(즉 FPGA의 물리적 핀에 연결된 신호)라는 점이 분명합니다.
@clk의 주파수가 250MHz(4ns)라면 다음과 같은 타이밍 제약 조건이 필요합니다.
create_clock -period 4 -name clk [get_ports clk]
이 명령의 의미는 다음과 같습니다. “@clk라는 이름의 클록이 I/O 포트에 존재한다. 이 클록의 주기는 4ns이다. 만약 나중에 이 클록을 가리키는 다른 타이밍 제약 조건이 있다면 그 제약 조건은 ‘clk’라는 이름을 사용하여 이 클록을 가리킨다.”
참고:
- “period” 매개변수의 값은 해당 클록의 실제 주기여야 합니다. “추가 안전”을 위해 더 작은 값을 고르면 안 됩니다. 이는 과도 제약(overconstraining)이며, 그렇게 해야 할 이유는 어떤 경우에도 없습니다. 만약 그렇게 하는 것이 도움이 된다면 그때는 해결해야 할 다른 문제가 있는 것입니다.
- 비동기 리셋(asynchronous reset)을 사용하는 경우, create_clock으로는 이 리셋 신호에 대한 플립플롭의 타이밍 요구사항 위반을 막지 못할 수 있습니다. 이에 대해서는 별도 페이지에서 설명합니다.
타이밍 분석
이제 @foo_reg에서 시작하여 @bar에서 끝나는 경로의 셋업 요구사항에 대한 Vivado 타이밍 분석을 살펴보겠습니다. 다시 말해, 다음 Verilog 표현식으로 만들어지는 경로입니다.
bar <= !foo_reg;
여기에서 보여 주는 타이밍 분석은 세 부분으로 이루어져 있으며 타이밍 리포트에는 다음 순서로 나타납니다.
- 첫째, 경로의 타이밍 분석 결과 요약과 몇 가지 추가 정보를 담은 헤더입니다.
- 둘째, 클록 엣지가 발생한 시점부터 두 번째 플립플롭(이 예에서는 @bar)의 입력에 안정적인 로직 상태가 나타날 때까지 걸리는 시간을 계산한 부분입니다.
- 셋째, 타이밍 요구사항을 충족하려면 두 번째 플립플롭의 입력이 언제까지 안정적이어야 하는지를 계산하는 부분입니다.
이 세 부분을 아래에서 각각 보여 주고 설명합니다. 타이밍 리포트에는 각 부분 사이에 눈에 띄는 구분선이 없다는 점에 유의하세요. 특히 두 번째 부분이 끝나고 세 번째 부분이 시작되는 지점을 리포트만 보고 알아차리기는 쉽지 않습니다. 세 번째 부분의 시작은 리포트를 읽는 사람이 내용을 보고 직접 파악해야 합니다.
여기서 Vivado 타이밍 리포트를 예로 들었지만, Quartus와 다른 여러 FPGA 툴들도 동일한 방법론을 사용합니다. 다른 툴의 타이밍 리포트는 대개 정보를 조금씩 다른 방식으로 보여 줍니다. 그러나 이 리포트들의 이론적 배경은 동일합니다. 그렇기 때문에 이 예를 살펴보는 것은 다른 FPGA 툴을 사용할 때도 도움이 됩니다.
우선 타이밍 리포트의 첫 번째 부분은 잠시 건너뛰고, 앞의 두 부분을 살펴본 뒤 다시 돌아오겠습니다. 이 순서로 설명하는 것이 이해하기 쉽습니다. 그 전에 몇 가지 일반적인 이야기를 먼저 하겠습니다.
타이밍 분석의 전략
이전 페이지에서 보여 준 단순한 정적 타이밍 분석과 달리, 실제 타이밍 분석에서는 클록의 불완전성을 고려해야 합니다. 이를 위해 지연 계산은 클록의 원점, 예를 들어 클록의 물리적 입력 핀에서 시작합니다. 단순한 데이터 경로 지연 계산(이전 페이지에서 설명)이 데이터 경로의 지연만 고려하는 것과는 다른 점입니다.
따라서 이론적 실험은 다음과 같습니다. 클록의 원점에서 클록 엣지와 함께 스톱워치를 켭니다. 그 클록 엣지가 첫 번째 플립플롭으로 이동하여 그 플립플롭을 동작시킬 때까지 스톱워치를 계속 돌립니다. 플립플롭이 출력을 갱신하면서 갱신된 신호가 목적지로 이동하는 시간도 계속 측정하고, 그 신호가 두 번째 플립플롭에 도달하면 스톱워치를 멈춥니다.
다음 단계는 그 결과가 충분히 좋은지 확인하는 것입니다. tsu 요구사항의 관점에서는 신호가 다음 클록 엣지에 비해 충분히 일찍 도착했는지를 확인하는 것입니다.
그런데 여기서 기준이 되는 것은 두 번째 플립플롭에 도달하는 클록 엣지입니다. 그 클록 엣지는 언제 도착할까요?
이를 알아내기 위해 클록의 원점에서 다음 클록 엣지와 함께 스톱워치를 다시 켭니다. 그리고 이 두 번째 클록 엣지가 두 번째 플립플롭에 도달하면 스톱워치를 멈춥니다. 출발점은 같지만 클록 엣지는 더 나중이고, 도착점도 다릅니다.
이 이론 실험이 끝나면 두 번째 클록 엣지가 두 번째 플립플롭에 언제 도착하는지 알 수 있습니다. tsu 요구사항을 충족하려면 이 클록 엣지에 비추어 플립플롭의 입력이 충분히 일찍 안정되어야 합니다.
첫 번째 이론 실험의 스톱워치는 데이터가 두 번째 플립플롭에서 안정화되는 시각을 보여 줍니다. 두 번째 실험의 스톱워치는 같은 플립플롭에 클록 엣지가 도착하는 시각을 보여 줍니다. 남은 일은 이 두 숫자를 비교하여 그 차이가 tsu 요구사항보다 충분히 큰지 확인하는 것뿐입니다.
이 방법을 쓰면 클록과 관련된 불확실성도 고려할 수 있습니다. 두 이론 실험 모두에 최악의 시나리오를 적용할 수 있기 때문입니다. 셋업 시간 계산에서는 첫 번째 실험(스톱워치)에 사용하는 모든 지연의 상한값을 적용합니다. 그 결과는 신호가 두 번째 플립플롭 입력에 도착할 수 있는 가장 늦은 시각을 보여 줍니다. 반면 두 번째 실험(스톱워치)에서는 모든 지연의 하한값을 적용합니다. 그 결과는 두 번째 클록 엣지가 두 번째 플립플롭에 도착할 수 있는 가장 이른 시각입니다.
즉, 신호는 가능한 한 늦게 도착하고 클록 엣지는 가능한 한 일찍 도착하는 시나리오로 계산합니다. 이 조건에서 셋업 시간 요구사항이 충족된다면 실제로도 항상 충족된다고 확신할 수 있습니다.
홀드 시간(hold time) 계산에서는 그 반대입니다. 첫 번째 실험에는 최소 지연을 사용하고 두 번째 실험에는 최대 지연을 사용합니다.
소스 경로 계산
앞에서 말했듯이 타이밍 리포트의 첫 번째 부분은 나중에 보여 줍니다. 이제 두 번째 부분인 소스 경로 계산을 살펴보겠습니다. 이 계산은 두 구간으로 이루어져 있습니다.
- 소스 클록 경로(Source Clock Path)는 FPGA 클록 입력 핀의 상승 엣지에서 시작하여, 그 상승 엣지가 @foo_reg의 클록 입력에 도달할 때 끝납니다.
- 데이터 경로(Data Path)는 @bar의 데이터 입력이 새 값으로 갱신될 때까지의 여정을 이어서 계산합니다. 이 구간은 이전 페이지에서 살펴본 단순한 정적 타이밍 분석에 해당합니다.
이 두 구간을 합하면 FPGA 외부 클록 핀의 상승 엣지가 발생한 이후부터 데이터가 두 번째 플립플롭에 도달할 때까지 걸리는 시간이 계산됩니다.
이에 해당하는 타이밍 리포트의 부분은 다음과 같습니다.
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
------------------------------------------------------------------- -------------------
이 부분의 각 행은 로직 요소 하나 또는 배선 하나를 나타냅니다. “Delay type”이 “net”이면 그 행은 배선에 해당합니다. 이러한 종류의 지연은 모두 라우팅 지연, 즉 신호가 한 로직 요소에서 다른 로직 요소로 전파되는 데 걸리는 시간입니다.
“Incr” 열은 경로 안의 각 요소가 기여하는 지연량을 보여 줍니다. “Path” 열은 그 지점까지의 누적 지연을 보여 줍니다.
중간에 있는 가로선은 소스 클록 경로의 끝과 데이터 경로의 시작을 나타냅니다. 이제 두 경로의 지연을 좀 더 자세히 살펴보겠습니다.
처음 일곱 개의 지연 항목은 AG12라는 입력 핀(이 핀의 물리적 위치)과 관련된 것입니다. 이 리포트에 따르면 입력 핀과 그에 딸린 로직이 기여하는 총 지연은 1.731ns입니다.
글로벌 클록 버퍼는 입력에서 출력까지 0.101ns를 추가로 기여합니다. 그다음에는 글로벌 클록의 라우팅 지연이 이어지는데, 1.389ns로 비교적 큰 값입니다. 이것은 클록 신호가 @foo_reg의 클록 입력에 도달하는 데 걸리는 시간입니다. 이 지연이 큰 이유는 이 신호를 분배하기 위해 글로벌 클록 버퍼와 클록 트리를 사용하기 때문입니다. 클록 트리는 FPGA의 넓은 영역에 클록을 모든 목적지에 같은 지연으로 분배하기 위한 라우팅 자원입니다. 따라서 이 예처럼 클록이 도달하는 목적지가 몇 개뿐이어도 지연이 큽니다. 이 예에서 클록의 팬아웃(fan-out)은 3개뿐입니다.
이 시점에서 클록은 마침내 플립플롭이 들어 있는 슬라이스(slice)에 도달합니다. 이 예에서는 SLICE_X49Y58입니다. 그러므로 여기가 소스 클록 경로의 끝입니다. 리포트의 가로선은 데이터 경로의 시작을 나타냅니다. 이전 페이지의 예에서는 바로 여기서 단순 정적 타이밍 분석이 시작되었습니다.
오른쪽 Netlist Resources 열을 보면 가로선 바로 위 행에 “foo_reg_reg/C”라고 되어 있고, 그다음 행에는 “foo_reg_reg/Q”라고 표시되어 있습니다. 즉 가로선 다음 행의 지연 항목이 @foo_reg 플립플롭의 클록-출력 지연(C에서 Q까지)입니다. 이 지연은 0.138ns입니다. “FDRE”는 Data, Reset, Enable을 갖춘 플립플롭을 뜻합니다.
그다음에는 LUT까지의 라우팅 지연(0.241ns), LUT 내부의 전파 지연(propagation delay, 0.244ns), 두 번째 플립플롭까지의 라우팅 지연(0.046ns)이 이어집니다. 라우팅 지연이 아주 작은 이유는 모든 요소가 하나의 슬라이스에 들어 있기 때문입니다.
이 부분을 요약하면, 클록 엣지가 외부 핀에서 첫 번째 플립플롭의 클록 입력까지 도달하는 데 3.221ns가 걸렸습니다. 그 후 갱신된 신호가 두 번째 플립플롭의 입력에 도착할 때까지 0.669ns가 걸렸습니다(3.890 − 3.221 = 0.669ns). 전체적으로 외부 핀의 클록 엣지부터 최종 목적지(두 번째 플립플롭의 데이터 입력)에 안정적인 신호가 나타날 때까지의 시간은 3.890ns입니다. 이것은 최악의 경우를 기준으로 한 계산입니다.
그럼 이제 이 도착 시각이 충분히 빨랐는지, 셋업 시간 요구사항이 충족되는지 물어볼 차례입니다.
목적지 클록 경로
이 두 번째 계산의 목적은 클록 엣지가 외부 핀에서 두 번째 플립플롭의 클록 입력까지 얼마나 빨리 이동할 수 있는지 알아내는 것입니다.
주의할 점은 이 클록 경로의 목적지가 두 번째 플립플롭이라는 것입니다. 이전 계산의 클록 경로에서는 목적지가 첫 번째 플립플롭이었으므로 혼동하지 마세요.
다른 차이점도 있습니다.
- 클록 경로만 계산됩니다. 다시 말해 이전 계산과 비교하면 가로선까지의 구간만 고려합니다.
- 이론적 스톱워치는 0이 아니라 4ns부터 시작합니다. 이 계산의 목적은 데이터 신호가 셋업 시간 요구사항을 충족할 만큼 일찍 도착하는지 판별하는 것이기 때문입니다. 따라서 클록에 대한 타이밍 제약 조건(위의 create_clock 명령)에서 정한 두 번째 클록 엣지인 4ns 시점에서 계산을 시작합니다.
- 이 구간에 있는 각 구성 요소의 지연은 더 작은 값을 사용합니다. 이 특정 예에서는 두 플립플롭이 같은 슬라이스에 있으므로 두 계산의 클록 경로가 완전히 같아서 그 차이를 쉽게 볼 수 있습니다. 보통은 이렇게 같지 않습니다. 이에 대해서는 아래에서 자세히 설명합니다.
- 이 계산의 마지막 세 행(클록 페시미즘(clock pessimism), 클록 불확실성(clock uncertainty), Setup_DFF2_SLICEL_C_D)은 로직 구성 요소가 아니라 타이밍 파라미터입니다.
타이밍 분석의 세 번째 부분(목적지 클록 경로)은 다음과 같습니다.
(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를 같은 슬라이스에 배치했기 때문에, 이 특정 사례에서는 이 분석의 클록 경로가 첫 번째 분석의 클록 경로와 같습니다. 따라서 가로선까지의 로직 요소 순서가 이전 분석과 완전히 동일하다는 것을 쉽게 알 수 있습니다. 이 순서 뒤에는 계산을 보정하는 두 가지 타이밍 파라미터, 즉 클록 페시미즘(clock pessimism)과 클록 불확실성(clock uncertainty)이 있습니다. 이 두 가지는 이 페이지 맨 아래에서 각각 다룹니다.
이 계산에서 마지막에서 한 행 위에는 두 번째 클록 엣지가 도착할 수 있는 가장 이른 시각이 나옵니다. 첫 번째 클록 엣지 이후 7.138ns입니다. 셋업 시간 요구사항은 데이터 신호가 이 클록 엣지보다 먼저 안정적이어야 한다는 것입니다. tsu는 얼마나 먼저여야 하는지를 규정합니다. 따라서 데이터가 안정적이어야 하는 가장 늦은 시각을 구하려면 클록 도착 시각에서 tsu를 빼야 합니다.
위의 예에서 tsu는 음수이며 −0.067ns입니다. 따라서 최종 결과는 7.138 − (−0.067) = 7.205ns입니다. 다시 말해 데이터는 첫 번째 클록 엣지 이후 7.205ns까지는 두 번째 플립플롭에서 안정적이어야 합니다.
이전 계산에서는 데이터가 이 클록 엣지 이후 최악의 경우 3.890ns에 안정화되는 것으로 나왔습니다. 따라서 요구사항을 충분히 만족하며 여유도 있습니다. 요구사항과 보장된 시각의 차이는 7.205 − 3.890 = 3.315ns입니다. 즉 슬랙(slack)은 3.315ns입니다.
타이밍 분석의 요약
이제 앞에서 계산 부분보다 먼저 나오는 타이밍 리포트의 첫 번째 부분으로 돌아갈 차례입니다. 이 부분은 주요 결과를 요약하며, 계산에 등장하는 몇 가지 값이 무엇을 뜻하는지도 명확히 해 줍니다.
따라서 경로의 타이밍 분석은 실제로 다음과 같은 내용으로 시작된다는 점을 기억하세요.
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)
이 행은 타이밍 제약 조건이 달성되었고(met), 남는 시간(슬랙, slack)이 3.315ns라는 뜻입니다.
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})
이 행들은 검사 대상 데이터 경로가 무엇인지 말해 줍니다. 경로는 시작 위치와 끝 위치(Source와 Destination)로 정의됩니다. 데이터 경로는 @foo_reg의 클록 입력인 foo_reg_reg/C에서 시작하며, bar_reg__0/D의 데이터 입력에서 끝납니다.
또 한 가지는 ‘clk’라는 이름이 언급되면서 그 파형이 설명되어 있다는 점입니다. 여기서 ‘clk’는 create_clock으로 클록에 부여한 이름을 가리킵니다. 이 예에서 ‘clk’는 신호 이름이기도 합니다. 그러나 타이밍 제약 조건의 ‘-name’ 매개변수에 다른 이름을 썼다면, 신호 이름과 무관하게 그 다른 이름이 타이밍 리포트에 나타납니다. 이 예의 타이밍 리포트에서 ‘clk’가 언급된 모든 곳에 해당하는 이야기입니다.
Path Group: clk
여기서 Path Group이 ‘clk’라는 것은 이 경로를 검사하는 이유가 같은 이름의 타이밍 제약 조건이라는 뜻입니다.
Path Type: Setup (Max at Slow Process Corner)
Path Type이 Setup이라는 것은 셋업 시간 요구사항을 검사한다는 뜻입니다. ‘Max at Slow Process Corner’는 데이터 경로의 계산(첫 번째 계산)에 최대 지연을 사용했음을 의미합니다. 여기서 Corner가 무엇인지는 아래에서 설명합니다.
Requirement: 4.000ns (clk rise@4.000ns - clk rise@0.000ns)
앞서 두 가지 이론 실험 각각에 대해 가상의 스톱워치를 시작한다고 했습니다. ‘Requirement’는 이 스톱워치들이 시작되는 시각의 차이입니다. 이 경우에는 타이밍 제약 조건이 요구하는 클록 주기인 4ns입니다.
Data Path Delay: 0.669ns (logic 0.382ns (57.100%) route 0.287ns (42.900%))
Data Path Delay는 첫 번째 계산에서 가로선 아래에 있는 지연들의 합, 즉 데이터 경로의 지연 합계입니다.
이 행에서는 지연이 로직과 라우팅으로 나뉘어 표시됩니다. 로직 요소에서 보낸 시간과 그 사이의 배선에서 보낸 시간이 각각 얼마인지 보여 줍니다. 일반적인 경험 법칙에 따르면 지연의 약 60%는 로직, 나머지는 라우팅이어야 합니다. 따라서 이 예의 경로는 정상적인 상황입니다.
라우팅 지연이 차지하는 비중이 훨씬 커지면 문제를 나타낼 수 있습니다. 특히 경로가 타이밍 제약 조건을 달성하지 못할 때 그렇습니다. 이에 대한 자세한 내용은 다음 페이지의 thold 분석을 다루는 절에서 설명합니다.
Logic Levels: 1 (LUT1=1)
데이터 경로가 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 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.035ns는 비현실적으로 낙관적인 값입니다. 타이밍 제약 조건에 지터(jitter)를 지정하지 않아서 툴이 지터를 0으로 가정했기 때문입니다. 게다가 외부 클록을 FPGA 내부의 PLL 없이 직접 사용하고 있으므로, 고려해야 할 지터 발생 원인이 거의 없습니다.
외부 클록의 지터를 타이밍 제약 조건에 지정하지 않는 것은 실수지만, 실제로는 대개 이렇게 처리합니다. 지터가 타이밍 계산에서 고려되는 다른 요소들에 비해 보통 작기 때문에 문제를 일으키는 경우는 드뭅니다.
Clock Net Delay (Source): 1.389ns (routing 0.002ns, distribution 1.387ns) Clock Net Delay (Destination): 1.218ns (routing 0.002ns, distribution 1.216ns)
이 행들은 클록 버퍼 출력에서 각 플립플롭의 클록 입력까지 클록 신호 자체가 이동하는 데 걸리는 지연입니다. 이 예에서 이 숫자들로부터 얻을 수 있는 정보는 많지 않습니다.
멀티 코너 타이밍 분석
모든 로직 요소의 지연은 온도, 공급 전압 등 몇 가지 불확정 파라미터에 따라 달라집니다. 또한 FPGA 생산 과정에서 발생하는 정확도 편차를 가리켜 ‘공정(process)’이라고 부릅니다. 모든 FPGA가 데이터시트 사양을 충족하는지 테스트를 거치지만, 개별 로직 요소의 동작에는 여전히 일부 불확실성이 남아 있습니다.
FPGA 툴은 각 경로에 대해 ‘코너(corner)’라고 부르는 몇 가지 극단적인 시나리오로 타이밍 분석을 수행합니다. 예를 들어 한 시나리오는 허용되는 최저 온도에 가장 빠른 공정(즉, 우연히 지연이 작게 제조된 FPGA)을 결합한 것입니다. 두 번째 시나리오는 최고 온도와 가장 빠른 공정을 결합한 것입니다. 세 번째와 네 번째 시나리오는 같은 조합을 가장 느린 공정으로 반복한 것입니다.
즉, 이 예에서는 온도와 공정이라는 두 파라미터의 극한 조건에 대해 타이밍 분석을 수행합니다. 이것을 4코너 타이밍 분석이라고 합니다. 그러나 이것은 멀티 코너 타이밍 분석을 수행하는 여러 방식 중 하나일 뿐입니다. 각 FPGA 툴은 서로 다른 방식으로 타이밍 분석을 수행합니다.
그러나 툴이 어떤 코너들을 검사하든, 항상 최악의 경우가 타이밍 분석의 결과로 간주됩니다. 즉 툴은 각 코너에 대해 슬랙(slack)을 계산하며, 가장 낮은 슬랙이 실제 결과입니다.
툴은 각 FPGA에 적합한 멀티 코너 타이밍 분석을 수행하도록 프로그래밍되어 있으므로 이 주제를 깊이 이해할 필요는 없습니다. 다만 타이밍 리포트를 읽을 때 그 리포트가 단일 코너에 대한 것인지, 모든 코너를 종합한 결과(즉 최악의 경우)인지 확인하는 것이 중요합니다. 특히 Quartus에서는 혼동할 가능성이 있습니다.
다음에는 클록 페시미즘 제거와 클록 불확실성에 대해 다룹니다. 비교적 심화 주제입니다. 타이밍 계산의 세부 사항에 관심이 없다면 이 연재의 다음 페이지로 건너뛰어도 좋습니다.
클록 페시미즘 제거
두 플립플롭이 우연히 같은 슬라이스에 있기 때문에, 두 계산의 클록 경로 지연(클록 엣지가 슬라이스에 도달할 때까지의 시간)을 비교할 수 있습니다. 두 번째 계산에서 이 시간은 2.646ns입니다. 계산이 4ns에서 시작해 6.646ns에서 끝나므로 6.646 − 4 = 2.646ns입니다. 이전 계산에서는 3.221ns였습니다. 차이는 0.575ns입니다.
그 차이가 나는 이유는 첫 번째 계산에는 최대 지연을, 두 번째 계산에는 최소 지연을 사용했기 때문입니다. 최소 지연과 최대 지연의 차이는 제조 공정의 자연스러운 정확도 한계 때문에 지연이 정확히 알려져 있지 않다는 사실을 나타냅니다. 따라서 첫 번째 플립플롭으로 가는 클록 경로와 두 번째 플립플롭으로 가는 클록 경로가 완전히 다르다면 최악의 경우를 고려해야 합니다. 이 최악의 경우는 첫 번째 경로의 모든 지연이 허용 최대치이고 두 번째 경로의 모든 지연이 허용 최소치인 상황입니다. 이것을 클록 페시미즘(clock pessimism)이라고 합니다.
이 차이는 온도나 서로 다른 물리적 FPGA 사이의 차이와는 무관합니다. 두 계산은 같은 온도와 제조 공정을 가정하여 수행됩니다. 이 차이는 각 구간의 지연이 FPGA 사양 안에서 허용 오차를 갖기 때문에 발생합니다.
그런데 두 계산에서 클록 경로가 동일할 때 왜 클록 페시미즘이 계산에 포함되는 걸까요? 정답은 그렇게 계산하는 것이 잘못이기 때문입니다. 목적지 클록 경로에 ‘clock pessimism’이라는 제목의 행이 있는 이유가 바로 그런 잘못을 보정하기 위한 것입니다. 이 행은 지연에 0.527ns를 더해 보정합니다. 실제로는 ‘clock pessimism removal’(CPR)이라고 불러야 맞습니다.
클록 페시미즘 제거의 핵심은 두 계산에서 동일한 클록 경로 구간에 대해 불필요하게 서로 다르게 적용된 최소 지연과 최대 지연의 차이를 없애는 것입니다. 툴은 두 계산의 클록 경로를 비교하여 공통 구간을 찾아냅니다. 그리고 공통 구간의 모든 지연 차이를 합산한 값이 제거해야 할 클록 페시미즘입니다.
앞에서 말했듯이 두 클록 경로의 차이는 0.575ns였습니다. 그런데 실제로 적용된 클록 페시미즘은 0.527ns뿐입니다. 즉 줄인 양이 0.048ns 더 작습니다. 그 이유는 슬라이스 내부에 두 계산이 공유하지 않는 작은 클록 경로 구간이 있기 때문입니다. 슬라이스 안에서 한 배선은 첫 번째 플립플롭으로 가고 다른 배선은 두 번째 플립플롭으로 가는데, 이 두 배선의 지연은 서로 다를 수 있습니다.
클록 불확실성
타이밍 계산에서는 클록 경로 계산에서 0.035ns를 빼 주었습니다. 이로써 타이밍 계산은 더 엄격해집니다.
클록 불확실성(clock uncertainty)은 클록 엣지 사이의 시간에 영향을 주는 모든 무작위 요인을 반영합니다. 이러한 무작위성은 클록 지터라고 하며, 다양한 노이즈와 전자 회로의 무작위 동작 때문에 발생합니다.
계산에서 0.035ns를 빼는 것은 타이밍 제약 조건(create_clock)에서 클록 주기를 4ns로 정의했더라도 실제 주기는 무작위적이라는 사실을 반영합니다. 그 결과 두 클록 엣지 사이의 시간이 더 짧아질 수 있습니다. 얼마나 짧아질까요? 이 계산에서는 두 클록 엣지 사이의 시간이 3.965ns보다 짧아지지 않는다고 가정했습니다(4 − 0.035 = 3.965ns).
이 가정이 타당한 근거가 있는 걸까요? 이는 꽤 어려운 질문입니다. 클록 지터의 예측은 복잡한 주제이며 이번 타이밍 제약 조건 논의 범위를 훨씬 벗어나기 때문입니다. 그렇지만 클록 지터는 타이밍 제약 조건과 무관하게 로직 설계에서 여러 문제의 원인이 될 수 있으므로, 이 주제를 더 공부해 두는 것이 좋습니다.
이상으로 클록 주기 제약 조건에 관한 두 페이지 중 첫 번째 페이지를 마칩니다. 더 배울 내용은 다음 페이지에 있습니다...