Clock domains, related clocks 및 unrelated clocks

이 페이지는 clock domains에 대한 시리즈 의 세 페이지 중 첫 번째 페이지입니다.

소개

아주 사소한 FPGA designs를 제외하고 하나 이상의 clock이 synchronous elements (flip-flops, block RAMs, shift registers 등)와 함께 사용됩니다. logic design 내부의 대부분의 기능 유닛은 하나의 clock을 기반으로 하지만 대부분의 경우 여러 clocks 에 대한 주제는 특별한 주의가 필요하지 않습니다. 하나의 clock을 기반으로 하는 logic이 다른 clock에 종속된 logic 와 연결되면 상황이 더 어려워집니다. 이 일련의 페이지에서는 design에서 여러 clocks 로 작업하는 방법에 대해 설명합니다.

다른 clocks에 의존하는 logic을 연결할 때 가장 먼저 대답해야 할 가장 중요한 질문은 resynchronization logic이 필요한지 여부입니다. 이는 두 개의 clocks가 related clocks 인지 여부를 묻는 것과 같습니다. 이 페이지에서는 이 질문과 답변 방법, 기타 관련 주제에 대해 설명합니다. 아래의 많은 논의는 timing constraints 및 logic의 특정 요소에 적용할 가능성과 관련이 있습니다. 그런 이유로 timing에 대한 간략한 요약으로 시작하겠습니다.

이 페이지 시리즈의 논의는 positive edge triggered flip-flops, 즉 clock inputs의 rising edges 에 반응하는 flip-flops 로 제한됩니다. 다른 synchronous elements 도 물론 존재합니다. 즉, clock을 기반으로 신호를 샘플링하고 생성하는 logic elements : Shift registers, block RAMs 및 기타 많은 기능 요소. 이러한 요소 중 일부는 clock의 falling edge 또는 둘 다에서 반응할 수 있습니다. 여기에서 논의할 때 나는 단순함을 위해 이 모든 것을 무시합니다.

또한 synchronous element X의 clock input이 clock Y에 연결되어 있음을 표현하기 위해 "X is synchronous with Y"라는 표현을 사용하겠습니다. 따라서 이 synchronous element는 이 clock로 input (또는 inputs)를 샘플링하고 outputs를 업데이트합니다.

timing의 기본 사항에 대해 간략히 설명합니다.

이것은 timing의 이론에 대한 간략한 요약입니다. 더 자세한 설명은 별도의 페이지 에서 볼 수 있습니다.

LUT를 통해 하나의 flip-flop 에서 다른 signal path 로의 signal path를 보여주는 다음 그림을 고려하십시오.

이 도면의 LUT (Look-Up Table)는 combinatorial logic의 모든 그룹을 나타냅니다. I1, I2, I3 또는 I4 의 모든 변경은 propagation delay의 양으로 output O의 즉각적인 변경을 유발합니다.

따라서 signal path는 다음과 같이 진행됩니다. @foo라고 표시된 왼쪽 flip-flop의 Q output은 input clock, @clk1의 rising edge 이후에 변경됩니다. 이 output은 I1에 연결되어 있기 때문에 LUT의 output O는 잠시 후 변경될 수 있습니다. 이것은 오른쪽 flip-flop의 data input, 즉 D에 들어갑니다. @clk2의 rising edge 이후, flip-flop은 D를 Q ( @bar레이블)로 복사합니다.

하지만 그렇게 간단하지 않습니다. 모든 flip-flops 에는 다음과 같은 타이밍 요구 사항이 있습니다. data input (D)는 @clk2의 rising edge이전에 안정적인 t_su ( setup time)여야 하고, 이 edge이후에도 안정적인 t_hold ( hold time)를 유지해야 합니다.

FPGA 에 있는 대부분의 signal paths는 단일 clock와 관련되어 있으므로 @clk1 와 @clk2는 정확히 동일한 clock 신호입니다( clock skew무시). 이러한 paths의 경우 이 두 가지 타이밍 요구 사항을 보장할 수 있는지 여부를 계산할 수 있습니다.

예를 들어 위의 그림과 t_su의 타이밍 요구 사항을 살펴보겠습니다. 아이디어는 @clk1 의 rising edge 에서 오른쪽 flip-flop 의 D input이 업데이트되고 안정적일 때까지 걸리는 시간을 찾는 것입니다. 이것은 이 path의 모든 지연을 합한 것입니다. @clk1 의 rising edge 부터 @foo가 업데이트될 때까지("clock to output") 지연으로 시작하여 오른쪽 flip-flop 의 D input 까지 모든 지연이 계속됩니다. 여기에는 LUT 의 지연과 logic elements (routing delays) 간의 배선 지연이 포함됩니다.

@clk1 와 @clk2는 동일한 clock이 므로 두 flip-flops 의 다음 rising edge가 언제인지 알 수 있습니다. 하나의 clock period 이후입니다(예: 100 MHz clock의 경우 10 ns ). 따라서 path의 전체 지연은 clock period보다 낮아야 하며 마진은 t_su입니다. 이것이 보장될 수 있다면 t_su가 요구하는 사항을 보장합니다. 오른쪽의 flip-flop 의 D input은 @clk2의 rising edge 보다 시간 여유(t_su)로 안정적입니다. 숫자에 대한 예는 timing 이론에 대한 페이지를 참조하십시오.

t_hold에 대해서도 유사한 계산을 수행할 수 있습니다. t_su와 달리 오른쪽 flip-flop 의 D input은 @clk2의 rising edge 이후 일정 시간(t_hold) 동안 안정적으로 유지 되어야 합니다. 따라서 clock period는 관련이 없으며 고려되지 않습니다( @clk1 와 @clk2가 동일한 경우). 중요한 것은 다음 clock cycle이 아니라 동일한 clock cycle에서 무슨 일이 일어나는가입니다.

이러한 종류의 계산은 @clk1 의 rising edge 와 @clk2의 rising edge 사이의 시간 차이를 알고 있기 때문에 가능합니다. 특히, @clk1 와 @clk2가 같은 clock라면, t_su를 계산하는데 사용되는 이 시간차는 해당 clock의 clock period 입니다. 그러나 이 두 clocks 의 시차를 알 수 없는 경우 t_su 와 t_hold모두 보장할 수 없습니다.

t_su 또는 t_hold 의 요구 사항은 모든 flip-flop에 필요합니다. 여기에는 FPGA의 모든 flip-flops는 물론 외부 devices 의 flip-flops 도 포함됩니다(즉, FPGA 의 output pin 에서 clock로 신호를 샘플링하는 외부 device 까지). 따라서 시스템의 각 flip-flop 에 대해 이 두 가지 요구 사항이 충족되는지 확인해야 합니다. 이를 보장할 수 없는 flip-flops 의 경우 이것에도 불구하고 안정적인 작동을 보장하는 메커니즘(예: resynchronization logic)을 보장해야 합니다. 이것은 간단히 말해서 crossing clock domains 의 주제입니다.

다시: timing은 언제 보증됩니까?

이전 섹션에서 길을 잃은 경우를 대비하여 다음이 주요 사항입니다.

FPGA design 에는 항상 timing constraints가 포함되어 있어 design 도구에 clocks의 주파수에 대해 알려줍니다. 이 정보를 기반으로 도구는 두 가지 타이밍 요구 사항(t_su 및 t_hold)를 충족합니다. 또는 도구가 이러한 요구 사항을 달성하지 못하면 이 실패를 보고합니다.

위에서 언급했듯이 t_su를 보장할 수 있습니다. path 의 시작 부분에 있는 clock 의 rising edges 와 path의 끝 부분에 있는 clock 사이의 시차를 알고 있는 경우에만 t_hold . 이것은 logic design 의 대부분이 동일한 clock와 동기화된 다른 registers 에 의존하는 registers 로 구성되기 때문에 대부분의 경우에 해당합니다.

그러나 두 개의 다른 clocks를 사용한다면 어떻게 될까요? 하나의 clock이 path의 시작 부분에서 flip-flop 에 연결되고 다른 clock이 path의 끝에서 flip-flop 에 연결되면? 즉, @clk1이 @clk2와 같지 않다면 어떻게 될까요? 여전히 타이밍 계산을 수행하고 타이밍 요구 사항을 보장할 수 있습니까? 글쎄, 그것은 달려있다. 이것이 이 페이지의 나머지 부분입니다.

Clock domains 및 clock domain crossing

clock domain은 특정 clock signal와 동기화되는 모든 synchronous elements (즉, flip-flops 등)로 구성됩니다.

다음과 같은 간단한 Verilog 코드 스니펫을 고려하십시오.

reg foo, bar;

always @(posedge clk1)
  foo <= !foo;

always @(posedge clk2)
  bar <= foo;

이 예에서 @foo는 @clk1와 동기화되고 @bar는 @clk2와 동기화됩니다. 따라서 분명히 @foo 와 @bar는 서로 다른 clock domains (각각 @clk1 와 @clk2)에 속합니다.

@foo에 대해 걱정할 것이 없습니다. 그것은 자신에게만 의존합니다. 그러나 @bar는 @clk2 와 동기화되며 @clk1와 동기화되는 @foo에 종속됩니다. @bar를 register로 사용할 수 있습니까? @bar가 항상 적법한 타이밍에 따라 @foo 의 값을 획득하여 동작이 알려지고 반복 가능하다고 가정할 수 있습니까?

이 질문에 답하기 전에 여기서 방금 일어난 일의 이름을 지정해 보겠습니다. clock domain crossing입니다. @foo 및 @bar는 서로 다른 clocks와 동기화되는 두 개의 flip-flops 로 구현됩니다. 따라서 @foo 에서 @bar 로의 path는 한 clock domain 에서 다른 clock domain 로 이동합니다.

보다 일반적으로 clock domain crossing은 하나의 clock domain 에 속하는 synchronous element 의 output이 다른 clock domain에 속하는 synchronous element 의 input 로 끝나는 경우를 나타냅니다. 이 두 synchronous elements사이에는 종종 combinatorial logic이 있습니다.

따라서 @bar가 다음과 같이 정의되더라도

always @(posedge clk2)
  bar <= !foo || !bar;

여기에 여전히 clock domain crossing이 있습니다. 이 경우 위 그림과 같이 @foo에서 시작하여 logic function을 구현하는 LUT를 거쳐 @bar에서 끝났을 것입니다.

Related clocks 대 unrelated clocks

related clocks 라는 용어는 rising edges 와 falling edges 사이의 예측 가능한 시간 차이를 보장하는 방식으로 동일한 reference clock 에서 파생된 clocks를 나타냅니다(알려진 부정확성과 jitter제외).

"synchronous clocks"라는 용어는 종종 "related clocks" 대신 사용됩니다. 마찬가지로 "unrelated clocks"대신 "asynchronous clocks"를 많이 사용한다.

related clock 의 일반적인 예는 단일 FPGA PLL을 사용하여 주파수 간의 알려진 관계를 사용하여 여러 clocks를 생성하는 경우입니다. 이 시나리오에서 FPGA 도구는 일반적으로 가능한 한 clock edges가 정렬되도록 clock buffers를 정렬합니다.

예를 들어, reference clock 에 2와 3을 곱하면:

이 예에서 x1 clk, x2 clk 및 x3 clk은 related clocks입니다. 이러한 clocks 의 각 쌍 사이의 timing은 예측 가능하기 때문입니다.

일반적인 경우 reference clock은 다음과 같은 다른 clocks와 관련하여 unrelated clock 입니다. 다른 clocks 와 관련하여 reference clock의 edges 사이의 timing은 온도 및 기타 요인에 따라 변경될 수 있습니다. 그러나 PLL이 reference clock 와 PLL의 outputs사이에 예측 가능한 정렬을 보장하도록 구성된 경우 reference clock 도 related clock입니다.

clocks 사이의 시간 관계에 대한 지식은 clock domains사이를 이동하는 paths 에 대한 타이밍 계산을 허용합니다. 예를 들어, x1 clk 의 domains 와 x2 clk 사이의 path 타이밍은 x2 clk 와 x2 clk 사이의 path 와 동일한 요구 사항으로 계산됩니다. 이는 이 두 clocks 사이의 최단 시간차가 x2 clk의 두 rising edges 사이의 시간과 같기 때문입니다.

마찬가지로 x2 clk 와 x3 clk 사이의 path 도 계산할 수 있지만 가장 짧은 시간 차이는 x1 clk의 period의 6분의 1에 불과합니다. 따라서 최악의 타이밍 요구 사항은 상상의 x6 clk에 해당합니다. 그 이유는 x2 clk 의 두 번째 rising edge 와 x3 clk의 세 번째 rising edge 사이의 시간 차이 때문입니다.

timing 계산 방법에 대한 자세한 내용은 이 페이지 를 참조하십시오.

따라서 이 예의 요점은 일반적으로 사실인 것을 말하는 것입니다. related clocks를 사용하면 동일한 clock domain내의 paths 와 마찬가지로 이러한 clocks사이의 paths 에 timing constraints를 적용하여 타이밍을 보장할 수 있습니다 . 이것은 FPGA 도구가 의도적으로 clock edges가 정렬되도록 할 때 가능합니다. 예에서 볼 수 있듯이 타이밍 요구 사항은 clocks 각각에 대한 것보다 종종 더 엄격하고 때로는 훨씬 더 엄격합니다.

그러나 두 개의 clocks가 동일한 reference clock 에서 파생되었다는 사실이 반드시 related clocks가 되는 것은 아닙니다. 특히, 이러한 clocks 사이의 skew가 제어되지 않거나 알 수 없는 경우( design 도구가 명시적으로 동일한 지연으로 clock distribution 리소스를 사용하지 않는 경우) unrelated clocks로 처리해야 합니다.

그리고 clk x1 도 reference clock와 정확히 같은 주파수를 가지고 있더라도 반드시 해당 reference clock와 관련이 있는 것은 아닙니다. 이러한 clocks가 의도적으로 상호 정렬되지 않는 한 해당 phase relation은 알 수 없습니다.

phase에 대한 이 주제 때문에 위의 clock domain 에 대한 정의에 "특정 clock"가 아니라 "특정 clock signal"라고 썼습니다. "특정 clock"는 예를 들어 FPGA의 두 개의 다른 input pins 에 연결된 보드의 동일한 clock을 의미할 수 있습니다. 반면에 "특정 clock signal"는 Verilog 또는 design의 netlist 에서 clock 신호를 나타내는 wire를 나타냅니다. 위 예의 @clk1 및 @clk2 와 같습니다. instantiations 에서 ports를 연결하거나 일반 "assign" 문을 사용하여 Verilog design 에 배포됩니다.

clock이 Verilog 에서 정확히 동일한 신호라는 사실은 도구가 하드웨어에서 낮은 clock skew를 보장하는 리소스를 사용하도록 할 것임을 의미합니다. 또한 도구가 clocks를 related clocks 로 간주하는지 여부에 대한 의미도 있습니다(아래에서 자세히 설명).

Related clocks, timing constraints 및 resynchronization logic

원래 질문으로 돌아가 보겠습니다. 위의 예에서 @bar를 다른 register처럼 사용할 수 있습니까? 또는 더 일반적으로 말하면 flip-flop이 한 clock domain 에서 다른 clock domain 로 이동하는 path 의 대상인 경우 flip-flop의 output와 마찬가지로 output을 안정적으로 사용할 수 있습니까? 이것은 data input 에 도달하는 하나 이상의 path가 다른 clock와 동기화되어 있을 때 이 flip-flop의 setup time 및 hold time을 보장할 수 있는지 묻는 것과 같습니다.

대답은 간단하고 짧습니다. 양쪽의 clocks (예:@clk1 및 @clk2 )가 related clocks인 경우 대상에 있는 flip-flop의 output은 완벽하게 문제가 없으며 이 path 에 대한 적절한 timing constraint가 달성된다면 모든 register처럼 사용할 수 있습니다. 그렇지 않으면 목적지의 timing을 보장할 수 없으며 그 사실을 해결하기 위해 resynchronization logic을 추가해야 합니다.

이 페이지 는 두 related clocks사이의 path 의 완전한 timing analysis를 보여줍니다.

위의 긴 토론 후에 이것을 몇 가지 간단한 규칙으로 요약할 때입니다.

1. unrelated clocks에 속한 clock domains 간에 paths 에 timing constraints를 적용하는 것은 불가능합니다.
2. 두 clock domains사이의 모든 paths 에 resynchronization logic이 있는 경우 이 paths에 timing constraints를 적용할 필요가 없습니다.
3. 두 clock domains사이에 path 에 resynchronization logic이 없으면 이 path에 timing constraints를 적용해야 합니다.

첫 번째 규칙은 가장 간단합니다. 두 개의 clocks가 related clocks인지 확신할 수 없다면 clock domains 사이의 모든 paths 에 resynchronization logic이 있는지 확인하십시오( 다음 페이지 에서 방법 설명). 또한 이 paths에 timing constraints가 적용되지 않았는지 확인하십시오. 두 번째 규칙에 따르면 괜찮기 때문입니다. 불필요한 timing constraints는 FPGA 도구를 더 어렵게 만듭니다.

이 규칙의 또 다른 결과는 clocks가 related clocks인 경우에도 unrelated clocks로 취급해도 된다는 것입니다. 방금 언급했듯이 모든 paths에 resynchronization logic이 있는지 확인하고 timing constraints 의 적용을 해제하여 이를 수행하십시오(자세한 내용은 아래 참조).

마지막으로 clocks가 related clocks라고 확신한다면 resynchronization logic은 필요하지 않지만 clock domains사이의 모든 paths 에 올바르게 적용되는 timing constraints가 있어야 합니다.

이 표에는 이 섹션이 요약되어 있습니다. 테이블의 행은 path의 끝에 resynchronization logic이 있는지 여부에 있고 해당 열은 clocks가 related clocks 인지 여부에 있습니다. 표 중간은 path가 timing constraints를 필요로 하는지 여부를 나타냅니다.

		clocks는
		related clocks	unrelated clocks
Resynch- ronization logic:	적용되지 않은	Timing constraints는 path에 필요합니다.	이것은 실수입니다
	적용된	path에는Timing constraints가 필요하지 않습니다.

흔한 실수

신호가 서로 다른 modules에 연결되어 있는 복잡한 design에서는 어떤 신호가 어떤 clock와 동기화되어 있는지 간과하기 쉽습니다. 따라서 한 clock domain 에서 다른 clock domain 로 자신도 모르게 이동합니다.

유해한 실수에는 두 가지 옵션이 있습니다. 첫 번째는 resynchronization logic없이 unrelated clocks 의 clock domains 사이에 path를 만드는 것입니다. 이는 이러한 paths의 대상에서 때때로 타이밍이 위반될 수 있음을 의미합니다. 타이밍의 모든 실수와 마찬가지로 눈에 보이는 문제는 매우 오해 의 소지가 있습니다. 도구가 timing constraints 에서 2개의 clocks가 related clocks라고 추론하여 timing constraints를 paths에 불필요하게 적용하면 이 도구가 혼란을 가중시킬 수 있습니다. 이러한 timing constraints는 unrelated clocks사이의 paths 에서 의미가 없지만 이러한 paths는 보고서에 제대로 처리된 것처럼 나타납니다. 이것은 timing reports 의 인간 독자를 모든 것이 괜찮다고 생각하거나 clocks가 실제로 related clocks라고 생각하도록 혼동할 수 있습니다.

두 번째 해로운 실수는 두 개의 clocks가 related clocks가 고 logic에 의해 그렇게 취급되지만 도구는 이를 그렇게 간주하지 않는 경우입니다. 결과적으로 clock domains사이에 paths 에서 timing constraints가 적용되지 않습니다. 결과적으로 목적지에서 타이밍 요구 사항이 충족된다는 보장은 없습니다. 다시 한 번, 이는 신뢰할 수 없는 동작으로 이어질 수 있습니다. 그러나 design의 타이밍 유효성 검사 에서 이러한 종류의 실수를 발견할 수 있습니다.

clock domain crossing을 알아차리지 못하는 것이 정말 무해한 유일한 상황은 related clocks와 FPGA 도구도 이를 이와 같이 간주합니다(따라서 관련 paths에 timing constraints를 적용). clocks 의 주파수가 다르고 logic이 이를 고려하지 않은 경우 여전히 기능적 버그가 있을 수 있지만 이는 logic의 모든 버그와 같습니다.

불필요한 constraining피하기

종종 단일 PLL은 다른 기능 장치에서 사용하도록 의도된 다른 주파수로 clocks를 생성하는 데 사용됩니다. 디자이너의 입장에서 보면 unrelated clocks지만 실제로는 related clocks가 고 툴에서는 보통 related clocks로 간주한다.

예를 들어 PLL이 10 MHz가 있는 reference clock 에서 두 개의 clocks를 생성한다고 가정합니다. 하나의 clock은 90 MHz가 고 두 번째 clock은 100 MHz입니다. 의도는 프로젝트의 다른 부분에 이러한 clocks를 사용하는 것이므로 개념적으로는 unrelated clocks입니다. 그러나 두 flip-flops사이에 연결이 있어 하나의 flip-flop이 하나의 clock와 동기화되고 두 번째 flip-flop이 다른 clock와 동기화된다면 어떻게 될까요?

첫 번째 clock 의 period가 11.11 ns가 고 두 번째 clock 의 period가 10 ns가 기 때문에 rising edges 사이의 최악의 시간 차이는 1.11 ns 입니다(가능한 모든 phase 조합을 고려함). 이는 900 MHz의 clock period 와 동일합니다. 따라서 이 두 flip-flops 사이의 path 의 timing은 빡빡하며, 이 요구 사항을 달성할 수 있다 하더라도 특히 이러한 paths가 많은 경우 도구에 어려움이 있습니다.

이것은 이론적인 경우가 아닙니다. 일반적인 함정은 clocks가 related clocks 인지 여부에 주의를 기울이지 않고 dual-clock FIFO를 사용하여 clock domains사이에 인터페이스하는 것입니다. 이 실수에는 기능적 문제가 없지만 dual-clock FIFOs 에는 항상 resynchronization logic이 있으므로 도구가 두 clock domains사이에 paths 에 timing constraints를 적용하도록 강제하는 것은 무의미합니다. 도구는 목적 없이 이러한 timing constraints를 달성하는 데 어려움을 겪을 수 있습니다.

따라서 그렇게 사용되지 않는 related clocks , 특히 동일한 PLL에서 나오는 clocks 에 주의를 기울이는 것이 중요합니다. 한 clock domains 에서 다른 clock domains 로 timing constraints가 paths 에 적용되는 경우가 있습니다. resynchronization logic이 타이밍 위반으로부터 보호하기 때문에 이 시행은 아무런 이점이 없습니다. 반면에 이러한 paths 에서 timing constraints를 구현하려는 도구의 노력은 전체 design에서 timing constraints를 구현하는 데 어려움을 초래할 수 있습니다.

이를 해결하려면 clocks 를 unrelated clocks로 선언하는 timing constraints를 추가합니다. 또는 이러한 paths에 대해 false paths 또는 maximal delays를 정의하십시오. 그러나 경우에 따라 이것이 필요하지 않을 수 있으므로 조치를 취하기 전에 이러한 paths 에 대해 timing report를 확인하는 것이 좋습니다. 예를 들어 FPGA 도구에서 제공하는 dual-clock FIFO를 사용하는 경우 clock domains사이에 연결되는 paths 에 적절한 timing constraints가 자동으로 추가되는 경우가 많습니다.

오해의 소지가 있는 timing constraints

FPGA tools는 일반적으로 unrelated clocks사이에서 timing constraints를 수용하고 시행한다는 점을 강조하는 것이 중요합니다. 이러한 constraints는 무의미하고 혼란스럽습니다. 특히 관련 paths가 timing report 에 타이밍 요구 사항이 보장된 것처럼 나타나기 때문입니다. 이미 논의한 바와 같이 unrelated clocks에 속하는 clock domains 사이에서 path 의 타이밍을 보장하는 것은 불가능합니다.

timing constraints는 design에 대한 정보를 FPGA tools 에 제공하는 방법일 뿐입니다. design이 timing constraints를 달성하면 timing constraints가 정확할 때만 의미가 있습니다. 따라서 clocks가 related clocks인지 확실하지 않은 경우 timing constraint를 추가하여 clock domain crossing을 해결하려고 하지 마십시오.

그리고 다시 한번, 관련이 있을 때 clocks를 unrelated clocks로 정의하는 timing constraints를 추가하거나 false paths를 정의하는 것이 좋습니다. 이는 FPGA 도구를 더 쉽게 만들 뿐만 아니라 혼란을 방지합니다.

도구가 올바르게 정보를 받았는지 확인하십시오.

위에서 언급한 모든 이유로 FPGA design 도구가 clocks가 related clocks인지 아닌지에 대한 올바른 정보를 가지고 있는 것이 중요합니다. 또는 더 정확하게는 FPGA 도구가 resynchronization logic 로 보호되지 않는 모든 paths ( clock domains내부에 paths를 포함하지만 여기서는 관련이 없음)에 timing constraints를 적용한다는 것입니다.

그러나 도구가 logic design 와 동일한 인식을 갖도록 하는 것은 어려울 수 있습니다. 각 FPGA design software 에는 clocks간의 관계에 대한 자동 가정을 수행하는 고유한 방법이 있습니다. 모든 도구가 공통적으로 가지고 있는 것으로 보이는 유일한 것은 도구의 전용 clocking IP를 사용하여 동일한 PLL로 두 개 이상의 clocks를 생성하는 경우 도구가 이러한 clocks를 related clocks로 간주한다는 것입니다. 따라서 관련 clock domains 사이의 paths는 시간이 지정되고 timing constraints는 이러한 paths에서 시행됩니다. 이 시행은 일반적으로 reference clock용으로 제공된 timing constraint를 기반으로 합니다. 그러나 그것을 당연하게 여기지 마십시오.

그 외에 각 도구에는 clocks간의 관계를 추론하는 고유한 방법이 있으며 동일한 FPGA 공급업체의 다른 도구라도 특정 상황에서는 다르게 결정할 수 있습니다. 특히 Xilinx의 Vivado는 Xilinx의 이전 주력 도구인 ISE와 비교하여 clocks가 related clocks라고 가정하는 경향이 있습니다.

따라서 모든 FPGA design 도구에 대한 일반적인 원칙은 없으며 특정 도구라도 놀라운 결정을 내릴 수 있습니다. 이 주제를 실제로 해결하는 유일한 방법은 timing reports를 확인하고 특정 path groups 용 timing reports를 생산하여 타이밍 요구 사항이 필요한 곳에서는 정확하고 불필요한 곳에서는 존재하지 않는지 확인하는 것입니다. 이것은 어려운 작업이지만 노력할 가치가 있습니다.

이것으로 이 시리즈 의 첫 페이지를 마칩니다. 다음 페이지 에서는 crossing clock domains의 기본 사항에 대해 설명합니다.