01signal.com

전자 엑소시즘: FPGAs가 때때로 홀린 것처럼 행동하는 이유

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

상황이 이상해질 때

FPGAs는 일반적으로 매우 안정적인 구성 요소라고 말하지만 다른 기술과 마찬가지로 잘못 사용하면 제대로 작동하지 않습니다.

불행히도 사용 가능한 FPGA design 도구는 인간이 실수를 저지르지 않도록 안내하는 데 매우 도움이 되지 않으며, 이는 너무 자주 신뢰할 수 없고 예측할 수 없는 결과로 이어집니다. 보다 구체적으로, FPGA 도구는 특정 design practices를 따르는 경우에만 안정적인 작동을 보장하고 우리가 무엇을 하고 있는지 알고 있다는 기본 가정이 있습니다. source code에 오류가 있는 경우 executable code 생성을 거부하는 software compilers와 달리 FPGA 도구는 다음과 같이 말합니다. "여기에 bitstream이 있습니다. 원한다면 사용해 보세요. 그런데 200 warnings가 있습니다. warning #143이 무엇을 의미하는지 이해한다면 수정해야 할 심각한 문제가 있다는 것도 알게 될 것입니다."

FPGAs 로 작업하는 사람들이 전자 장치가 어떤 마법의 힘에 사로잡혀 있고 아무 의미가 없다고 느끼는 것은 드문 일이 아닙니다. 전혀 관련이 없는 변경으로 인해 문제가 나타났다가 사라질 수 있으며 합리적인 설명이 보이지 않습니다. 제대로 교육을 받은 많은 엔지니어들은 이 이상한 행동에 대한 설명을 찾기 위해 FPGAs 에 대한 말도 안되는 이론을 채택하는 경향이 있습니다.

이것은 "Black Magic 모드"입니다. 현명한 사람들이 자신의 문제에 대한 합리적인 설명이 있다고 믿지 않고 대신 자신의 경험에 기반한 해결책을 찾을 때. FPGA가 정말 차가울 때 모든 것이 잘 작동합니까? 좋아, 거대한 heatsink을 넣어라. 문제가 일부 boards 에서만 나타나고 다른 것은 나타나지 않습니까? 자, 각 board를 테스트하고 그렇지 않은 것은 버리십시오. 등등.

어떻게 생겼는지

이것은 엔지니어에게 비합리적인 사고 방식으로 영향을 줄 수 있는 문제의 일부 목록입니다. 항상 "모든 것이 잘 작동하는 경우를 제외하고..."라고 합니다.

이것은 종종 전자 장치 자체에 결함이 있고 datasheet에 미치지 못한다는 믿음과 함께 옵니다. 거대한 회사가 결함이 있는 구성 요소를 배송하는 방법에 대한 음모 이론은 드문 일이 아닙니다.

따라서 이것은 단순한 버그가 아닙니다. 실제로 버그는 사람을 미치게 만들 수 있지만 어느 정도 반복되는 경향이 있으며 공기 상태 때문에 나타나지도 사라지지도 않습니다. 나는 소프트웨어 엔지니어가 PC 컴퓨터 자체의 버그를 비난하는 것을 들어본 적이 없습니다(실제로 매우 드문 경우이지만). 대조적으로, FPGA design 의 실수는 확실히 하드웨어 수준에서 오작동을 일으킬 수 있습니다. 거기에서 온 세상을 탓할 거리는 짧다.

논리적인 설명이 있습니다. 진짜.

그리고 손이 닿는 곳에 있습니다. 반드시 쉽지는 않습니다.

이 분야에서 꽤 오랫동안 프리랜서로 일했고 가끔 이와 같은 상황을 수정했습니다. 제가 당신에게 말할 때 저를 믿으십시오. 극히 드문 경우를 제외하고는 FPGA는 괜찮고 문제는 아마도 bitstream에 있을 것입니다.

나쁜 소식은 FPGA design에 하나 이상의 결함이 있는 경우가 매우 많으며 이러한 결함이 눈에 보이는 문제의 원인일 수 있다는 것입니다. 따라서 수정해야 할 사항이 많을 수 있습니다. 꽤 여러 번 "거의 작동하는" FPGA design을 수정하라는 요청을 받았지만 곧 "이 작은 문제"가 빨리 수정될 것이라는 비현실적인 기대에 직면하고 있음을 깨닫습니다. design을 안정화한다는 것은 눈에 보이는 진전 없이 많은 작업을 하는 것을 의미합니다.

이런 식으로 선택의 여지가 없습니다. 이 페이지에서 나는 전자 제품에서 유령처럼 보이는 것에 대한 가능한 이유를 나열함으로써 합리적인 사고를 되살리려고 노력할 것입니다.

물론 가장 좋은 방법은 처음부터 이런 상황을 피하는 것입니다. 다른 페이지에 나열한 황금률 을 따르는 것이 좋은 시작입니다.

상황이 이상해지는 이유

음, 짧은 대답은 FPGA design에 문제가 있다는 것입니다. 그리고 그런 경우에는 원칙적으로 두 가지 가능성이 있습니다. 상대적으로 운이 좋은 가능성은 FPGA가 수행해야 하는 작업의 가시적이고 꾸준한 오작동이 있을 때입니다. 이것은 소프트웨어 버그와 같습니다. 그것을 찾아 수정하고 수정 후 작동하는지 확인하십시오.

덜 운이 좋은 가능성은 FPGA가 작동하지만 대부분 운이 좋은 우연의 일치입니다. 따라서 일부 조건이 변경되면 FPGA가 갑자기 제대로 작동하지 않고 정상적으로 작동할 수 있습니다. 그러나 왜 이런 일이 발생합니까?

요점은 다음과 같습니다. FPGA는 전자 제품이므로 제조 과정에서 부정확한 부분이 있습니다. 더욱 중요한 것은 silicon 의 온도가 변하면 transistors가 상태를 변경하는 속도도 바뀌고 logic fabric에서 신호가 전파되는 속도도 마찬가지라는 것입니다. supply voltage 의 변경 사항은 FPGA내부에서 발생하는 속도에도 영향을 미칩니다.

따라서 FPGA가 조금 더 따뜻하거나 더 차갑게 되면 clock에 비해 신호가 flip-flop 에 약간 늦게 또는 조금 더 일찍 도착할 수 있습니다. 이것만으로도 flip-flop이 샘플링했어야 하는 신호를 놓치거나 flip-flop이 일반적으로 놓치는 신호를 샘플링할 수 있습니다. chip 의 인접(및 관련 없는) logic이 덜 활성화되거나 더 활성화되면 silicon 의 국부적 가열로도 이 문제가 발생할 수 있습니다.

마찬가지로 FPGAs는 제조상의 부정확성을 가지고 있습니다. 공장에서 출고되는 모든 FPGAs가 사양과 호환되는지 확인하는 테스트를 통과했지만 일부 FPGAs는 다른 silicon 보다 더 빠를 수 있습니다. 이것이 부적절하게 만들어진 logic design이 한 FPGA 에서는 작동하고 다른 FPGA 에서는 작동하지 않을 수 있는 이유입니다.

이러한 모든 임의 매개변수는 logic fabric에서 작은 구성 요소가 상태를 변경할 때 영향을 미치며 타이밍의 차이는 완벽하게 작동하는 것과 재앙을 구분할 수 있습니다. 따라서 제조, 온도 및 전압의 작은 편차가 눈에 띄는 차이를 만들 수 있습니다.

그렇다면 FPGA는 어떻게 신뢰할 수 있습니까? FPGA design이 올바르게 만들어지면 FPGA design 도구는 모든 것이 항상 정의된 대로 작동하는지 확인합니다. 또는 더 정확하게는 모든 것이 제조 테스트를 통과하고 datasheet의 요구 사항 내에서 사용되는 모든 FPGA 에서 작동합니다. 이것은 필요한 범위 내에서 주변 온도를 유지하고(필요한 경우 냉각 포함) FPGA핀의 올바른 전압으로 요약됩니다.

그러나 필요한 FPGA design 관행을 따르지 않으면 도구도 적절한 작동을 보장하지 않습니다. 즉, 아무런 차이가 없어야 하는 매개변수가 중요해지고, 전혀 중요하지 않아야 하는 항목에 따라 전체 board가 작동을 멈추고 다시 작동합니다. 이상한 일이 생길 수 있는 방법에는 제한이 없습니다.

반복되는 위험을 무릅쓰고 다음과 같은 몇 가지 예를 들 수 있습니다.

이것은 계속해서 반복할 가치가 있습니다: FPGA design이 제대로 완료되면 이런 일이 발생하지 않습니다. 또는 최소한 극히 드물게. datasheets을 읽고 따라하고 FPGA 도 올바르게 사용할 때 전자 장치가 얼마나 안정적인지 깨닫는 사람은 거의 없습니다.

그러나 나는 이 설교가 이 페이지를 읽는 사람들에게 너무 늦었다고 생각합니다. 문제는 이미 거기에 있습니다. 그래서 내 자신의 경험을 바탕으로 유령처럼 보이는 FPGA에 대한 몇 가지 일반적인 이유를 나열했습니다. 이러한 문제에 직면하고 있다면 다음 중 하나일 가능성이 높습니다.

이유 #1: Timing

대부분 도구는 귀하가 제공한timing constraints를 구현하여 FPGA 의 안정적인 작동을 보장합니다. 이것은 귀하와 도구 간의 거래입니다. 타이밍 요구 사항을 정확하게 표현하고 FPGA가 허용된 온도 및 전압 범위 내에서 작동하는 한 도구는 사용하는 모든 FPGA 에서 이러한 요구 사항을 충족하는지 확인합니다.

timing constraints가 reference clock의 주파수를 포함하는 단일 constraint인 것은 드문 일이 아닙니다. 이것으로 충분할 수도 있지만 다른 design 에서 이 행을 방금 복사했는데 작동한다면 검토할 충분한 이유가 있습니다.

실제로 이것은 일반적으로 timing을 올바르게 수행하는 것에 관한 것입니다. 그리고 가장 경험이 풍부한 FPGA designer도 마찬가지입니다. 이는 design 의 모든 단일 signal path가 constraint 에 의해 제어되어 끝에 있는 flip-flop이 항상 신호를 올바르게 수신하도록 하는 것을 의미합니다. constraining이 필요하지 않은 paths를 제외하고.

따라서 가장 먼저 확인해야 할 사항은 다음과 같습니다. design이 timing constraints를 달성했습니까? 이것은 정말 기본이지만, 대부분의 FPGA 도구는 상관없이 bitstream을 생성하므로 FPGA newbies는 이 간단한 실수에 빠질 수 있습니다.

다음은 timing constraints를 검토하는 것입니다. 그러한 검진에 대해 논의 하는 별도의 페이지 가 있지만 긴 이야기를 짧게 하자면: timing constraints가 무엇을 의미하는지 정확히 이해하고 계십니까? 그 의미가 정확히 있어야 합니까? 선택적 timing constraints가 있는 경우(즉, paths를 filter conditions 로 특별히 덮는 경우) 실제로 올바른 paths에서 작동합니까?

그런 다음 timing report를 주의 깊게 읽어야 합니다. 다시 한 번 이 별도 페이지 에서 이 주제에 대해 자세히 설명합니다.

살펴볼 또 다른 것은 clock domain crossings입니다. 한 clock domain 에서 다른 clock domain 로 안전하지 않게 이동하는 신호가 있습니까? 이것은 logic이 각 clock와 관련되어 있는지에 대한 관심 부족 때문일 수 있습니다. clock domain crossings는 FPGA 도구로 만든 FIFOs 로만 수행됩니까? 그렇지 않다면 crossings가 정확하고 안전하게 완료되었습니까?

이유 #2: 부적절한 resets

관련이 없어 보일 수 있지만 logic의 초기 상태가 보장되지 않으면 black magic 동작이 발생할 수 있습니다.

규칙은 간단합니다. resets 와 logic의 절전 모드 해제에 대해 진지한 생각을 하지 않았다면 잘못 생각했을 가능성이 큽니다.

특히 다음 예를 고려하십시오.

always @(posedge clk or negedge resetn)
     if (!resetn)
       the_reg <= 0;
     else
       the_reg <= [ ... ] ;

resets 에 대한 관점이 이와 같은 코드를 작성하는 것이라면 @resetn이 비활성화 될 때(즉, 이 예에서 high 로 변경) 어떤 일이 발생하는지 명시적으로 처리하지 않고 이 페이지 를 반드시 봐야 합니다.

어느 쪽이든 resets가 있어야 할 위치에 있는지, 제대로 작동하는지 확인하는 것이 좋습니다. 이것이 의미하는 바는 이 주제에 대한 짧은 페이지 시리즈 에서 논의됩니다.

이유 #3: Clocking

clocks 의 품질은 아마도 digital design에서 가장 과소평가된 주제일 것입니다. "네, 하이에서 로우로 바뀌고, 반대로 clock로 사용합시다." 라는 식으로 자주 나옵니다.

FPGA logic 와 함께 사용되는 clocks는 안정적이고 적절한 jitter 성능을 가져야 합니다. 그에 못지 않게 중요한 것은 clock 와 FPGA 의 물리적 연결이 안정적이고 신뢰할 수 있어야 한다는 것입니다.

따라서 이와 같은 진술에서,

always @(posedge clk)

@clk 로 사용되는 것은 무엇이든 세심한 주의를 기울여야 합니다. 이상적으로 이 clock은 전용 clock generator 구성 요소(oscillator)에서 시작되어 안정적이고 낮은 jitter를 가진 clock을 보장합니다. 일반적으로 이 외부 clock을 logic에 직접 연결하는 것보다 reference clock 에서 PLL로 사용하는 것이 좋습니다. 이는 PLL이 clock의 주파수를 변경하지 않더라도 마찬가지입니다.

PLL을 사용하면 PLL의 lock detector를 모니터링할 수 있기 때문입니다. 따라서 이 clock 에 의존하는 logic은 PLL이 잠금 해제될 때 reset 상태로 유지될 수 있습니다. 이렇게 하면 reference clock 에 안정성 문제가 있는 경우(특히 powerup직후) 문제가 발생할 가능성이 크게 줄어듭니다.

PLL은 문제 해결사로 오인될 수 있으며, 산발적으로 lock을 잃어버리기 때문에 분명히 불필요한 resets가 발생합니다. PLL을 제거하고 외부 clock을 logic에 직접 연결하여 실수로 "고정"하면 모든 것이 제대로 작동하는 것처럼 보입니다. 이와 같은 경우 reference clock에 문제가 있을 가능성이 있습니다. 이 경우 PLL을 제거해도 문제가 해결되지 않고 오히려 logic fabric에 밀어 넣어 black magic 상황이 발생할 수 있습니다.

지금까지 전용 oscillators에서 clocks 에 대해 논의했는데, 이는 정말 쉬운 경우입니다. 다른 출처에서는 더 나빠집니다. processor 또는 주변 장치 중 하나에 의해 생성된 Clocks는 신중하게 사용해야 합니다. 이러한 clocks는 processor에 의해 일시적으로 중단되거나 때때로 불법적인 waveforms를 생성할 수 있습니다. 이는 소프트웨어가 관련 없는 작업의 일부로 관련 hardware registers에 쓰기 때문일 수 있습니다. 이러한 짧은 이벤트는 oscilloscope로 clock을 검사할 때 보이지 않을 수 있지만 이러한 짧은 이벤트는 그럼에도 불구하고 이상한 오작동을 일으킵니다.

또 다른 일반적인 문제 원인은 source-synchronous clock 를 잘못 취급하는 것입니다. 즉, 외부 구성 요소가 clock 신호와 하나 이상의 데이터 신호를 공급하여 데이터가 clock와 동기화되는 경우입니다. 일반적으로 데이터 신호는 clock의 rising edges 와 함께(또는 falling edges에서만) 값을 변경할 수 있습니다.

일반적이지만 오히려 위험한 방법은 source-synchronous clock을 FPGA내부의 application logic에 직접 연결하는 것입니다. 이것의 문제 중 하나는 source-synchronous clock이 종종 연속적인 clock로 사용하도록 의도되지 않았기 때문에 일시적으로 멈추거나 spurious pulses를 가질 수 있다는 것입니다.

또 다른 가능한 문제는 데이터 소스가 케이블을 통해 main board 에 연결된 카메라인 경우와 같이 source-synchronous 인터페이스가 물리적 커넥터를 통해 종종 FPGA 에 연결된다는 것입니다. 커넥터는 일반적으로 신뢰할 수 있지만 진동으로 인해 나노초 동안 물리적 접촉이 손실되더라도 clock 신호에서 잘못된 pulse가 발생할 수 있습니다. 이것은 물론 데이터 신호에서도 발생할 수 있지만, 특히 데이터 소스가 카메라인 경우 일반적으로 덜 중요합니다. 그러나 이러한 clock 신호가 application logic 에 직접 연결되면 1나노초 pulse가 확실히 엉망이 될 수 있습니다.

따라서 source-synchronous와 clock 및 데이터 인터페이스를 위한 최상의 솔루션은 clock 와 data를 일반 신호로 취급하는 것입니다. 따라서 source-synchronous clock 와 데이터 신호는 모두 안정적이고 안전한 훨씬 더 빠른 clock을 사용하여 flip-flops로 샘플링됩니다. 바람직하게는 I/O pins에 인접한 전용 flip-flops 로 이 작업을 수행합니다.

source-synchronous clock이 로우에서 하이로 변경되면 이 신호를 샘플링하는 flip-flop 의 output 에서 유사한 변경이 반영됩니다. 따라서 flip-flop 의 output이 로우에서 하이로 변경된다는 단순한 사실에 의해 source-synchronous clock 의 rising edges는 동기식 logic로 감지될 수 있습니다. 이 logic은 물론 더 빠르고 안정적인 clock을 기반으로 합니다. 이 logic이 이와 같은 rising edge를 감지하면 데이터를 유효한 것으로 표시합니다. 즉, data inputs 의 값이 포함된 flip-flops 의 outputs는 유효한 데이터로 표시됩니다.

01-signal sampling을 사용하는 이 방법의 분명한 이점은 clock 신호에 무슨 일이 일어나더라도 FPGA의 logic은 계속 안전한 clock에 의존한다는 것입니다. source-synchronous clock이 미쳐버릴 경우 적절하게 반응하는 edges를 감지하는 것은 logic 에 달려 있습니다.

이 기술은 source-synchronous clock 의 상대적으로 낮은 주파수에서 가능합니다( FPGA의 속도와 DDR sampling이 사용되는 경우 일반적으로 최대 200-300 MHz).

더 빠른 소스의 경우 선호되는 솔루션은 PLL에 소스의 clock을 공급 하고 PLL의 output을 application logic와 함께 사용하는 것입니다. 위에서 언급한 대로 PLL이 잠겨 있지 않다고 표시하면 logic을 재설정해야 합니다. 이것은 다른 이유로도 올바른 솔루션일 수 있습니다. 주파수가 01-signal sampling 에 대해 제안한 대로 너무 높으면 적절한 sampling을 보장하는 유일한 방법은 clock의 phase shifting 덕분에 타이밍을 찾는 것입니다. 이는 샘플링된 신호에서 오류가 감지되지 않을 때까지 타이밍이 logic 에 의해 자동으로 조정됨을 의미합니다. 이 기술은 어쨌든 PLL을 사용해야 합니다.

이유 #4: RTL design의 규칙 위반

synthesis 에 대한 적절한 Verilog 코드(또는 VHDL)는 몇 가지 엄격한 규칙, 특히 RTL paradigm (Register Transfer Level)를 따라야 합니다. 무엇보다도 이것은 일종의 메모리(예: flip-flop)인 모든 logic element가 clock edge의 결과로만 값을 변경함을 의미합니다. 이것에 대한 유일한 예외는 asynchronous reset이 며, 이는 어떤 신호도 될 수 없습니다 .

synthesizer가 이러한 규칙을 위반하는 Verilog 코드를 만나면 일반적으로 협력을 시도하고 시뮬레이션이 보여주는 것과 동일하게 동작하지 않을 수 있는 logic을 생성합니다. 또 다른 가능성은 synthesis 의 결과가 대부분의 경우 예상되는 동작을 충족하지만 무작위로 실패할 수 있다는 것입니다.

예를 들어, 0 와 14사이의 카운터에 대해 다음과 같은 잘못된 design을 고려하십시오.

reg [3:0] counter;
wire      reset_cnt;

assign reset_cnt = (counter == 15); // This is so wrong!

always @(posedge clk or posedge reset_cnt)
  if (reset_cnt)
    counter <= 0;
  else
    counter <= counter + 1;

끔찍한 실수는 @reset_cnt를 asynchronous reset로 사용하는 것입니다.

그러나 이것이 시뮬레이션에서 어떻게 작동하는지 설명하는 것으로 시작하겠습니다. @counter는 @clk의 rising edges 에서 카운트 업합니다. 그러나 @counter가 값 15에 도달하면 @reset_cnt가 '1' 로 변경되고 비동기식으로 @counter를 다시 0으로 재설정합니다. 따라서 @counter가 @clk로 샘플링되면 0 ~ 14값이 표시되어야 합니다.

하드웨어에서는 이것이 작동하지 않을 수 있습니다. 문제는 @reset_cnt가 @counter의 combinatorial function 라는 것입니다. 따라서 @counter가 7에서 8로 값을 변경하면 @reset_cnt를 계산하는 logic은 @counter 의 값을 15 로 잠시 볼 수 있습니다. 7은 binary code에서 0111이 고 8은 1000로 인코딩되어 있기 때문입니다. 따라서 bit 3이 @reset_cnt를 계산하는 logic 에 대해 가장 짧은 propagation delay을 가지고 있다면 이 신호는 간단히 '1' 일 수 있습니다. 결과적으로 @counter는 때때로 0 에서 14 로 계산되고 때로는 0 에서 7로 계산됩니다. 온도 및 기타 관련 없는 요소는 관찰되는 옵션 중 하나에 영향을 미칠 수 있습니다.

그러나 이 예가 잘못된 이유에 대한 설명은 크게 단순화되었습니다. 도구는 가장 창의적인 방법으로 combinatorial logic을 자유롭게 구현할 수 있으므로 clock edges간에는 거의 모든 일이 발생할 수 있습니다. 도구가 보장하는 유일한 것은 신호가 대상(setup time 및 hold time)에서 flip-flops 의 타이밍 요구 사항에 따라 안정적이라는 것입니다.

따라서 logic design이 RTL design에 관한 규칙을 엄격하게 따르지 않는 한 이상한 일이 확실히 발생할 수 있습니다.

이유 #5: 온도 및 power supplies

이것은 문제의 일반적인 원인이 아니며 확인하기 쉽습니다. 그럼에도 불구하고 온도와 power supplies는 이상한 문제의 근본 원인이 될 수 있습니다.

아주 자연스럽게 silicon의 온도가 허용 범위를 벗어나면 작동이 보장되지 않습니다. 가장 일반적인 이유는 불충분한 열 계획으로 인한 과열 또는 먼지와 씨름하는 팬입니다.

power supplies의 경우 여러 가지 이유로 결함이 있는 output을 생성할 수 있습니다. oscilloscope 로 간단히 확인하면 전압이 지정된 범위 내에 있는지 여부를 알 수 있습니다. 그러나 전압은 항상 이 범위 내에 있어야 합니다. 평균 전압이 정확하다는 것만으로는 충분하지 않습니다. switching power supplies가 항상 생성하는 소음이나 가끔 발생하는 spikes가 한계를 초과해서는 안 됩니다.

1 μs 보다 길지 않은 spike가 무해한 것처럼 보일 수 있지만 FPGA내부에는 수십에서 수백 clock cycles가 있으므로 이 기간은 FPGA 에 잘못된 전압이 공급되는 상당한 시간입니다. 실제로 도달하는 전압을 보려면 FPGA 에 가까운 decoupling capacitors 의 전압을 측정하는 것이 좋습니다. 또한 oscilloscope의 trigger를 상한 및 하한 전압 제한에서 구성하고 oscilloscope이 이에 반응하지 않는지 확인하십시오. oscilloscope의 디스플레이에서 짧은 spikes를 알아차리기는 쉽지 않지만 trigger는 그들을 잡을 것입니다.

때때로 power supply 문제는 열악한 board design의 직접적인 결과입니다. 많은 power supply modules 에는 종종 간과되는 minimal current가 있습니다. 이 minimal current가 power supply module에서 배수되지 않으면 불안정해지고 사양에 맞지 않는 전압을 생성할 수 있으며 더 심하게는 때때로 oscillations가 있을 수 있습니다.

또 다른 일반적인 실수는 voltage regulator가 필요한 곳에 switching power supply을 배치하는 것입니다. 특히, 아주 깨끗한 input이 필요한 low-jitter clock oscillators가 있습니다. 이러한 oscillator가 노이즈가 있는 power supply에 의해 공급되면 이 노이즈는 clock output의 jitter 에 반영됩니다. Gigabit transceiver가 이 clock (예: PCIe, USB 3.x, fiber optics 등)를 사용하는 경우 이는 종종 data link을 신뢰할 수 없게 만듭니다.

마찬가지로 DDR memories가 design의 일부인 경우 reference voltage power supply이 필요합니다. 이 전압은 FPGA 와 DDR memories 모두에서 이 두 구성 요소 사이를 연결하는 와이어의 '0' 와 '1' 사이의 전압 임계값으로 사용됩니다. 이 전압이 switching power supply에 의해 생성되는 경우 voltage supply noise가 FPGA 와 DDR memories간에 오류 없이 데이터를 전송하는 것을 더 어렵게 만들거나 심지어 불가능하게 만들 가능성이 있습니다.

이유 #6: 장난해?

때로는 black magic 상황의 원인이 너무 커서 어떤 것이 작동했는지 의아하게 생각하는 결함이 있습니다. 예를 들어, PCB 의 배선이 관련 FPGA pin에서 완전히 분리되었지만 crosstalk 또는 parasitic capacitance덕분에 올바른 신호가 FPGA 에 도달하는 경우입니다.

이것은 clocks에서 특히 발생하는 경향이 있습니다. 왜냐하면 board전체에 종종 연결되어 있기 때문입니다. 그리고 주기적 신호라는 사실은 FPGA 에 도달할 가능성을 높여서 괜찮은 것처럼 보입니다.

그러니 꼭 oscilloscope을 가지고 모든 clocks를 FPGA에 최대한 가깝게 확인하십시오. clock용 AC coupling capacitor가 있는 경우, 특히 capacitor가 누락되었음을 발견할 수 있기 때문에 확인하는 것이 좋습니다.

이유 #7: 일반 버그

또는 더 정확하게: design은 작동하도록 만들어진 적이 없습니다. 아무도 앉아서 logic이 어떻게 작동하는지 알아낸 적이 없습니다. 대신에 부분적으로는 시뮬레이션으로 부분적으로는 하드웨어를 사용하여 trial and error로 코드를 점진적으로 작성했습니다. 이 프로세스는 잘 작동하는 것처럼 보였을 때 완료되었지만 코드를 보면 전혀 작동하지 않는 것이 기적처럼 보입니다. 그 작은 부분을 수정하기 위해 여러 번 패치되었기 때문에 변경은 고사하고 진행 상황을 추적하는 것은 불가능합니다.

실제로 black magic 동작이 아니기 때문에 이 이유를 마지막에 넣었습니다. 아주 짜증나는 버그일 뿐입니다. 그럼에도 불구하고 이것이 FPGA 프로젝트가 중단되는 가장 일반적인 이유입니다.

그래도 FPGA의 잘못이라고 생각한다면

때로는 당신의 잘못이 아닙니다. FPGA 자체 또는 공급업체 소프트웨어에 버그가 있을 수 있습니다. 이것은 사람들이 FPGA의 공급업체를 비난하는 경향보다 훨씬 덜 자주 발생하지만 드문 경우지만 실제로 그렇습니다.

다른 사람을 비난하고 싶은 자연스러운 유혹 때문에 자신에게 호의를 베풀고 FPGA를 비난하여 엑소시즘 세션을 끝내지 마십시오.

이러한 작업 없이 마무리하고 어떻게든 문제를 해결하면 나중에 문제를 다시 만날 수 있는 좋은 기회가 있습니다.

FPGA 자체의 버그에 대한 가장 좋은 예는 오래 전 Xilinx Virtex-4의 hardware FIFO 였습니다. 즉, FIFO 의 control logic이 silicon 에서 직접 구현된 dual clock FIFO 입니다(즉, logic fabric이 아님).

FIFO를 통한 데이터 흐름이 때때로 중단되었습니다. 약간의 조사 후에 FIFO는 잠시 동안 제대로 작동한 후 empty 신호와 full 신호를 동시에 활성 상태로 유지하는 것으로 나타났습니다. FIFO가 reset에서 유지되지 않는 한 이것은 불법적인 조건입니다. 그래서 정확한 신호를 관찰하고 있다는 것을 절대적으로 확인한 후, 버그가 있다는 결론으로 케이스를 종료했습니다.

FPGA의 FIFO. 그리고 대신 logic fabric 에 구현된 FIFOs를 선택했습니다.

몇 달 후, 이 FIFOs 에서 errata record를 찾았습니다. 이 errata record는 문제에 대해 미리 알지 못했다면 이해할 수 없었을 것입니다. 그러나 설명을 매우 주의 깊게 읽은 후, 그것이 내 관찰을 확인시켜 주었다고 결론을 내릴 수 있었습니다.

그것은 문제를 "내 잘못이 아님"으로 선언하는 것이 OK이기 전에 FPGA의 버그가 얼마나 명백해야 하는지에 대한 예일 뿐입니다.

요약

FPGA가 자연의 법칙을 무시하는 것처럼 보일 때 상식에서 벗어나는 설명을 채택하고 싶은 유혹이 있습니다. 그럼에도 불구하고 합리적인 설명을 찾는 것이 중요합니다. 그리고 매우 자주 이 설명은 초능력 없이도 찾을 수 있습니다.

그러나 그 이유를 찾기 위해서는 design에 대한 철저한 검토가 필요할 수 있으며, 이것이 반드시 나쁜 것은 아닙니다. 이러한 사냥이 좌절스러울 수 있지만, 상관없이 design의 품질에 크게 기여할 수 있습니다.

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