이 페이지는 타이밍(timing)에 관한 연재 글 모음의 일부입니다. 지금까지의 페이지에서는 타이밍 계산의 이론, 클록 주기 제약 조건, 타이밍 클로저(Timing Closure)의 원리를 다뤘고, 몇 가지 중요한 Tcl 명령도 소개했습니다. 이 페이지에서는 특정 경로(path)에 대한 타이밍 제약 조건을 정의하는 방법을 설명합니다.
서론
타이밍 제약 조건을 작성할 때의 목표는 짧고, 간결하며, 이해하기 쉬운 것이어야 합니다. 그래야 혼동과 실수의 위험이 줄어듭니다. 가능하다면 FPGA 내부 경로에 대한 타이밍 제약 조건은 두 가지 유형만으로 구성되는 것이 가장 좋습니다. 클록 주기 제약 조건(예: create_clock)과 클록 그룹 제약 조건(예: set_clock_groups)이 그것입니다.
하지만 특정 경로에는 특별한 규칙이 필요한 경우가 많습니다. 이러한 특별한 규칙을 타이밍 예외(Timing Exceptions)라고 합니다. 이름이 뜻하듯이 이러한 타이밍 제약 조건은 주로 기존의 타이밍 제약 조건을 대체(override)하기 위한 것입니다. 또한 원래는 아무런 타이밍 요구사항이 없었을 경로에 대해 타이밍 요구사항을 지정하는 데에도 사용할 수 있습니다.
SDC 문법에서 이러한 목적을 위한 명령은 주로 다음과 같습니다.
- set_false_path: 선택한 경로에 타이밍 요구사항을 적용하지 말 것을 툴에 알립니다.
- set_max_delay: tsetup 적용을 위한 요구사항을 정의합니다.
- set_min_delay: thold 적용을 위한 요구사항을 정의합니다.
- set_multicycle_path: 클록 인에이블(clock enable) 신호에 의해 제어되는 로직의 요구사항을 완화합니다.
다른 문법을 사용하는 툴에도 비슷한 명령이 있을 가능성이 높습니다.
이 명령들의 인자(argument)는 무엇보다도 어떤 경로에 이 명령이 적용되어야 하는지를 정의합니다. 이것에 대해서는 아래에서 설명합니다.
관련된 주제 가운데 두 가지는 다른 페이지에서 다룹니다.
- I/O 타이밍 제약 조건을 위한 별도 페이지가 있습니다. 따라서 아래의 논의는 내부 경로(즉, 로직 패브릭에서 순차 로직 요소로 들어가고 순차 로직 요소에서 나오는 경로)에 이 명령들을 사용하는 경우로 한정합니다.
- set_multicycle_path는 별도 페이지에서 다룹니다.
False path(가짜 경로)
가짜 경로(false path)는 그러한 제약을 요청하는 타이밍 제약 조건 때문에 툴이 무시하는 경로입니다. 다시 말해, 우리가 그렇게 지시했기 때문에 툴은 일부러 가짜 경로에 어떠한 타이밍 요구사항도 적용하지 않습니다.
이것은 제약 조건이 없는 경로(unconstrained path)와 혼동해서는 안 됩니다. 제약 조건이 없는 경로는 툴이 적용할 타이밍 제약 조건을 갖지 못한 경로입니다. 가짜 경로와 마찬가지로 툴은 이 경로에 타이밍 요구사항을 적용하지 않지만, 그 이유는 다릅니다. 요구사항을 적용하지 않는 것이 선택이 아니라, 툴이 어떤 요구사항을 적용해야 할지 모르기 때문입니다.
FPGA 설계에는 제약 조건이 없는 경로가 없어야 합니다. 그렇기는 해도, 우리가 툴로 하여금 무시하도록 만들고 싶은 경로는 자주 있습니다. 이러한 경로는 타이밍 제약 조건을 통해 가짜 경로로 표시되어야 합니다. 그 이유는 이렇습니다. 타이밍 리포트를 읽을 때 제약 조건이 없는 경로의 수가 항상 0임을 확인해야 합니다. 이 숫자가 0이 아니라면 실수를 찾아보아야 합니다. 제약 조건이 없는 경로가 0이 아닌 것을 받아들이는 데 익숙해지면, 타이밍 제약 조건에 문제가 있어도 놓치기 쉬워집니다.
가짜 경로를 선언하는 데에는 두 가지 가능한 이유가 있습니다.
- 그 경로에 툴이 타이밍 요구사항을 적용해야 하는 상황에서, 가짜 경로 선언은 툴에게 그 경로를 대신 무시하라고 말합니다.
- 그 경로에 대한 타이밍 제약 조건이 아예 없는 경우입니다. 이 경우 가짜 경로 선언의 목적은 제약 조건이 없는 경로의 수를 0으로 유지하는 것입니다.
실용적으로는 이 두 시나리오 중 어느 것이 적용되는지는 중요하지 않습니다. 경로에 타이밍 요구사항이 필요 없다면 가짜 경로로 선언해야 합니다.
클록 도메인 크로싱(clock domain crossing)과 관련하여 set_false_path를 사용하는 것은 흔한 실수입니다. 이 주제는 뒤에서 더 자세히 다룹니다. 사실 I/O 포트와 관련된 경우를 제외하면 set_false_path를 사용하는 것이 올바른 상황은 그리 많지 않습니다.
set_false_path에 적용할 경로 선택하기
이 명령이 적용될 경로를 선택하는 방법은 여러 가지가 있습니다. 선택할 수 있는 범위가 넓음에도 불구하고, 경로 선택은 대개 -from과 -to라는 두 인자로 수행합니다. 예를 들어:
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
이 예에서 set_false_path 명령은 @source 레지스터에서 시작하여 @dest 레지스터에서 끝나는 경로에 적용됩니다.
get_cells가 -from과 -to에 로직 요소를 나타내는 객체를 제공한다는 점에 유의하세요. 이전 페이지에서 다룬 다른 명령들(get_pins, get_nets, get_ports, get_clocks)도 사용할 수 있습니다. 그러나 -from 및 -to와 함께 무엇을 쓸 수 있는지에 대한 규칙은 FPGA 툴마다 다릅니다.
툴이 객체에 대한 참조를 자연스럽게 기대하는 방식으로 해석하지 않을 수 있다는 점에 유의하세요. 툴은 경고조차 없이 객체의 일부 또는 전부를 무시할 수도 있습니다. 실제로 get_* 명령이(예: 검색 패턴의 실수로) 객체를 하나도 찾지 못하면, 타이밍 예외에 포함되는 경로도 하나도 없습니다. 심지어 이런 경우에도 경고가 나오지 않을 수 있습니다.
따라서 타이밍 리포트를 사용하여 타이밍 예외가 의도한 대로 적용되는지 확인하는 것이 중요합니다. 즉, 올바른 경로가 영향을 받고 있고, 타이밍 분석이 정확한 목적(타이밍 요구사항을 적용하지 않음)을 수행하고 있는지 확인해야 합니다.
경로를 선택하는 또 하나의 유용한 인자로 -through가 있습니다. 이름이 뜻하듯이 이 인자는 특정 로직 요소를 통과하는 경로를 선택합니다.
모든 기능을 파악하려면 공식 문서를 읽는 데 시간을 투자할 가치가 있습니다. 예를 들어 명령의 효과를 상승 클록 엣지나 하강 클록 엣지에만 국한시키는 것도 가능합니다. 또 tsetup 분석만 하거나 thold 분석만 하도록 명령을 제한할 수도 있습니다.
set_false_path 명령은 -from, -to, -through 중 적어도 하나를 인자로 요구합니다(또는 비슷한 의미의 다른 인자). 인자가 둘 이상이면 타이밍 예외는 모든 인자의 조건을 충족하는 경로에만 적용됩니다.
set_false_path의 위험성
가짜 경로의 문제는 실수를 저지르기가 너무 쉽다는 것입니다. 특히 의도한 것보다 더 많은 경로를 포함시켜 버릴 위험이 있습니다. 그렇게 되면 일부 순차 요소가 제대로 동작하지 않을 수 있습니다. 우리는 툴이 그 요소들의 tsu와 thold 요구사항을 보장해 주리라고 잘못 기대합니다. 그러나 실제로 툴은 그 순차 요소로 가는 경로를 마치 가짜 경로인 것처럼 취급합니다. 따라서 툴은 그 경로들에 대해 어떤 타이밍 분석도 하지 않습니다. 이것은 위험한 상황입니다. 툴이 타이밍 제약 조건이 달성되었다고 말할 때 모든 것이 괜찮다는 착각을 만들기 때문입니다. 하지만 실제로는 타이밍 위반에 그대로 노출된 플립플롭과 기타 순차 요소들이 아무 보호 없이 남아 있습니다.
설상가상으로, 어떤 경로가 가짜 경로로 선언되면 그 선언이 대개 가장 높은 우선순위를 가집니다. 따라서 어떤 경로가 실수로 가짜 경로로 선언되면, 그 선언은 반대를 요구하는 다른 타이밍 제약 조건을 대개 무시합니다. 이것은 set_false_path가 다른 타이밍 제약 조건보다 앞에 나타나더라도 대부분 마찬가지입니다. 즉 set_false_path는 "이 경로들은, 내가 이전에 요구했거나 나중에 요구할 것과 무관하게, 가짜 경로다"라고 해석됩니다.
set_min_delay와 set_max_delay
먼저 가짜 경로를 다뤘습니다. 가짜 경로는 선택된 경로 그룹에 대한 타이밍 요구사항을 없애 줍니다. 그런데 때로는 타이밍 요구사항을 취소하는 것이 아니라 지정할 필요가 있습니다. 이것은 set_min_delay와 set_max_delay로 수행합니다. 예를 들어 다음 Verilog 코드를 보겠습니다.
reg x, y;
always @(posedge clk)
y <= x;
그리고 타이밍 제약 조건은 다음과 같습니다.
set_max_delay -from [get_cells x_reg] -to [get_cells y_reg] 3 set_min_delay -from [get_cells x_reg] -to [get_cells y_reg] 1
그렇다면 이 명령들의 의미는 무엇일까요? set_max_delay부터 시작하겠습니다. 이 타이밍 예외를 짧게 설명하자면, 특정 경로에만 적용되는 클록 주기 제약 조건(create_clock)과 비슷하다고 할 수 있습니다.
기억하시겠지만 클록 주기 제약 조건이 정의되면, 툴은 필요한 타이밍 요구사항을 자동으로 적용합니다. tsetup 요구사항을 충족시키기 위해 관련 경로의 최대 지연이 제한됩니다. 마찬가지로 thold를 위해 최소 지연도 제한됩니다.
위의 예에서 set_max_delay 명령에 나오는 값은 3입니다. 이것은 클록 주기가 3ns인 create_clock 명령과 동등합니다. 그러나 set_max_delay의 영향은 특정 경로 그룹으로 제한됩니다. 그것이 차이입니다.
set_min_delay에 관해서는 조금 더 복잡하므로 아래에서 더 자세히 설명합니다.
참고로 set_max_delay라는 이름은 오해의 소지가 있습니다. 이 명령은 경로 자체의 최대 지연을 직접 정의하지는 않습니다. 위 예의 명령으로 영향받는 경로의 지연이 3ns로 제한되는 것은 아닙니다. 3ns 값은 클록 엣지 사이에 허용되는 시간 차이로 적용됩니다. 그리고 이 시간 차이는 순차 요소의 클록 입력에서 측정되는 것이 아니라, 클록들의 원점에서 측정됩니다. 이것은 PLL, 클록 버퍼, 클록 라우팅의 지연도 계산에 포함된다는 뜻입니다. 클록 주기 제약 조건과 마찬가지로, 클록 지연이 타이밍 분석에서 고려됩니다.
-from, -to, -through 및 다른 인자의 의미는 set_false_path와 같습니다. 그러나 일반적으로 set_min_delay와 set_max_delay는 클록 주기 제약 조건을 보정하기 위한 용도로 쓰입니다. 따라서 경로의 양쪽에 순차 요소가 있다고 보통 가정합니다. 그렇기 때문에 -from과 -to는 동기 요소(synchronous element)를 나타내야 합니다. 이를 가리키는 방법에는 여러 가지가 있습니다. 순차 요소 자체를 나타내는 셀 객체, 클록 객체 등이 그 예입니다.
set_min_delay에 대해서도 비슷한 이야기가 있습니다. 클록 주기 제약 조건의 또 다른 결과는 툴이 thold 요구사항을 충족해야 한다는 것입니다. 이를 위해 툴은 같은 클록 사이 또는 관련 클록(related clocks) 사이의 모든 경로에 최소 지연을 적용합니다. 어떤 경로에 대한 타이밍 계산이(양쪽에 같은 클록을 쓰는) create_clock만의 결과라면, 이것은 값이 0인 set_min_delay와 동등합니다. 이것은 같은 클록 엣지가 두 순차 요소에 도착한다는 관념을 반영합니다. 그러나 이것이 그 클록 엣지가 두 순차 요소에 같은 시각에 도착한다는 뜻은 아닙니다. 오히려 각 순차 요소에 대한 클록 엣지는 클록 원점에서 동시에 출발합니다. 클록 원점에서 순차 요소까지의 지연은(tsetup 계산 방식과 비슷하게) 계산에 고려됩니다.
set_min_delay를 사용하면 두 번째 순차 요소에 도착하는 클록 엣지의 시각을 조정할 수 있습니다. 예를 들어 위의 명령은 두 번째 플립플롭에 이 클록 엣지가 1ns 더 늦게 도착하게 만듭니다. 그러면 thold 요구사항을 충족하기가 더 어려워집니다. 아래의 타이밍 리포트 예를 보십시오.
set_min_delay와 set_max_delay를 사용하는 이유는 두 가지가 있을 수 있습니다.
- 툴이 원래 적용하는 타이밍 요구사항이 특정 경로 그룹에 적절하지 않을 때. 예를 들어 메타스태빌리티(metastability) 보호 레지스터에서 시작하는 경로에 타이밍 요구사항을 더 엄격하게 적용해야 하는 경우입니다.
- 해당 경로에 관련된 타이밍 제약 조건이 없을 때. 이런 목적으로 set_max_delay를 사용하려거든, 클록 주기 제약 조건이나 멀티사이클 경로(multicycle path)가 필요한 것은 아닌지 스스로에게 물어보세요.
이 두 명령을 사용할 때는 항상 타이밍 리포트에서 해당 경로들의 타이밍 분석을 주의 깊게 확인하세요. 특히 클록 경로가 계산에서 어떤 역할을 하는지 주의를 기울이세요.
이 페이지 맨 아래에는 set_min_delay와 set_max_delay의 결과를 보여 주는 타이밍 리포트의 예가 있습니다.
지연을 더 정확하게 제어하기
지금까지 살펴본 set_max_delay와 set_min_delay가 제공하는 제어 수준은 (지금까지 설명한 바와 같은) 클록 주기 제약 조건보다 크게 나은 것은 아닙니다. 그런데 클록 경로 지연이 우리가 정의하는 지연에 끼어들지 않기를 원한다면 어떻게 해야 할까요? 경로의 특정 구간의 지연을 제어하고 싶다면요?
일부 FPGA 툴은 이러한 필요에 대해 어떤 해결책도 제공하지 않습니다. 예를 들어 Quartus는 (내가 아는 한) 그러한 가능성을 제공하지 않습니다. 반면 Vivado에는 몇 가지 기능이 있으며, 그중 일부를 간단히 설명하겠습니다.
그중 하나가 datapath_only 옵션입니다. set_max_delay를 사용할 때 타이밍 계산에 클록 경로를 포함하지 않기를 원하는 경우가 있습니다. 예를 들어 경로가 무관한 클록(unrelated clocks) 사이에 있으면 클록 경로를 고려하는 것이 무의미합니다.
datapath_only를 사용하면 두 순차 요소의 클록 경로 지연이 0인 것처럼 타이밍이 계산됩니다. 따라서 계산은 경로의 로직 요소 지연만으로 이루어집니다. 이 지연들의 합은 set_max_delay 명령에 주어진 숫자보다 작아야 합니다(아래 타이밍 리포트 예 참조).
따라서 set_max_delay를 datapath_only와 함께 사용하면 그 의미는 명령 이름이 뜻하는 바에 더 가까워집니다. 다만 경로는 여전히 순차 요소에서 시작하고 끝나야 한다는 점에 유의하세요.
또한 datapath_only에는 몇 가지 특성이 있습니다. 이 옵션을 사용하면 툴은 관련 경로의 thold에 대해 어떤 타이밍 요구사항도 적용하지 않습니다. 다시 말해, 툴은 thold 시나리오에만 가짜 경로 제약 조건이 적용된 것처럼 동작합니다. 관련 경로에 set_min_delay 명령을 추가하더라도 이 명령은 무시됩니다. Vivado가 datapath_only의 영향을 받는 경로에 최소 지연 적용을 거부하는 이유는 분명하지 않습니다.
어떤 시나리오에서든 datapath_only를 set_min_delay의 인자로 사용할 수는 없습니다.
오해를 부르는 기능들
이 절의 제목이 뜻하듯이, 여기 소개하는 것들은 도움이 될 가능성이 낮은 기능들입니다. 다음 절로 건너뛰어도 됩니다.
Vivado는 더 높은 수준의 제어도 허용합니다. 경로의 특정 구간의 지연에 제한을 적용하는 것이 가능합니다. 예를 들어 순차 요소가 아닌 로직 요소를 -from과 -to에 사용하면 어떻게 될까요? 핀과 네트를 사용하면 어떨까요? set_min_delay와 set_max_delay가 무엇을 할까요?
물론 어떤 FPGA 툴을 사용하는지에 따라 다릅니다. 요구사항에 맞는 경로가 없으므로 툴이 그러한 제약 조건을 조용히 무시할 수도 있습니다. 그러나 Vivado는 그러한 제약 조건을 무시하지 않습니다. 다만 결과는 자연스럽게 기대하는 바와 다릅니다. Vivado는 이러한 상황을 "경로 분할(path segmentation)"로 간주하고 응답으로 치명적 경고(critical warning)를 냅니다. 대부분의 경우 이 기능을 사용하는 것은 그것이 일으키는 복잡함에 비해 가치가 없습니다. 자세한 내용은 문서를 참조하세요.
또한 오해를 부를 수 있는 기능이 하나 더 있습니다. Quartus에는 set_net_delay라는 명령이 있습니다. 이것은 설계의 서로 다른 로직 요소 사이에 최소 및 최대 지연을 정의할 수 있게 해 줍니다. 그러나 툴은 구현 과정에서 이러한 타이밍 요구사항을 달성하려고 시도하지 않는 것으로 보입니다. 대신 "report_net_delay"(또는 GUI)로 리포트를 생성할 수 있습니다. 따라서 이 리포트를 통해 set_net_delay로 정의한 조건이 충족되었는지 추론할 수 있습니다. 즉 set_net_delay는 정보를 얻는 데는 사용할 수 있지만, 타이밍 제약 조건으로는 유용하지 않습니다. 다시 말해 set_max_delay와 set_min_delay는 타이밍 제약 조건으로 유효하지만 set_net_delay는 그렇지 않습니다.
요약하면, set_max_delay와 set_min_delay를 평범하게 사용하는 방법보다 더 나아지는 경우는 거의 없습니다. 흥미로운 기능은 아마 Vivado의 datapath_only뿐입니다.
타이밍 제약 조건의 우선순위
복잡한 타이밍 제약 조건의 주요 문제는 하나 이상의 제약 조건이 영향을 주는 경로가 자주 생긴다는 것입니다. 이러한 제약 조건들은 대개 그 경로에 대해 서로 모순되는 타이밍 요구사항을 가집니다. 그러면 어느 제약 조건이 이길까요?
각 FPGA 툴은 이런 종류의 충돌을 해결하는 방법에 대해 고유한 규칙을 가지고 있습니다. 대개 제약 조건의 유형에 따라 결정됩니다. 다른 요소, 특히 경로 선택의 구체성도 역할을 할 수 있습니다.
SDC 기반 타이밍 제약 조건의 경우, 우선순위는 제약 조건의 유형에 따라 달라집니다. 예를 들어 Vivado는 다음 우선순위 순서대로 충돌을 해결합니다. 명령은 높은 우선순위에서 낮은 우선순위 순으로 나열되어 있습니다.
- set_clock_groups(관련 클록 및 무관한 클록의 그룹)
- set_false_path(가짜 경로)
- set_min_delay 및 set_max_delay(최소 지연 및 최대 지연)
- set_multicycle_path(멀티사이클 경로)
- create_clock(클록 주기)
처음 두 명령(set_clock_groups와 set_false_path)은 가짜 경로를 만들며 가장 높은 우선순위를 가진다는 점에 유의하세요. 따라서 이 명령들에 실수로 어떤 경로가 영향을 받지 않는지 확인하는 것이 각별히 중요합니다. 그런 실수는 관련 경로에 대한 모든 타이밍 요구사항 적용을 조용히 꺼 버립니다.
같은 명령이 같은 경로에 두 번 이상 사용되면, 가장 구체적인 명령이 이깁니다. 예를 들어 한 명령에 "-from"과 "-to"가 있고 두 번째 명령에 "-from"만 있다면 첫 번째 명령이 이깁니다. 또 다른 예: 한 명령이 로직 요소를 기준으로 경로를 정의하고(예: get_cells 사용), 두 번째 명령이 클록을 기준으로 경로를 정의한다면(get_clocks 사용), 첫 번째 명령이 이깁니다.
두 명령이 너무 비슷해서 우선순위에 차이가 없다면, 나타나는 순서가 충돌을 해결합니다. 마지막 명령이 이깁니다.
Quartus와 SDC 기반의 다른 툴들도 비슷한 우선순위 규칙을 사용합니다.
그러나 어떤 툴을 사용하든, (create_clock을 대체하는 경우를 제외하고) 타이밍 제약 조건들 사이에 모순이 생기지 않도록 하는 것이 가장 좋습니다. 복잡한 타이밍 제약 조건은 파괴적인 버그가 번성할 수 있는 곳입니다.
일부 FPGA 툴에서는 우선순위 규칙을 우회하는 것이 가능합니다. -reset_path 속성을 사용하면, 이 속성을 사용하는 명령이 적용되는 모든 경로에 대해 이전의 타이밍 예외를 무시합니다. 예를 들어:
set_max_delay -reset_path -from [get_cells source_reg] 2
결론
이 페이지의 서두에서 타이밍 제약 조건은 짧고 단순하며 간결해야 한다고 말했습니다. 타이밍 예외를 추가하면 타이밍 제약 조건은 길어질 뿐만 아니라 더 복잡해지고 이해하기 어려워집니다. 그러니 필요할 때는 타이밍 예외를 사용하되, 주의해서 작성하고 깔끔하게 유지하세요.
타이밍 예외 명령을 작성할 때는 그 목적을 반영하고 그 뒤에 있는 아이디어를 표현하도록 노력하세요. FPGA 툴은 대개 타이밍 제약 조건을 만드는 GUI 마법사를 제공합니다. 출발점으로는 유용할 수 있습니다. 그러나 마법사가 만든 타이밍 제약 조건을 신중하게 생각해 보지 않고 사용하지 마세요. 이 제약 조건이 만들어질 당시에는 올바르더라도, 로직 설계가 발전하고 새 로직이 추가되어도 계속 충실히 동작할까요?
타이밍 예외의 영향을 받는 경로에 대한 타이밍 리포트를 항상 읽으세요. 경로에 적용되는 타이밍 제약 조건이 둘 이상이면 이것은 더욱 중요합니다. 또한 타이밍 요구사항이 잘못될 가능성이 있는 경로에 대해서는 특별한 타이밍 리포트를 만들어 보세요.
기억하세요: 타이밍 리포트를 만들고 읽는 것은 시간 낭비가 아닙니다. 아무리 주의 깊게 문서를 읽더라도(항상 좋은 일입니다), 실수가 일어날 가능성은 항상 있습니다. 특히 가짜 경로는 가장 예상하지 못한 곳에서 발생할 수 있습니다.
보너스: 타이밍 리포트 예제
set_min_delay와 set_max_delay를 이해하는 데 도움이 되도록, Vivado로 만든 타이밍 리포트 몇 개를 소개합니다.
위에서 이 리포트들의 배경이 되는 Verilog 코드가 다음과 같다는 것을 기억하세요.
always @(posedge clk)
y <= x;
그리고 타이밍 제약 조건은 다음과 같습니다.
set_max_delay -from [get_cells x_reg] -to [get_cells y_reg] 3 set_min_delay -from [get_cells x_reg] -to [get_cells y_reg] 1
tsetup에 대한 리포트입니다.
Slack (MET) : 0.360ns (required time - arrival time)
Source: x_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: y_reg/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: 3.000ns (MaxDelay Path 3.000ns)
Data Path Delay: 2.617ns (logic 0.139ns (5.311%) route 2.478ns (94.689%))
Logic Levels: 0
Clock Path Skew: -0.053ns (DCD - SCD + CPR)
Destination Clock Delay (DCD): 2.644ns
Source Clock Delay (SCD): 3.224ns
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.392ns (routing 0.002ns, distribution 1.390ns)
Clock Net Delay (Destination): 1.216ns (routing 0.002ns, distribution 1.214ns)
Timing Exception: MaxDelay Path 3.000ns
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=4, routed) 1.392 3.224 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r x_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y57 FDRE (Prop_DFF_SLICEL_C_Q)
0.139 3.363 r x_reg/Q
net (fo=2, routed) 2.478 5.841 x
SLICE_X49Y57 FDRE r y_reg/D
------------------------------------------------------------------- -------------------
max delay 3.000 3.000
AG12 0.000 3.000 r clk (IN)
net (fo=0) 0.000 3.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.515 3.515 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.066 3.581 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.034 3.615 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.722 4.337 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.091 4.428 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=4, routed) 1.216 5.644 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r y_reg/C
clock pessimism 0.527 6.171
clock uncertainty -0.035 6.136
SLICE_X49Y57 FDRE (Setup_EFF2_SLICEL_C_D)
0.065 6.201 y_reg
-------------------------------------------------------------------
required time 6.201
arrival time -5.841
-------------------------------------------------------------------
slack 0.360
지연 값(3ns)이 두 번째 플립플롭의 클록 경로 시작 시각으로 사용된다는 점에 유의하세요. 다시 말해, 정확히 3ns의 주기 제약 조건이 있는 것과 같습니다.
또한 데이터 경로의 네트가 2.478ns라는 엄청난 지연을 갖는 것에 유의하세요. 이것은 set_min_delay 명령의 결과입니다. 툴은 thold 요구사항을 충족시키기 위해 이 네트에 긴 지연을 넣도록 강제되었습니다.
그런데 말이 나왔으니, 이것은 thold에 대한 타이밍 리포트입니다.
Slack (MET) : 0.057ns (arrival time - required time)
Source: x_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: y_reg/D
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Path Group: clk
Path Type: Hold (Min at Fast Process Corner)
Requirement: 1.000ns (MinDelay Path 1.000ns)
Data Path Delay: 1.141ns (logic 0.049ns (4.294%) route 1.092ns (95.706%))
Logic Levels: 0
Clock Path Skew: 0.029ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 1.684ns
Source Clock Delay (SCD): 1.258ns
Clock Pessimism Removal (CPR): 0.398ns
Clock Net Delay (Source): 0.502ns (routing 0.002ns, distribution 0.500ns)
Clock Net Delay (Destination): 0.585ns (routing 0.002ns, distribution 0.583ns)
Timing Exception: MinDelay Path 1.000ns
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.339 0.339 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.025 0.364 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.015 0.379 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.350 0.729 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.027 0.756 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=4, routed) 0.502 1.258 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r x_reg/C
------------------------------------------------------------------- -------------------
SLICE_X49Y57 FDRE (Prop_DFF_SLICEL_C_Q)
0.049 1.307 r x_reg/Q
net (fo=2, routed) 1.092 2.399 x
SLICE_X49Y57 FDRE r y_reg/D
------------------------------------------------------------------- -------------------
min delay 1.000 1.000
AG12 0.000 1.000 r clk (IN)
net (fo=0) 0.000 1.000 clk_IBUF_inst/I
AG12 INBUF (Prop_INBUF_HRIO_PAD_O)
0.595 1.595 r clk_IBUF_inst/INBUF_INST/O
net (fo=1, routed) 0.042 1.637 clk_IBUF_inst/OUT
AG12 IBUFCTRL (Prop_IBUFCTRL_HRIO_I_O)
0.022 1.659 r clk_IBUF_inst/IBUFCTRL_INST/O
net (fo=1, routed) 0.409 2.068 clk_IBUF
BUFGCE_X1Y0 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.031 2.099 r clk_IBUF_BUFG_inst/O
X2Y0 (CLOCK_ROOT) net (fo=4, routed) 0.585 2.684 clk_IBUF_BUFG
SLICE_X49Y57 FDRE r y_reg/C
clock pessimism -0.398 2.286
SLICE_X49Y57 FDRE (Hold_EFF2_SLICEL_C_D)
0.055 2.341 y_reg
-------------------------------------------------------------------
required time -2.341
arrival time 2.399
-------------------------------------------------------------------
slack 0.057
다시 한번, 지연 값(1ns)이 두 번째 플립플롭의 클록 경로 시작 시각으로 사용된다는 점에 유의하세요. set_min_delay 명령이 없을 때(즉 클록 주기 제약 조건만 있을 때) 이 값은 0ns입니다.
데이터 경로의 네트 지연은 1.092ns입니다. 이것은 thold 요구사항을 충족시키기에 간신히 충분한 값입니다. 그런데 왜 앞에서는 2.478ns였을까요? tsetup의 최악의 경우 계산이 "Max at Slow Process Corner"로 수행되기 때문입니다. 따라서 2.478ns는 해당 네트의 가능한 가장 긴 지연이고, 1.092ns는 가능한 가장 짧은 지연("Min at Fast Process Corner")입니다. 이에 대한 자세한 내용은 멀티 코너 타이밍 분석에 관한 논의를 참조하세요.
세 번째 예는 datapath_only를 보여 줍니다. 제약 조건은 다음과 같습니다.
set_max_delay -datapath_only -from [get_cells x_reg] -to [get_cells y_reg] 3
set_min_delay는 없습니다. 어차피(set_max_delay 명령 뒤에 쓰더라도) 무시되기 때문입니다.
이제 tsetup에 대한 리포트는 다음과 같습니다.
Slack (MET) : 2.482ns (required time - arrival time)
Source: x_reg/C
(rising edge-triggered cell FDRE clocked by clk {rise@0.000ns fall@2.000ns period=4.000ns})
Destination: y_reg/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: 3.000ns (MaxDelay Path 3.000ns)
Data Path Delay: 0.583ns (logic 0.139ns (23.842%) route 0.444ns (76.158%))
Logic Levels: 0
Timing Exception: MaxDelay Path 3.000ns -datapath_only
Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
SLICE_X49Y57 0.000 0.000 r x_reg/C
SLICE_X49Y57 FDRE (Prop_DFF_SLICEL_C_Q)
0.139 0.139 r x_reg/Q
net (fo=2, routed) 0.444 0.583 x
SLICE_X49Y57 FDRE r y_reg/D
------------------------------------------------------------------- -------------------
max delay 3.000 3.000
SLICE_X49Y57 FDRE (Setup_EFF2_SLICEL_C_D)
0.065 3.065 y_reg
-------------------------------------------------------------------
required time 3.065
arrival time -0.583
-------------------------------------------------------------------
slack 2.482
이 타이밍 리포트의 구조는 이전과 같지만, 클록 경로와 관련된 모든 것이 제거되었음을 유의하세요.
네트의 지연이 작습니다. 툴이 긴 지연을 넣을 이유가 없었기 때문입니다. thold 요구사항이 없습니다.
thold에 대한 타이밍 리포트는 보여 드리지 않겠습니다. 타이밍 요구사항 자체가 없기 때문입니다(최소 지연이 가짜 경로로 취급됩니다).
이상으로 타이밍 예외에 대한 일반적인 논의를 마칩니다. 다음 페이지에서는 클록 도메인 크로싱(clock domain crossing)에 필요한 타이밍 예외에 대해 계속 다룹니다.