이 페이지는 timing에 대한 일련의 페이지 에 속합니다. 이전 페이지에서는 timing 계산의 이론을 설명하고, clock period constraint를 논의하고, timing closure의 원리를 보여주고, 몇 가지 중요한 Tcl commands를 소개했습니다. 이 페이지에서는 특정 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 구문의 commands는 주로 다음과 같습니다.
- set_false_path: 선택한 paths에 timing 요구 사항을 적용하지 않아야 함을 도구에 알립니다.
- set_max_delay: tsetup시행을 위한 요구 사항을 정의합니다.
- set_min_delay: thold시행을 위한 요구 사항을 정의합니다.
- set_multicycle_path: clock enable signal로 제어되는 logic 에 대한 요구 사항을 완화합니다.
다른 구문을 사용하는 도구는 유사한 commands를 가질 가능성이 높습니다.
이 commands의 arguments는 (다른 것들 중에서) 어떤 paths가 영향을 받아야 하는지 정의합니다. 이는 아래에서 설명합니다.
다른 페이지에서 논의되는 두 가지 관련 주제가 있습니다.
- I/O timing constraints에 대한 별도 페이지가 있습니다. 따라서 아래 논의는 내부 paths (즉, logic fabric에서 sequential logic element를 거쳐 paths 로 이동하는 paths )와 함께 이러한 commands를 사용하는 것으로 제한됩니다.
- 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 requirements가 필요하지 않으면 false path로 선언해야 합니다.
clock domain crossings와 관련하여 set_false_path를 사용하는 것은 일반적인 실수입니다. 이 항목은 나중에 자세히 설명합니다. 사실 I/O ports를 제외하고는 set_false_path를 쓰는 것이 맞는 상황은 많지 않다.
set_false_path용 paths 선택
command가 적용되는 paths를 선택하는 방법은 여러 가지가 있습니다. 가능성의 폭이 넓음에도 불구하고 paths 선택은 일반적으로 두 개의 arguments로 이루어집니다. -from 및 -to. 예를 들어:
set_false_path -from [get_cells source_reg] -to [get_cells dest_reg]
이 예에서 set_false_path command는 @source register 에서 시작하여 @dest register에서 끝나는 path 에 적용됩니다.
get_cells는 logic elements를 나타내는 objects 와 함께 -from 및 -to를 제공합니다. 이전 페이지 에서 논의한 다른 commands 도 사용할 수 있습니다. get_pins, get_nets, get_ports 및 get_clocks. 그러나 각 FPGA tool 에는 -from 및 -to와 함께 사용하기에 허용되는 것에 대한 자체 규칙이 있습니다.
도구가 objects 에 대한 참조를 자연스럽게 예상하는 대로 해석하지 못할 수 있다는 점에 유의하십시오. 도구는 경고를 발행하지 않고 일부 또는 모든 objects를 무시할 수도 있습니다. 사실, get_* command 에서 objects를 찾지 못하면(예: search pattern의 실수로 인해) timing exception에 path가 포함되지 않습니다. 이조차도 경고 없이 발생할 수 있습니다.
따라서 timing exceptions가 의도한 대로 적용되는지 확인하기 위해 timing report를 사용하는 것이 중요합니다. 즉, 올바른 paths가 영향을 받고 timing analysis가 정확한 목적을 충족한다는 것을 의미합니다( timing requirements의 시행 없음).
paths를 선택하는 데 유용한 또 다른 argument가 있습니다. -through. 이름에서 알 수 있듯이 이 argument는 특정 logic elements를 통과하는 paths를 선택합니다.
모든 기능을 파악하기 위해 공식 문서를 읽을 시간을 갖는 것이 좋습니다. 예를 들어, command 의 효과를 rising clock edges 또는 falling clock edges로만 제한하는 것도 가능합니다. 또 다른 가능성은 command를 tsetup 또는 thold만 분석하도록 제한하는 것입니다.
set_false_path command는 argument (또는 유사한 의미를 가진 다른 argument )로서 -from, -to 또는 -through 중 적어도 하나를 요구합니다. argument가 두 개 이상인 경우 timing exception은 모든 arguments의 조건을 충족하는 paths 에만 적용됩니다.
set_false_path의 위험
false paths 의 문제는 실수하기가 얼마나 쉬운가입니다. 특히 의도한 것보다 더 많은 paths를 포함할 위험이 있습니다. 이 경우 제대로 작동하지 않을 수 있는 sequential elements가 있습니다. 우리는 실수로 도구가 tsu 및 thold에 대한 요구 사항을 보장할 것이라고 기대합니다. 하지만 실제로 도구는 paths 에서 이 sequential elements가 false paths인 것처럼 작동합니다. 따라서 도구는 timing analysis를 만들지 않습니다. 이는 도구가 timing constraints가 달성되었다고 말할 때 모든 것이 괜찮다는 환상을 만들어내기 때문에 위험한 상황입니다. 하지만 실제로는 보호 없이 timing violations 에 노출된 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 requirements를 제거하는 false paths에 대해 논의하면서 시작했습니다. 종종 timing requirements를 취소하기보다는 지정해야 할 필요가 있습니다. 이는 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
그럼 이 commands의 의미는 무엇일까요? set_max_delay부터 시작해 봅시다. 이 timing exception 에 대한 간단한 설명은 특정 paths 에만 사용하도록 의도된 clock period constraint (create_clock)와 비슷하다는 것입니다.
clock period constraint가 정의되면 도구가 자동으로 필요한 timing requirements를 적용한다는 점을 기억하세요 . tsetup 요구 사항을 충족하기 위해 관련 paths 의 최대 delays가 제한됩니다. 마찬가지로 최소 delays는 thold를 대신하여 제한됩니다.
위의 예에서 set_max_delay command 에 나타나는 값은 3입니다. 이는 clock period 에 대한 create_clock command 와 동일하며 3 ns와 같습니다. 하지만 set_max_delay의 영향은 특정 paths그룹에 국한됩니다. 그게 차이입니다.
set_min_delay에 관해서는 조금 더 복잡하므로 아래에서 자세히 설명합니다.
set_max_delay command 의 이름은 오해의 소지가 있습니다. 이 command는 path 자체의 최대 delay을 직접 정의하지 않습니다. 영향을 받는 paths 의 delay은 위의 예에서 command 에 의해 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 의 시간을 조정할 수 있습니다. 예를 들어, 위의 command는 이 clock edge가 두 번째 flip-flop에 1 ns 만큼 늦게 도착하게 합니다. 이렇게 되면 thold 에 대한 timing 요구 사항을 충족하기가 더 어려워집니다. 아래 timing report 의 예를 참조하십시오.
set_min_delay 및 set_max_delay을 사용하는 두 가지 가능한 이유가 있습니다.
- 도구가 그렇지 않으면 시행할 timing 요구 사항이 특정 paths그룹에 부적절할 때. 예를 들어, timing requirement가 metastability guard에서 시작하는 paths 에 더 엄격해야 할 때.
- paths용 관련 timing constraint가 없는 경우. 이 목적으로 set_max_delay을 사용하려면 대신 clock period constraint 또는 multi-cycle paths 가 필요하지 않은지 스스로에게 물어보십시오.
이 두 개의 commands를 사용할 때는 항상 timing reports에서 paths 의 timing analysis를 주의 깊게 확인하세요. 특히 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 tools는 이러한 요구 사항에 대한 솔루션을 제공하지 않습니다. 예를 들어, 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 command 에 제공된 숫자보다 작아야 합니다(아래 timing report 의 예 참조).
따라서 set_max_delay을 datapath_only와 함께 사용하면 그 의미는 이 command's 이름이 암시하는 것과 더 가깝습니다. 그러나 path는 여전히 synchronous element에서 시작하고 끝나야 합니다.
또한 datapath_only 에는 몇 가지 특징이 있습니다. 사용하는 경우 도구는 관련 paths의 thold 에 대한 timing requirement를 적용하지 않습니다. 즉, 도구는 thold 시나리오에만 적용된 false path constraint가 있는 것처럼 동작합니다. 관련 paths에 대해 set_min_delay command가 추가되더라도 이 command는 무시됩니다. 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 tool을 사용하느냐에 따라 달라집니다. 도구는 이러한 constraints를 조용히 무시할 수 있습니다. 요구 사항에 맞는 paths가 없기 때문입니다. 하지만 Vivado는 이러한 constraints를 무시하지 않지만, 그 결과는 자연스럽게 예상하는 바와 다릅니다. Vivado는 이 상황을 "path segmentation"로 간주하고 응답으로 critical warning을 발행합니다. 대부분의 경우 이 기능을 사용하는 것은 이로 인해 발생하는 합병증을 감수할 가치가 없습니다. 이에 대한 자세한 내용은 설명서를 참조하십시오.
오해의 소지가 있는 또 다른 기능은 다음과 같습니다. Quartus 에는 set_net_delay라는 command가 있습니다. 이를 통해 design에서 다른 logic elements 간에 최소 및 최대 delay을 정의할 수 있습니다. 그러나 이 도구는 implementation에서 이러한 timing requirements를 달성하려고 시도하지 않는 것 같습니다. 대신 "report_net_delay"(또는 GUI)를 사용하여 report를 생성할 수 있습니다. 따라서 set_net_delay 로 정의된 조건이 충족되었는지 이 report 에서 추론할 수 있습니다. 따라서 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 requirements를 갖습니다. 그렇다면 어느 constraint가 이길까요?
각 FPGA tool 에는 이런 종류의 갈등을 해결하는 방법에 대한 자체 규칙이 있습니다. 일반적으로 주로 constraint의 유형에 따라 달라집니다. 다른 요소도 역할을 할 수 있으며, 특히 paths선택의 특이성이 있습니다.
SDC를 기반으로 하는 timing constraints 의 경우 우선순위는 constraint의 유형에 따라 달라집니다. 예를 들어, Vivado는 이 우선순위 순서에 따라 충돌을 해결합니다. commands는 가장 높은 우선순위에서 가장 낮은 우선순위로 나열됩니다.
- 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)
처음 두 개의 commands (set_clock_groups 와 set_false_path)가 false paths를 생성하고 가장 높은 우선순위를 가지고 있다는 점에 유의하세요. 따라서 이러한 commands로 인해 실수로 path가 영향을 받지 않는지 확인하는 것이 매우 중요합니다. 이러한 실수는 관련 paths에서 timing 요구 사항의 모든 시행을 자동으로 해제합니다.
같은 command가 같은 path에 두 번 이상 사용될 때, 가장 구체적인 command가 승리합니다. 예를 들어, 한 command 에 "-from"와 "-to"가 있지만 두 번째 command 에 "-from"만 있는 경우, 첫 번째 command가 승리합니다. 또 다른 예: 하나의 command가 logic elements (예: get_cells)를 기반으로 paths를 정의하고, 두 번째 command가 clocks ( get_clocks)를 기반으로 paths를 정의하는 경우, 첫 번째 command가 승리합니다.
두 개의 commands가 너무 유사하여 우선 순위에 차이가 없는 경우, 나타나는 순서에 따라 충돌이 해결됩니다. 마지막 command가 승리했습니다.
유사한 우선 순위 규칙이 Quartus 및 SDC를 기반으로 하는 기타 도구에서 사용됩니다.
그러나 사용하는 도구에 관계없이 timing constraints 사이의 모순을 피하는 것이 가장 좋습니다( create_clock을 무시하는 경우 제외). 복잡한 timing constraints는 파괴적인 버그가 번성할 수 있는 곳입니다.
일부 FPGA tools에서는 우선 순위 규칙을 해결할 수 있습니다. -reset_path attribute을 사용하면 이 attribute을 사용하는 command가 적용되는 모든 paths 에서 이전 timing exceptions를 무효화합니다. 예를 들어:
set_max_delay -reset_path -from [get_cells source_reg] 2
결론
timing constraints는 짧고 간단하며 간결해야 한다는 말로 이 페이지를 시작했습니다. timing exceptions를 추가하면 timing constraints가 더 길어질 뿐만 아니라 더 복잡해지고 이해하기 어려워집니다. 그래서 필요할 때 timing exceptions를 사용하되, 조심해서 쓰고 깔끔하게 정리하세요.
timing exception commands를 그들의 목적을 반영하고 그 뒤에 있는 아이디어를 표현하는 방식으로 작성해 보세요. FPGA tools는 일반적으로 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 입니다.
위에서 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을 위한 report :
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 command의 결과입니다: 도구는 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 command가 없는 경우(즉, 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 command뒤에 쓰여졌더라도요).
tsetup 용 report는 이제 다음과 같습니다.
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 요구 사항은 없습니다.
그리고 thold에 대한 timing report를 보여주지 않는데, timing requirement는 존재하지 않기 때문입니다(최소한의 delay은 false path로 처리됩니다).
이것으로 timing exceptions에 대한 일반적인 논의를 마칩니다. 다음 페이지는 clock domain crossing에 필요한 timing exceptions 로 계속됩니다.