소개
FPGA designer가 되려면 한 페이지에 요약할 수 없는 다양한 기술이 필요합니다. 그러나 특히 이 직업과 관련된 몇 가지 일반적인 지침이 있습니다. FPGA design의 5가지 황금률로 요약해 보았습니다.
규칙 #1: 당신이하는 일을 알고
이것은 첫 번째 규칙이자 가장 지키기 어려운 규칙입니다. 이는 각 코드 라인, constraint 또는 구성 명령이 의미하는 바와 의미를 이해하는 것을 의미합니다. logic design의 기본 이론과 design tools가 우리가 제공하는 것에 어떻게 반응하는지 이해하는 것입니다.
시행착오를 통해 작업하는 것과는 반대로 모든 hi-tec 개발 도구 공급업체가 debuggers, 시뮬레이터 및 "쉽게" 판매되는 많은 도구를 제공함으로써 암묵적으로 권장하는 것입니다.
무언가를 적어서 소프트웨어를 개발하고, debugger로 테스트를 실행하고, 어떻게 진행되었는지 확인하고, 무언가를 수정하고, 반복하는 것은 드문 일이 아닙니다. 간헐적으로 인터넷의 예제에 있는 코드 조각도 소프트웨어에 복사하여 붙여넣을 수 있습니다. 이러한 반복적인 작업 습관은 웹 사이트 또는 스마트폰용 애플리케이션 개발과 같은 간단한 소프트웨어로 상당히 생산적일 수 있습니다. 작은 버그는 그다지 심각하지 않으며 나타나는 대로 수정할 수 있으며 일반적인 태도도 마찬가지입니다.
그러나 소프트웨어가 더 정교할수록 이 방법은 교착 상태로 더 빨리 이어집니다. 그리고 FPGA design의 경우, 반복적인 개발 관행은 빠르고 강하게 반격하는 경향이 있습니다. FPGA design 도구는 심각한 실수를 예방하거나 경고하는 데 전혀 도움이 되지 않습니다. 완전히 엉망이 되어도 무방합니다. 도구가 방해가 되지 않습니다.
규칙 #2: 작동하는지 보장
또는: "작동"은 충분하지 않습니다.
FPGA는 컴퓨터가 아니라 전자 제품입니다. 그럼에도 불구하고 design 의 특정 원칙을 따르면 반복 가능하고 신뢰할 수 있습니다(규칙 #1 참조). 그렇지 않다면 명백한 이유가 무엇이든 간에 더러운 속임수를 아주 잘 사용할 수 있습니다.
눈에 보이는 버그가 없다고 해서 문제가 없다는 것은 아닙니다. 모든 분야에서 마찬가지입니다. 예를 들어 배관공이 작업을 마치고 파이프에서 물이 새지 않았다고 해서 작업이 제대로 완료되었다는 의미는 아닙니다. 나중에 수압이 높아졌거나 누군가 실수로 파이프를 만졌기 때문에 파이프에서 누수가 시작될 수 있습니다.
그러나 우리 모두는 빠른 테스트 또는 더 광범위한 테스트를 수행하는 함정에 빠지며 모든 것이 괜찮아 보일 때 완료된 것으로 간주합니다. 단순한 웹 사이트나 중요한 응용 프로그램의 일부가 아닌 소프트웨어를 개발할 때 수도관이 새는 경우에는 충분히 허용됩니다. 그러나 FPGAs에서는 그것만으로는 충분하지 않습니다.
FPGA 용 design을 개발한다는 것은 design이 작동할 것이라는 보장을 의미합니다. 이는 design 도구가 이 정확한 목표를 달성하기 위해 제공하는 기술을 사용하여 장애 방지 기능이 있는 bitstream을 생산하도록 강요하고 있습니다.
"만약 이런 일이 일어나면 그렇게 하라"는 식으로 생각하려고 하기 보다는 logic design이 옳다는 것을 수학 증명처럼 스스로에게 증명하는 것입니다. logic은 이러한 가능성을 개별적으로 고려했기 때문이 아니라 어떤 일이 있어도 정확한 수학적 표현이 사실로 유지되기 때문에 가장 기이한 코너 케이스에서 작동해야 합니다.
그것이 결국 효과가 있다는 사실은 축하할 이유가 되지 않습니다. 올바르게 작동하는 것은 자연스러운 결과입니다.
규칙 #3: 현명하게 시뮬레이션(또는 전혀 하지 않음)
FPGA newbies가 제기하는 가장 일반적인 불만 중 하나는 시뮬레이션이 완벽하게 작동하므로 design이 정상이며 이제 다른 곳에 문제가 있음이 틀림없다는 것입니다. 물론 말도 안되는 소리입니다.
따라서 가장 먼저 Verilog 코딩 스타일이 몇 가지 엄격한 규칙을 따르지 않는 한 시뮬레이션과 하드웨어가 완전히 다른 작업을 수행할 수 있다는 것을 표에 올려 보겠습니다(물론 VHDL와 동일). 규칙 #1을 참조하십시오.
그러나 시뮬레이션은 올바르게 수행된 경우에도 제한된 시간과 시나리오를 포함합니다. 중간 크기의 design을 사용하더라도 100 ms와 같이 FPGA 내부에서 일어나는 일을 시뮬레이션하는 데 시간이 오래 걸립니다. 뿐만 아니라 하드웨어에서 실제 design을 실행하면 designer가 상상하지 못한 시나리오에 logic이 노출되어 시뮬레이션하지 않는 경우가 많습니다. 따라서 시뮬레이션을 완벽하게 거친 design은 FPGA가 시뮬레이션이 커버하는 것보다 훨씬 더 오래 실행되거나 예기치 않은 일이 발생했기 때문에 하드웨어에서 완전히 실패로 판명될 수 있습니다.
설상가상으로 모든 것이 병렬로 발생하기 때문에 하드웨어에서 버그를 찾기가 어렵습니다. 소프트웨어 디버깅과 달리 single-step을 수행하는 옵션은 고사하고 따라야 할 일련의 이벤트가 거의 없습니다. 물론 FPGA내부에 신호를 추적하는 도구가 있지만 추적할 신호와 추적 데이터 수집을 위해 trigger 로 사용할 조건을 파악하는 것이 항상 쉬운 것은 아닙니다.
따라서 시뮬레이션을 가능한 한 적게 사용하는 것을 목표로 삼으십시오. "작동하도록"하기 위해 design을 앞뒤로 수정하기 위해 시뮬레이션을 사용하는 경우 하드웨어에서 시도할 때 문제가 발생할 가능성이 높습니다.
오히려 첫 번째 실행부터 완벽하게 작동하도록 FPGA design을 작성하십시오. 이를 위해서는 코드의 첫 번째 행을 작성하고 수행 중인 작업(위의 규칙 #1)을 파악하기 전에 약간의 생각이 필요합니다. 시뮬레이션은 당신이 옳았다는 것을 확인하거나 어리석은 오타를 감지해야 합니다. 이 목표에 도달하는 것은 배우고 개선하는 과정이지만 성과가 있습니다. 결국 시뮬레이션은 고칠 것을 찾지 못하기 때문에 시간 낭비가 됩니다.
이것은 시간을 절약해 줄 뿐만 아니라 하드웨어에서 수정해야 할 버그가 점점 줄어들고 더 쉽게 발견할 수 있습니다.
나는 FPGA design 에 대한 일반적인 첫 번째 수업이 "먼저 시뮬레이션한 다음 하드웨어에서 실행"이라는 것을 잘 알고 있지만 첫 번째 수업에는 좋습니다.
규칙 #4: Don't push your luck
또는: 잘 정립된 코딩 스타일을 고수하십시오.
Verilog은 synthesis에 사용될 때 프로그래밍 언어가 아닙니다. 주요 차이점은 모든 프로그래밍 언어에서 구문적으로 올바른 것을 작성하면 compiler (또는 interpreter)가 구문이 의미하는 바를 정확히 실행한다는 것입니다. 또는 최악의 경우 오류를 보고합니다.
반면Synthesizers는 제한된 logic elements세트를 기반으로 하는 logic을 생성합니다. 따라서 Verilog 에서 코드를 작성하여 logic을 신뢰할 수 없거나 FPGA에서 구현할 수 없는 코드를 작성하는 것은 매우 쉽습니다. 설상가상으로 FPGA에서 Verilog 코드를 logic 로 구현할 방법이 없으면 synthesizers는 종종 다른 동작을 가진 logic을 생성합니다. 종종 synthesizer는 warning을 방출하지 않고 이를 수행합니다. 즉, FPGA 의 logic은 예상(즉, 시뮬레이션된) 동작과 다른 작업을 수행하며 이는 warning없이 발생합니다.
그리고 설상가상으로 synthesizers 의 버그는 compilers보다 훨씬 더 일반적입니다. 창의적인 코딩 스타일은 이러한 버그를 확실히 드러낼 수 있습니다.
위에서 말한 모든 것은 물론 VHDL 에도 해당됩니다.
따라서 이러한 종류의 문제를 피하는 유일한 방법은 다른 사람들이 널리 사용하는 코딩 스타일을 채택하는 것입니다. 염두에 두어야 할 질문은 " synthesizer가 이 코드 조각으로 인해 혼란스러워지면 나를 제외하고 얼마나 많은 사람들이 화를 낼까요?"입니다. 대답이 "많은 사람들"이라면 안전한 편에 있는 것입니다.
잘 정립된 코딩 스타일을 고수하면 또 다른 이점이 있습니다. Portability. 좋든 싫든 오늘은 하나의 synthesizer로 작업하고 내일은 완전히 다른 FPGA 와 다른 개발 도구를 사용하게 될 것입니다.
잘 정립된 코딩 스타일이 어떤 것인지 알아보려면 도구에 내장된 IPs를 대신하여 도구에 의해 생성되는 Verilog 코드를 살펴보십시오. 코드 작성자마다 약간의 다양성이 있지만 일부 코딩 패턴은 다른 패턴보다 더 많이 표시됩니다. 본받을 자들입니다.
거의 말할 필요도 없이 RTL paradigm에 따라 작동합니다. 이것은 잘 정립된 코딩 스타일일 뿐만 아니라 FPGA 도구가 기대하는 것입니다.
Verilog 에 대한 교과서와 튜토리얼은 일반적으로 포괄적이려고 하기 때문에 오해의 소지가 있습니다. 따라서 구문상 올바르지만 거의 사용되지 않으며 때로는 synthesis에 적합하지 않은 가능성을 많이 포함합니다.
규칙 #5: 타이밍이 전부다
Logic design은 소프트웨어 프로그래밍이 아닙니다. Verilog 전선과 registers에서 정확한 값을 얻는 것만으로는 충분하지 않지만 적절한 시간에 올바른 위치에 나타나는 것도 중요합니다. 또한 clocks가 올바르게 처리됩니다.
다음은 다소간 주요 주제입니다.
- 데이터가 pipelines의 여러 단계를 통해 흐르는 방법과 시기를 생각해 보십시오. 특히 pipelines가 (전체 또는 부분적으로) 중단될 수 있는 경우입니다. 실제로 모든 데이터 흐름에 대해서도 마찬가지입니다.
- timing constraints가 올바른지 확인하십시오. 특히, 외부 부품의 datasheets을 읽고 계산하십시오. 이 페이지 에서는 timing의 점검에 대해 설명합니다.
- clocks에 주의: 처음 사용한 순간부터 안정적인가요? 그들의 jitter는 그들의 목적을 위해 충분히 낮습니까?
- Clock domains crossing: resynchronization logic이 필요합니까? 그렇다면 하나의 domain 에서 다른 domain 로 신호의 장애 방지 전송을 보장합니까? 이에 대한 자세한 내용은 여기 를 참조하십시오.
요컨대, 컴퓨터 프로그램과 달리 logic design은 무슨 일이 일어날 것인지 뿐만 아니라 언제 일어날 것인지에 관한 것입니다.
요약
아무도 FPGA design이 쉽다고 말하지 않았으며 이 다섯 가지 규칙 중 어느 것도 따르기 쉽지 않습니다. 그들 각각은 지식과 자기 훈련 수준을 모두 요구합니다. 그리고 여전히 이러한 규칙을 준수하기 위해 노력할 가치가 있습니다. 그렇게 하면 특히 모든 것이 제대로 작동할 것으로 예상되는 프로젝트의 마지막 단계에서 많은 좌절을 피할 수 있습니다.