01signal.com

timing constraints가 올바른지 확인

中文 | 日本語 | 한국어 | English

이 페이지는 timing에 대한 일련의 페이지 중 마지막 페이지입니다. 이전 페이지에서는 timing 계산에 대한 이론을 설명하고 여러 timing constraints를 작성하는 방법을 보여주고 timing closure의 원리에 대해 논의했습니다.

소개

종종 FPGA 개발 전술은 기능을 추가하고 작동하지 않는 것을 수정하고 반복하는 것입니다. design 에서 잘못되었을 가능성이 있는 부분을 무시하기 쉽지만 눈에 보이는 문제를 일으키지는 않습니다.

timing constraints가 잘못 적용되고 달성되지 않더라도 FPGA design이 완벽하게 잘 작동할 수 있음을 이해하는 것이 중요합니다. timing constraints 의 올바른 사용은 FPGA의 안정적이고 올바른 작동을 보장하는 핵심 구성 요소 중 하나입니다. 그러나 이 주제를 소홀히 한다고 해서 반드시 즉각적인 실패를 의미하는 것은 아닙니다. 오히려 부적절한 timing은 때때로 매우 혼란스러운 오작동을 일으킬 수 있습니다.

이 페이지는 timing constraints에 대한 이 페이지 시리즈 의 많은 제안을 요약하고 반복합니다. 목적은 부적절한 timing의 결과인 문제를 찾는 동안 염두에 두어야 할 몇 가지 주제를 강조하는 것입니다. 누군가는 그것을 위해 때때로 이러한 주제에 대해 점검하는 지혜를 갖고 싶을 수 있지만, 실생활에서 우리 대부분은 마술처럼 보이는 문제를 해결하기 위해 이렇게 합니다.

timing report읽기

모든 FPGA design tools는 timing reports를 방출합니다. 우리가 FPGA design tools를 여는 가장 흔한 이유는 도구가 timing constraints를 달성하지 못할 때입니다. 여기에서 실패한 paths를 찾을 수 있으며, 이에 대해 무엇을 할 수 있는지 알아낼 수 있기를 바랍니다.

그러나 timing reports를 검사해야 하는 덜 중요한 이유는 다음과 같습니다. timing constraints가 의도한 대로 도구에 의해 해석되어 올바르게 적용되는지 확인합니다. 특히 새 timing constraints를 추가한 후에는 이 검사를 가끔 하는 것이 좋습니다.

각 FPGA design tool은 서로 다른 구조와 형식으로 이러한 reports를 생성하기 때문에 각 reports 의 각 부분이 정확히 무엇을 말하는지 연관시키는 것은 불가능합니다. 따라서 이 페이지에서는 모든 도구에 공통적인 원칙을 설명합니다. 자신의 timing reports의 형식과 기능에 관해서는 어쨌든 시간을 내어 배우는 것이 좋습니다.

timing report 점검의 또 다른 가능한 이점은 logic의 잘못된 사용을 드러낼 수 있다는 것입니다. 예를 들어, design 에 잘못 사용된 비동기 logic이 포함되어 있거나 timing constraints를 적용할 수 없는 clocks 에 의존하는 경우 timing report에서 이것이 분명해질 수 있습니다. 이 logic 에 timing constraints를 적용하는 것은 불가능하기 때문에 report 에서는 unconstrained paths로 나타날 수 있습니다.

다른 메모에서, design 에 포함된 IPs는 종종 자체적으로 timing constraints를 제공하며, 도구는 사용자가 제공한 것 위에 추가합니다. 일반적으로 이러한 constraints와 관련된 paths를 확인하는 것은 의미가 없지만 timing report에 상당한 무게를 추가할 수 있습니다.

Unconstrained internal paths

이 논의를 위해 synchronous element는 flip-flop, block RAM, shift register 또는 data input을 샘플링하고/하거나 clock의 rising edge 또는 falling edge 에서 data output을 변경하는 다른 logic elements 입니다.

synchronous element의 data output 에서 다른 synchronous element의 data input 로 이동하는 모든 paths는 시간이 지정되어야 합니다. 즉, timing constraints에 따라야 합니다. 유일한 예외는 timing violation 의 가능성이 unrelated clock domains와 같이 대상의 synchronous element에서 적절하게 처리되는 경우입니다.

다시 말해, design tools가 예측 가능한 방식으로 input signal을 샘플링하는 데 대한 책임을 지지 않는다는 사실을 은폐하기 위한 명시적인 resynchronization 메커니즘이 없는 한, path 에서 synchronous element 까지는 타이밍이 조절되어야 합니다.

때로는 reference clock을 정의하는 단일 행 timing constraint 로 충분하고 FPGA tools가 나머지를 처리합니다. 다른 경우에는 그 이상이 필요합니다. 정말 안 좋은 경우 일부 내부 paths는 실수로 unconstrained 로 남아 있습니다. 이에 대한 몇 가지 가능한 이유가 있습니다.

FPGA design tools는 timing constraint가 적용되지 않은 paths 인 unconstrained paths를 나열하는 timing reports 생성을 지원합니다. 원칙적으로 이 목록은 비어 있어야 합니다. constraints가 필요하지 않은 paths는 timing constraint 파일에서 false paths 로 명시적으로 정의되어야 합니다. 이러한 constraints는 어쨌든 시간이 지정되지 않은 paths 에 대해 기능적으로 아무 것도 변경하지 않지만 timing report 의 unconstrained paths 목록을 비워둘 수 있습니다. 이렇게 하면 의도하지 않게 누락된 paths를 쉽게 찾을 수 있습니다. 또한 이 목록에 있는 paths 의 수가 제한되어 있기 때문에 이 목록에 절대 포함되어서는 안 되는 paths가 숨겨질 수 있습니다. 왜냐하면 그 대신 무해한 paths가 나열되기 때문입니다.

하지만 불행히도 일부 timing reports에서 unconstrained paths 섹션에는 timing constraints에 포함될 이유가 없는 paths 도 포함될 수 있습니다. 예를 들어, clock buffer 의 output 에서 다른 clock resource의 input 로 이어지는 path가 있습니다. 결과적으로 timing report는 unconstrained로 많은 paths를 나열할 수 있지만 이는 완벽하게 괜찮습니다. 이로 인해 timing report에서 상황을 추론하기가 약간 더 어려워지지만 이러한 paths는 일반적으로 flip-flop의 data input 또는 다른 synchronous element로 끝나는 paths 와 별도로 나열되므로 실제로는 문제가 되지 않습니다. 따라서 report를 주의 깊게 읽고 나열된 각 그룹의 paths가 무엇을 의미하는지 주의를 기울이는 것으로 귀결됩니다.

기본적으로 생성되는 timing report는 이 정보를 담기에 충분히 자세하지 않은 경우가 있습니다. 합리적인 FPGA design tool 라면 unconstrained paths를 나열하는 주문형 timing report를 생성할 수 있으며, 각 그룹에 대해 나열할 paths 의 수를 선택할 수 있습니다(관련 목록이 완전히 비어 있어야 하지만 10개는 합리적인 숫자입니다).

clock domains사이Paths

Timing constraints는 소스와 목적지에서 다른 clocks 와 동기되는 내부 paths 에서 사용해야 합니다. clocks가 related clocks 인 경우(또는 더 정확히 말해서 logic이 이를 관련된 것으로 처리하는 경우)입니다. 그렇지 않으면 clocks가 related clocks 인 경우 related clocks가 되어서는 안 됩니다. 이 불필요한 제한으로 인해 고품질 routing resources가 낭비되고 timing constraints를 달성하지 못할 수 있습니다. related clocks 대 unrelated clocks에 대한 이 페이지를 참조하세요.

각 툴셋은 clocks 쌍을 관련된 것으로 간주할지 여부를 자동으로 결정하는 고유한 방식을 가지고 있습니다. timing constraint 파일에서 SDC 구문을 사용하는 툴(예: Vivado 및 Quartus)에는 related clocks 및 unrelated clocks그룹을 정의할 수 있는 set_clock_groups command가 있습니다. 특히 false path timing constraints덕분에 이 문제에 대한 툴을 안내하는 다른 방법도 있습니다.

따라서 문제는 도구가 clocks를 related clocks 로 간주하는지 여부를 확인하는 방법입니다. 안타까운 대답은 도구 세트마다 방법이 다르다는 것입니다. 예를 들어 Vivado에는 Clock Interaction Report가 있으며 각 쌍의 clocks에 대한 상황을 보여주는 색상 다이어그램이 있습니다.

또는 특정 paths 그룹으로 제한된 사용자 지정 timing reports를 사용하여 이 문제를 조사할 수 있습니다. 관련된 clocks 에 따라 paths를 선택할 수 있습니다. 이는 한 clock와 동기화된 logic elements 에서 시작하여 다른 clock에서 끝나는 paths를 선택하여 수행할 수 있습니다. clock domain crossings에 관련된 것으로 알려진 paths 그룹을 구체적으로 살펴보는 것도 유익할 수 있습니다.

어려울 수 있지만 도구가 constraints를 적용하는 clock domain crossings 와 올바른지 여부를 포괄적으로 검토하는 것이 중요합니다. 동시에 logic design이 필요한 곳에 resynchronization logic이 있는지 검토할 수 있는 기회입니다. 각 signal와 함께 사용되는 clock 에 대한 혼동으로 인해 안전하지 않은 clock domain crossing 로 끝나기 쉽습니다.

각 clock의 특성을 염두에 두고 이 검토를 하는 것이 중요합니다. 예를 들어, 다른 oscillators 의 두 clocks가 동일한 의도된 frequency를 가지고 있고 따라서 timing constraints 파일에서 유사한 정의를 가지고 있다면, 도구는 실수로 그것들을 관련이 있다고 간주하고, 한 clock 에서 다른 clock 로 이동하는 paths 에서 timing을 계산할 수 있습니다. 그러한 paths 에 constraints를 적용하는 것은 의미가 없습니다. 왜냐하면 두 clocks사이의 phase 관계에 대한 어떠한 보장도 없기 때문입니다. 불필요한 timing constraints 자체로 인해 도구가 timing을 달성하기가 더 어려워질 뿐이며, 이는 무해할 수 있습니다. 진짜 문제는 timing report가 clocks가 실제로 related clocks라고 생각하도록 오도할 수 있다는 것입니다. 따라서 constraints 와 timing reports만 놓고 보면 그 사이에 있는 paths는 안전해 보일 수 있습니다(즉, timing violations에 대한 보호가 필요하지 않음). 하지만 사실은 그렇지 않습니다. 두 개의 clocks는 거의 동일한 frequency를 제외하고는 공통점이 없습니다. 이런 종류의 실수를 피하는 유일한 방법은 각 clock이 어떻게 생성되는지 이해하는 것입니다.

Unconstrained external paths

Timing constraints는 항상 I/O pins 에서 시작하거나 I/O pins에서 끝나는 paths 에 적용해야 합니다. 이 작업을 수행하는 방법을 설명하는 별도 페이지가 있습니다. 유일한 예외는 특수 인터페이스가 있는 clock input pins 및 pins , 예를 들어 FPGA의 실리콘에 있는 hardware processor 에 직접 연결된 gigabit transceivers, pins 입니다. 인터페이스가 매우 느린 경우 timing constraints가 정의되지 않아도 용서할 수 있습니다. 예를 들어 LEDs, pushbuttons 및 I2C 와이어가 있습니다. 그러나 이러한 pins에 false path constraints를 할당하는 것이 훨씬 더 좋습니다. 이렇게 하면 timing report에서 unconstrained I/O pins 목록이 비어 있게 됩니다.

external paths에 timing constraints를 적용하는 것이 무의미해 보일 때가 많습니다. 예를 들어, 모두 동일한 clock와 동기화된 여러 output pins가 있고 모두 동시에 토글된다는 사실에 의해 올바른 timing이 보장되는 경우. 이 동시 토글링을 구현하는 일반적인 방법은 IOB register를 사용하는 것입니다. 이 flip-flop은 가능한 최고의 clock-to-output 와 output pins사이에서 매우 낮은 skew를 제공합니다.

그러나 이것은 output pins 의 timing constraints가 중요한 경우에 대한 좋은 예입니다. timing constraints를 타이트하게 유지함으로써 이러한 pins 사이의 낮은 skew가 보장됩니다. IOB register를 사용하는 경우 긴밀한 timing constraints는 도구가 이 flip-flop을 사용하도록 강제하거나 도구가 그렇게 하지 못하는 경우 눈에 띄지 않게 하는 방법이 될 수 있습니다. 도구가 flip-flop을 원하는 대로 배치하지 않으면 timing이 실패합니다.

비슷한 이유로 input pins 에 타이트한 timing constraints 도 적용해야 합니다.

여러 pins사이의 낮은 skew를 위해 timing constraints를 사용하는 경우 보고된 slack이 거의 0이 될 때까지 I/O pins를 제한하는 것이 아니라 더 엄격한 timing을 요구하면 constraint를 달성하지 못하는지 확인하는 것이 중요합니다. 이는 I/O signal path 에 옵션 delay lines가 포함될 수 있기 때문에 도구가 반직관적인 방식으로 사용할 수 있습니다. 예를 들어, Intel FPGA의 Quartus는 timing budget 잉여가 있는 경우 input path 에 일부 delay을 추가할 수 있습니다 . 이를 수행하기 위한 도구의 선택은 바람직하지도 예상되지도 않을 수 있습니다.

잘못된 false paths 및 그렇지 않은 경우 완화된 timing

때때로 timing constraints가 적용되지만 너무 관대합니다. 관련 paths는 잘못된 요구 사항으로만 시간이 지정되므로 감지하기가 훨씬 더 어렵습니다.

이러한 종류의 사고에는 여러 가지 가능한 이유가 있습니다.

이런 종류의 문제를 찾아내는 간단한 방법은 없습니다. timing report를 위에서 아래로 주의 깊게 읽는 것은 확실히 좋은 생각이지만 보고서에 각 그룹에 대해 10개의 paths가 표시되더라도 문제가 있는 paths가 해당 그룹에 나타날 것이라는 보장은 없습니다. 또는 그 문제에 대해 표시된 paths의 수 중에서.

이 문제를 해결하는 또 다른 방법은 timing constraints를 작성된 대로 검토하는 것입니다. SDC constraints는 Tcl로 작성되었으므로 constraints 파일에서 logic elements ("from" 및 "to" 포함)를 Tcl expressions로 선택하는 표현식을 평가하고 엔드포인트 목록을 읽을 수 있습니다.

예를 들어 이 줄이 Vivado .xdc 파일에 나타나는 경우:

set_false_path -to [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ]

implemented design을 열고 false paths가 적용되는 대상을 나열할 수 있습니다.

puts [join [ get_pins -hier -filter {name =~ */pclk_i1_bufgctrl.pclk_i1/S*} ] "\n" ]

Tcl commands ("puts" 및 "join")는 각 요소가 별도의 행에 나열되도록 하여 출력(매우 길 수 있음)을 쉽게 읽을 수 있습니다.

constraints 에 대한 이러한 종류의 검토는 중요하지만 실제 두뇌 작업이 필요하기 때문에 마찬가지로 어렵습니다.

요약

도구가 다양한 paths 에서 올바른 timing 제한을 적용하는지 확인하는 것은 까다로운 작업입니다. 그것은 timing constraint 문이 정확히 무엇을 의미하는지 아는 것과 timing reports를 확인하는 방법을 아는 것의 조합으로 실수를 발견할 가능성을 높입니다.

그러나 무엇보다 design이 잘 작동하는 것처럼 보일 때 design을 확인하고 다시 확인하는 자제력을 갖는 것입니다.

이 페이지는 영어에서 자동으로 번역됩니다. 불분명한 사항이 있으면 원본 페이지를 참조하십시오.
Copyright © 2021-2024. All rights reserved. (b4b9813f)