이 페이지는 timing에 대한 일련의 페이지 에 속합니다. 이전 페이지에서는 timing 계산에 대한 이론을 설명하고 clock period constraint에 대해 논의했으며 timing closure의 원리를 보여주고 몇 가지 중요한 Tcl 명령을 소개했습니다. 이 페이지에서는 특정 paths에 대해 timing constraints를 정의하는 방법을 설명합니다.
소개
timing constraints 작성의 목표는 짧고 간결하며 이해하기 쉬워야 한다는 것입니다. 이렇게 하면 혼란과 실수의 위험이 줄어듭니다. 가능하면 FPGA의 내부 paths 용 timing constraints는 두 가지 유형으로만 구성되어야 합니다. clock period constraints (예: create_clock) 및 clock group constraints (예: set_clock_groups ).
그러나 종종 특정 paths 에는 특정 규칙이 필요합니다. 이러한 특정 규칙을 Timing Exceptions라고 합니다. 이름에서 알 수 있듯이 이 timing constraints는 주로 기존 timing constraints를 재정의하기 위한 것입니다. 또한 이러한 요구 사항이 없는 paths 에 대한 timing 요구 사항을 지정하는 데 사용할 수도 있습니다.
SDC 구문에서 이러한 목적을 위한 명령은 주로 다음과 같습니다.
- set_false_path: 선택한 paths에 timing 요구 사항을 적용하지 않아야 함을 도구에 알립니다.
- set_max_delay: tsetup시행을 위한 요구 사항을 정의합니다.
- set_min_delay: thold시행을 위한 요구 사항을 정의합니다.
- set_multicycle_path: clock enable signal로 제어되는 logic 에 대한 요구 사항을 완화합니다.
다른 구문을 사용하는 도구는 유사한 명령을 가질 수 있습니다.
이러한 명령의 arguments는 영향을 받는 paths를 정의합니다. 이것은 아래에 설명되어 있습니다.
다른 페이지에서 논의되는 두 가지 관련 주제가 있습니다.
- I/O timing constraints에 대한 별도의 페이지가 있습니다. 따라서 아래 설명은 내부 paths (예: logic fabric의 logic element 에서 logic element 로)와 함께 이러한 명령을 사용하는 것으로 제한됩니다.
- set_multicycle_path는 별도의 다른 페이지 에서 설명합니다.
False Paths
false path 는 이를 요청하는 timing constraint 의 결과로 도구가 무시하는 path 입니다. 즉, 도구는 의도적으로 false path에 timing 요구 사항을 적용하지 않습니다.
unconstrained paths 와 혼동해서는 안 됩니다. 이들은 도구에 timing constraint가 없는 paths 입니다. false paths와 마찬가지로 이 도구는 이러한 paths에서 timing 요구 사항을 적용하지 않지만 그 이유는 다릅니다. 이러한 시행 부족은 선택 사항이 아니지만 도구는 어떤 요구 사항을 적용해야 하는지 알지 못합니다.
FPGA design에는 unconstrained paths가 없어야 합니다. 즉, 도구에서 무시하기를 원하는 paths가 종종 있습니다. 이러한 paths는 timing constraints덕분에 false path 로 표시되어야 합니다. 근거: timing report를 읽을 때 항상 unconstrained paths 의 숫자가 0임을 확인해야 합니다. 이 숫자가 0이 아니면 실수를 찾아야 합니다. unconstrained paths의 0이 아닌 숫자를 받아들이는 데 익숙해지면 timing constraints의 문제를 간과하기가 더 쉽습니다.
따라서 false paths를 선언하는 두 가지 가능한 이유가 있습니다.
- 그렇지 않으면 도구가 path에서 timing 요구 사항을 적용하는 경우 false path는 대신 path를 무시하도록 도구에 지시합니다.
- path와 관련된 timing constraint가 없는 경우. 이 경우 false path 의 목적은 unconstrained paths 의 수를 0으로 유지하는 것입니다.
실질적으로 말하자면, 이러한 시나리오 중 어떤 것이 적용되는지는 중요하지 않습니다. path에 timing 요구 사항이 필요하지 않은 경우 false path로 선언해야 합니다.
clock domain crossings와 관련하여 set_false_path를 사용하는 것은 일반적인 실수입니다. 이 항목은 나중에 자세히 설명합니다. 사실 I/O ports를 제외하고는 set_false_path를 쓰는 것이 맞는 상황은 많지 않다.
set_false_path용 paths 선택
명령이 적용되는 paths를 선택하는 방법에는 여러 가지가 있습니다. 다양한 가능성에도 불구하고 paths 의 선택은 일반적으로 두 개의 arguments로 이루어집니다. -from 및 -to. 예를 들어:
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
이 예에서 set_false_path 명령은 이름이 @source 인 register 에서 시작하고 이름이 @dest인 register 에서 끝나는 path 에 적용됩니다.
get_cells는 logic elements를 나타내는 objects 와 함께 -from 및 -to를 제공합니다. 이전 페이지 에서 논의된 다른 명령도 사용할 수 있습니다. get_pins, get_nets, get_ports 및 get_clocks. 그러나 각 FPGA 도구에는 -from 및 -to와 함께 사용할 수 있는 것에 대한 고유한 규칙이 있습니다.
도구는 objects 에 대한 참조를 자연스럽게 예상하는 대로 해석하지 않을 수 있습니다. 도구는 warning을 발행하지 않고 objects 의 일부 또는 전체를 무시할 수도 있습니다. 실제로 get_* 명령으로 objects를 찾지 못한 경우(예: search pattern의 실수로 인해) timing exception에 path가 포함되지 않은 것입니다. warning없이도 이런 일이 발생할 수 있습니다.
따라서 timing report를 사용하여 timing exceptions가 의도한 대로 적용되는지 확인하는 것이 중요합니다. 이는 올바른 paths가 영향을 받고 timing 계산이 정확한 목적을 충족함을 의미합니다( timing 요구 사항을 적용하지 않음).
paths를 선택하는 데 유용한 또 다른 argument가 있습니다. -through. 이름에서 알 수 있듯이 이 argument는 특정 logic elements를 통과하는 paths를 선택합니다.
모든 기능을 숙지하려면 시간을 내어 공식 문서를 읽어볼 가치가 있습니다. 예를 들어 명령의 효과를 rising clock edges 또는 falling clock edges로만 제한하는 것도 가능합니다. 또 다른 가능성은 명령을 tsetup 만 분석하거나 thold만 분석하도록 제한하는 것입니다.
set_false_path 명령에는 -from, -to 또는 -through 중 하나 이상이 argument (또는 유사한 의미의 다른 argument )로 필요합니다. argument가 2대 이상일 경우 timing exception은 모든 arguments의 조건을 만족하는 paths 에만 적용됩니다.
set_false_path의 위험
false paths 의 문제는 실수하기가 얼마나 쉬운가입니다. 특히 의도한 것보다 더 많은 paths를 포함할 위험이 있습니다. 이 경우 제대로 작동하지 않을 수 있는 sequential elements가 있습니다. 우리는 도구가 tsu 및 thold에 대한 요구 사항을 보장한다고 잘못 생각합니다. 그러나 실제로 도구는 paths 에서 이러한 sequential elements를 false paths로 간주합니다. 따라서 도구는 timing 계산을 귀찮게 하지 않습니다. 이는 도구가 timing constraints가 달성되었다고 말할 때 모든 것이 정상이라는 착각을 일으키기 때문에 위험한 상황입니다. 그러나 실제로는 아무런 보호 없이 timing 위반에 노출된 flip-flops 및 기타 sequential elements가 있습니다.
설상가상으로, path가 false path로 선언되면 일반적으로 이 선언이 가장 높은 우선 순위를 갖습니다. 따라서 path가 실수로 false path로 선언되면 반대가 필요한 다른 timing constraints 보다 우선합니다. 이는 set_false_path가 다른 timing constraint보다 먼저 나타나는 경우에도 일반적으로 해당됩니다. 따라서 set_false_path는 "이전에 내가 요구했거나 나중에 요구할 것과 관계없이 false paths입니다"로 해석됩니다.
set_min_delay 및 set_max_delay
선택한 paths그룹에 대한 timing 요구 사항을 제거하는 false paths에 대해 논의하기 시작했습니다. timing 요구 사항을 취소하는 것이 아니라 지정해야 하는 경우가 많습니다. 이것은 set_min_delay 및 set_max_delay에서 수행됩니다. 예를 들어 다음 Verilog 코드를 고려하십시오.
reg x, y;
always @(posedge clk)
y <= x;
그리고 timing constraints:
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부터 시작하겠습니다. 이 timing exception 에 대한 간략한 설명은 특정 paths 만을 위한 clock period constraint (create_clock)와 유사하다는 것입니다.
clock period constraint가 정의 되면 도구가 필요한 timing 요구 사항을 자동으로 적용합니다. tsetup 요구 사항을 충족하기 위해 관련 paths 의 최대 delays가 제한됩니다. 마찬가지로 최소 delays는 thold를 대신하여 제한됩니다.
위의 예에서 set_max_delay 명령에 나타나는 값은 3입니다. 이는 3 ns와 동일한 clock period 에 대한 create_clock 명령과 동일합니다. 그러나 set_max_delay의 영향력은 paths의 특정 그룹으로 제한됩니다. 그것이 차이점입니다.
set_min_delay에 관해서는 조금 더 복잡하므로 아래에서 자세히 설명합니다.
set_max_delay 명령의 이름이 잘못되었습니다. 이 명령은 path 자체의 최대 delay을 직접 정의하지 않습니다. 영향을 받는 paths 의 delay은 위 예제의 명령에 의해 3 ns 로 제한되지 않습니다 . 3 ns 값은 clock edges사이에 허용되는 시간 차이로 적용됩니다. 그리고 이 시차는 synchronous elements의 clock inputs에서 측정되는 것이 아니라 이러한 clocks의 원점에서 측정됩니다. 이는 PLLs의 delays , clock buffers 및 clock routing이 계산에 포함됨을 의미합니다. clock period constraint와 유사하게 clock delays는 timing analysis에서 고려됩니다.
-from, -to, -through 및 기타 arguments 의 의미는 set_false_path와 동일합니다. 그러나 일반적으로 set_min_delay 및 set_max_delay은 clock period constraint의 조정용입니다. 따라서 일반적으로 path의 양쪽에 sequential elements가 있다고 가정합니다. 따라서 -from 및 -to는 synchronous elements를 나타내야 합니다. 다음과 같은 방법으로 참조할 수 있습니다. synchronous element 자체를 나타내는 cell object , clock object등.
set_min_delay와 관련하여 비슷한 이야기가 있습니다. clock period constraint 의 또 다른 결과는 도구가 thold 요구 사항을 충족해야 한다는 것입니다. 이를 위해 도구는 동일한 clock 사이 또는 related clocks 사이의 모든 paths 에서 최소 delays를 적용합니다. path 에 대한 timing 계산이 create_clock 만의 결과(양쪽에 동일한 clock 포함)인 경우 이는 값이 0인 set_min_delay 와 동일합니다. 이는 동일한 clock edge가 두 sequential elements모두에 도착한다는 생각을 반영합니다. 그러나 이것은 이 clock edge가 이 sequential elements에 동시에 도착한다는 의미는 아닙니다. 오히려 각 sequential element 의 clock edges는 clock의 원점에서 동시에 시작됩니다. 각 clock의 원점에서 sequential element 까지의 delay이 계산에서 고려됩니다( tsetup에 대해 계산이 수행되는 방식과 유사함).
set_min_delay은 두 번째 sequential element에 도착하는 clock edge 의 시간을 조정할 수 있습니다. 예를 들어 위의 명령은 이 clock edge가 두 번째 flip-flop에서 1 ns 에 의해 나중에 도착하도록 합니다. 이로 인해 thold 에 대한 timing 요구 사항을 충족하기가 더 어려워집니다. 아래 timing report 의 예를 참조하십시오.
set_min_delay 및 set_max_delay을 사용하는 두 가지 가능한 이유가 있습니다.
- 도구가 시행하는 timing 요구 사항이 특정 paths그룹에 적합하지 않은 경우. 예를 들어, metastability guard에서 시작하는 paths 에서 timing 요구 사항이 더 엄격해야 하는 경우입니다.
- paths용 관련 timing constraint가 없는 경우. 이 목적으로 set_max_delay을 사용하려면 대신 clock period constraint 또는 multi-cycle paths 가 필요하지 않은지 스스로에게 물어보십시오.
이 두 명령을 사용할 때 항상 timing reports에서 paths 의 timing 계산을 주의 깊게 확인하십시오. 특히 clock path가 계산에서 어떤 역할을 하는지 주목하십시오.
이 페이지 하단에는 set_min_delay 및 set_max_delay의 결과를 보여주는 timing reports 의 예가 있습니다.
delay의 보다 정확한 제어
set_max_delay 및 set_min_delay이 제공하는 제어 수준은 clock period constraint (지금까지 제시된 대로)보다 크게 좋지 않습니다. 그러나 clock path delay이 delay의 정의를 방해하지 않도록 하려면 어떻게 해야 합니까? path의 특정 segment 의 delay을 제어하려면 어떻게 해야 합니까?
일부 FPGA 도구는 이러한 요구에 대한 솔루션을 제공하지 않습니다. 예를 들어, Quartus는 (내가 아는 한) 그런 가능성을 제공하지 않습니다. 반면에 Vivado에는 몇 가지 기능이 있으며 이에 대해 간단히 설명하겠습니다.
이러한 기능 중 하나는 datapath_only 옵션입니다. 때때로 set_max_delay을 사용하여 timing 계산에 clock paths가 포함되지 않도록 하는 것이 좋습니다. 예를 들어 path가 unrelated clocks사이에 있으면 clock paths를 고려하는 것은 의미가 없습니다.
datapath_only를 사용하는 경우 timing은 두 synchronous elements 의 clock path delay이 0인 것처럼 계산됩니다. 따라서 계산은 path의 logic elements 의 delays 로만 구성됩니다. 이러한 delays 의 합계는 set_max_delay 명령에 지정된 숫자보다 작아야 합니다(아래 timing report 의 예 참조).
따라서 set_max_delay이 datapath_only와 함께 사용될 때 그 의미는 이 명령의 이름이 의미하는 것과 더 가깝습니다. 그러나 path는 여전히 synchronous element에서 시작하고 끝나야 합니다.
또한 datapath_only 에는 몇 가지 특징이 있습니다. 사용되는 경우 도구는 관련 paths의 thold 와 관련된 timing 요구 사항을 적용하지 않습니다. 즉, thold 시나리오에만 적용된 false path constraint가 있는 것처럼 도구가 동작합니다. 해당 paths에 대해 set_min_delay 명령을 추가하더라도 이 명령은 무시됩니다. Vivado가 datapath_only의 영향을 받는 paths 에서 최소 delay을 적용하는 것을 거부하는 이유는 명확하지 않습니다.
datapath_only는 어떤 시나리오에서도 argument 에서 set_min_delay 로 사용할 수 없습니다.
오해의 소지가 있는 기능
이 섹션의 제목에서 알 수 있듯이 이러한 가능성은 별로 도움이 되지 않을 가능성이 있습니다. 다음 섹션으로 넘어가셔도 좋습니다.
Vivado는 더 높은 수준의 제어를 허용합니다. path의 특정 segment 의 delay 에 제한을 적용할 수 있습니다. 예를 들어 sequential elements가 아닌 logic elements를 -from 및 -to와 함께 사용하면 어떻게 됩니까? pins 와 nets는 어떻습니까? set_min_delay 와 set_max_delay은 무엇을 합니까?
물론 어떤 FPGA 도구를 사용하느냐에 따라 다릅니다. paths가 요구 사항과 일치하지 않기 때문에 도구는 이러한 constraints를 자동으로 무시할 수 있습니다. 그러나 Vivado는 그러한 constraints를 무시하지 않습니다. 비록 그 결과가 일반적으로 기대하는 것과는 다르지만 말입니다. Vivado는 이 상황을 "path segmentation"로 간주하고 응답으로 critical warning을 발행합니다. 대부분의 경우 이 기능을 사용하는 것은 이로 인해 발생하는 합병증을 감수할 가치가 없습니다. 이에 대한 자세한 내용은 설명서를 참조하십시오.
오해의 소지가 있는 또 다른 기능은 다음과 같습니다. Quartus 에는 set_net_delay라는 명령이 있습니다. design에서 서로 다른 logic elements 간에 최소 및 최대 delay을 정의할 수 있습니다. 그러나 도구가 implementation동안 이러한 timing 요구 사항을 달성하려고 시도하지 않는 것처럼 보입니다. 대신 "report_net_delay"(또는 GUI)로 보고서를 생성할 수 있습니다. 따라서 set_net_delay 로 정의된 조건이 충족되었는지 이 보고서에서 추론할 수 있습니다. 따라서 set_net_delay은 정보를 얻는 데 사용할 수 있지만 timing constraint로는 유용하지 않습니다. 다시 말해서: set_max_delay 및 set_min_delay은 timing constraints와 동일하지만 set_net_delay은 그렇지 않습니다.
요약하면 set_max_delay 및 set_min_delay을 사용하는 일반적인 방법보다 훨씬 나아지지는 않습니다. 유일하게 흥미로운 기능은 Vivado의 datapath_only인 것 같습니다.
timing constraints의 우선 순위
복잡한 timing constraints 의 주요 문제점은 하나 이상의 constraint에 의해 영향을 받는 paths가 종종 있다는 것입니다. 이러한 constraints는 일반적으로 이러한 paths에 대해 모순되는 timing 요구 사항을 가지고 있습니다. 어떤 constraint가 이겼습니까?
각 FPGA 도구에는 이러한 종류의 충돌을 해결하는 방법에 대한 고유한 규칙이 있습니다. 일반적으로 주로 constraint의 유형에 따라 다릅니다. 다른 요인, 특히 paths선택의 특이성도 중요한 역할을 할 수 있습니다.
SDC를 기반으로 하는 timing constraints 의 경우 우선 순위는 constraint유형에 따라 다릅니다. 예를 들어 Vivado는 이 우선 순위에 따라 충돌을 해결합니다. 명령은 가장 높은 우선 순위에서 가장 낮은 순서로 나열됩니다.
- set_clock_groups ( related clocks 및 unrelated clocks그룹)
- set_false_path (false path)
- set_min_delay 및 set_max_delay (minimum delays 및 maximum delays)
- set_multicycle_path (multicycle path)
- create_clock (clock period)
처음 두 명령(set_clock_groups 및 set_false_path)은 false paths를 생성하며 우선 순위가 가장 높습니다. 따라서 path가 이러한 명령의 실수로 영향을 받지 않는지 확인하는 것이 매우 중요합니다. 이러한 실수는 관련 paths에서 timing 요구 사항의 모든 시행을 자동으로 해제합니다.
동일한 명령이 동일한 path에 대해 두 번 이상 사용되면 가장 구체적인 명령이 우선합니다. 예를 들어, 하나의 명령에 "-from" 및 "-to"가 있지만 두 번째 명령에는 "-from"만 있는 경우 첫 번째 명령이 우선합니다. 다른 예시: 한 명령이 logic elements (예: get_cells포함)를 기반으로 paths를 정의하고 두 번째 명령이 clocks ( get_clocks포함)를 기반으로 paths를 정의하는 경우 첫 번째 명령이 우선합니다.
두 명령이 너무 유사하여 우선 순위에 차이가 없는 경우 나타나는 순서로 충돌이 해결됩니다. 마지막 명령이 이깁니다.
유사한 우선 순위 규칙이 Quartus 및 SDC를 기반으로 하는 기타 도구에서 사용됩니다.
그러나 사용하는 도구에 관계없이 timing constraints 사이의 모순을 피하는 것이 가장 좋습니다( create_clock을 무시하는 경우 제외). 복잡한 timing constraints는 파괴적인 버그가 번성할 수 있는 곳입니다.
일부 FPGA 도구를 사용하면 우선 순위 규칙을 우회할 수 있습니다. -reset_path 옵션을 사용하면 현재 명령이 적용되는 모든 paths 에서 이전 timing exceptions 보다 우선합니다. 예를 들어:
set_max_delay -reset_path -from [get_cells source_reg] 2
결론
timing constraints는 짧고 간단하며 간결해야 한다는 말로 이 페이지를 시작했습니다. timing exceptions를 추가하면 timing constraints가 더 길어질 뿐만 아니라 더 복잡해지고 이해하기 어려워집니다. 그래서 필요할 때 timing exceptions를 사용하되, 조심해서 쓰고 깔끔하게 정리하세요.
timing exception 명령의 목적을 반영하고 아이디어를 표현하는 방식으로 timing exception 명령을 작성하십시오. FPGA 도구는 일반적으로 timing constraints생성을 위한 GUI wizards를 제공합니다. 시작점으로 유용할 수 있습니다. 그러나 신중하게 생각하기 전에 wizard 로 만든 timing constraint를 사용하지 마십시오. 이 constraint가 생성되었을 때 맞더라도 logic design이 진화하고 새로운 logic이 추가되어도 계속 충실하게 작동할까요?
timing exception의 영향을 받는 paths 에 대해서는 항상 timing reports를 읽으십시오. path용 timing constraints가 두 개 이상인 경우 이는 훨씬 더 중요합니다. 또한 잘못된 timing 요구 사항이 있을 가능성이 있는 paths 용 특정 timing reports를 만듭니다.
기억하다: timing reports를 만들고 읽는 것은 시간 낭비가 아닙니다. 문서를 아무리 주의 깊게 읽어도(항상 좋은 생각입니다) 항상 실수할 가능성이 있습니다. 특히 false paths는 예상치 못한 곳에서 발생할 수 있습니다.
보너스: timing reports의 예
set_min_delay 와 set_max_delay에 대한 이해를 돕기 위해 Vivado로 만든 몇 가지 timing reports 입니다.
이러한 보고서 뒤에 있는 Verilog 코드는 다음과 같습니다.
always @(posedge clk)
y <= x;
그리고 timing constraints:
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
delay의 값(3 ns)은 두 번째 flip-flop의 clock path 에 대한 시작 시간으로 사용됩니다. 즉, 3 ns를 위한 period constraint가 있었던 것과 똑같습니다.
또한 data path 의 net 에는 거대한 delay이 있습니다. 2.478 ns. 이것은 set_min_delay 명령의 결과입니다. 도구는 thold 요구 사항을 충족하기 위해 이 net 에 긴 delay을 삽입해야 합니다.
말하자면 thold용 timing report 입니다.
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
다시 한 번, delay의 값(1 ns)이 두 번째 flip-flop의 clock path 에 대한 시작 시간으로 사용된다는 점에 유의하십시오. set_min_delay 명령이 없는 경우(예: clock period constraint만 있는 경우) 이것은 0 ns입니다.
data path 에서 net 의 delay은 1.092 ns입니다. 이는 thold 요구 사항을 충족하기에 충분합니다. 이전에는 왜 2.478 ns 였습니까? tsetup 에 대한 최악의 경우 계산이 "Max at Slow Process Corner"에 대해 수행되었기 때문입니다. 따라서 2.478 ns는 관련 net에 대해 가능한 가장 긴 delay이 고 1.092 ns는 가능한 가장 짧은 delay ("Min at Fast Process Corner")입니다. 이에 대한 자세한 내용은 Multi-corner timing analysis에 대한 논의를 참조하십시오.
세 번째 예는 datapath_only를 시연하므로 constraint는 다음과 같습니다.
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
이 timing report 의 구조는 이전과 같지만 clock paths 와 관련된 모든 것이 제거되었습니다.
도구가 긴 delay을 삽입할 이유가 없었기 때문에 net 의 delay은 작습니다. thold 요구 사항은 없습니다.
그리고 timing 요구 사항이 없기 때문에 thold용 timing report를 표시하지 않습니다(최소 delay은 false path로 취급됨).
이것으로 timing exceptions에 대한 일반적인 논의를 마칩니다. 다음 페이지는 clock domain crossing에 필요한 timing exceptions 로 계속됩니다.