이 페이지는 타이밍에 관한 연재 페이지 중 첫 번째입니다.
그 보상은 마음의 평안입니다
타이밍, 특히 타이밍 제약(timing constraints)은 FPGA 설계자에게 커다란 도전 과제입니다. 타이밍을 이해하기 어렵다는 점만 문제인 것은 아닙니다. 실제 도전은 FPGA 설계를 하는 동안 모든 것이 제대로 동작하기 때문에 이 주제 전체를 무시하고 싶은 유혹을 극복하는 일입니다. 눈에 보이는 문제가 없을 때 설계에 만족해 버리는 함정에 빠지기란 너무나 쉽습니다.
FPGA 설계자들이 타이밍이 부족하다는 건 알지만, 그래도 전자 기기가 시계처럼 정확히 동작하니 신경 쓰지 않는다고 말하는 것은 드물지 않습니다. 실제로도 그런 순간에는 타이밍을 제대로 처리하는 일이 시간 낭비처럼 보일 수 있습니다. 새 기능을 계속 개발하고 싶어 하는 관리자는 프로젝트에 별다른 진전이 없는 몇 주를 반기지 않을 것입니다. 사실, 설계의 타이밍을 제대로 검사하다 보면 해결하기 어려운 문제들이 발견될 수도 있습니다. 남들이 보기에는 존재하지 않는 문제를 지어내서 소중한 시간을 낭비하는 것처럼 보일 수 있습니다.
사실 타이밍을 무시하는 전략은 단기적으로는 효과를 보는 경우가 많습니다. 하지만 이 주제에 제대로 신경 쓰지 않으면 가장 골치 아픈 문제가 생기기 십상이고, 그런 문제는 꼭 가장 난처한 순간에 나타나곤 합니다. 예를 들어 전자 기기가 최종 승인 테스트 중에, 아마도 시스템을 전체 온도 범위에서 시험하는 동안 몇 시간에 한 번씩 고장 날 수 있습니다. 더 심한 경우도 있습니다. 제품이 출시된 지 몇 년이 지난 뒤에야 고객 불만이 들어오기 시작하는 것입니다. 불만의 원인을 찾느라 안간힘을 쓴 끝에, 그 제품들에 들어간 FPGA가 다른 배치(batch)에서 제조되었다는 사실이 드러납니다. 모든 FPGA가 데이터시트 요구 사항을 충족했음에도, 실리콘의 차이 때문에 새 FPGA가 조금씩 다르게 동작한 것입니다.
FPGA는 이런 사건들 때문에 좋지 않은 평판을 얻었습니다. 하지만 타이밍을 제대로 처리했다면 이런 일이 일어나지 않는다고 어느 정도 확신할 수 있습니다. FPGA는 설계가 올바르게 완성되었을 때 매우 믿음직한 부품입니다.
그러니 스스로에게 잘해 주는 셈 치고, 타이밍이라는 주제를 배우는 데 시간을 투자하고, 배운 지식을 항상 빠짐없이 활용하세요. 이렇게 하면 무엇인가를 변경할 때마다 설계에 예상치 못한 문제가 생길 것이라는 끊임없는 두려움에서 벗어날 수 있습니다. 나타났다 사라지는 버그를 끝없이 쫓는 일에서도 벗어나게 됩니다. 무엇보다 FPGA를 믿을 수 있고 견고한 부품으로 자연스럽게 여기게 될 것입니다.
타이밍 제약의 중요성
FPGA 내부의 로직은 FPGA 설계에 있는 모든 동기 요소 하나하나의 타이밍 요구 사항이 충족되어야만 안정적으로 동작할 수 있습니다. 이를 보장하려면 가능한 모든 경로(path)를 검사해야 합니다. 아무리 단순한 로직 설계라도 이러한 계산을 손으로 다 하는 것은 불가능합니다.
그러므로 모든 타이밍 요구 사항이 충족되는지 확인하는 것은 툴의 몫입니다. 툴이 그렇게 하려면 필요한 계산을 수행하는 데 쓰는 모든 정보가 툴에 제공되어야 합니다. 예를 들어 툴은 모든 클록의 주파수와 외부 부품이 타이밍 측면에서 어떻게 동작하는지 알아야 합니다. 이러한 정보는 타이밍 제약으로 툴에 전달되며, 타이밍 제약은 대개 특수한 문법을 가진 텍스트 파일로 구성됩니다.
타이밍 제약이 잘못 작성되었거나 필요한 정보를 모두 담지 못하면, 툴은 로직 설계가 안정적으로 동작한다고 보장할 방법이 없습니다. 툴은 타이밍 제약에 담긴 정보에 의존하므로, 그 정보가 틀렸거나 일부만 있으면 툴이 수행하는 타이밍 계산도 틀리거나 불완전할 수밖에 없습니다. 제대로 작성되지 않은 타이밍 제약은 FPGA가 불안정하게 동작하는 흔한 원인입니다.
따라서 툴과의 암묵적인 약속은 이렇습니다. 우리는 타이밍에 대해 툴이 알아야 할 모든 것을 알려 주고, 툴은 설계에 타이밍 위반이 없도록 보장합니다.
하지만 툴이 타이밍 위반을 피하지 못하는 경우도 있습니다. 그럴 때 툴은 그 사실을 알리는 경고 메시지를 출력합니다. 이것은 오류가 아니라 경고일 뿐이므로, FPGA 툴은 FPGA에 로드할 수 있는 비트스트림(bitstream) 파일을 계속 생성합니다. 따라서 툴이 타이밍 제약을 충족했음을 확인해 주는지 항상 검증하는 것이 중요합니다. 이 확인은 대개 "모든 타이밍 제약이 충족되었습니다"와 같은 메시지로 이루어집니다.
하지만 타이밍 제약만이 전부는 아닙니다
여러분과 FPGA 소프트웨어 사이의 암묵적인 약속은 사실 훨씬 더 광범위합니다. FPGA 설계가 어떤 모습이어야 하는지에 대한 몇 가지 규칙을 지키면, 툴은 FPGA가 고장 나지 않도록 보장합니다. 그러나 규칙을 어기면 툴도 보복합니다.
타이밍을 올바르게 맞추는 일은 그러한 규칙에서 중요한 부분입니다. 그리고 타이밍은 단지 타이밍 제약을 작성하는 문제만이 아닙니다. 알아 두어야 할 측면이 세 가지로 나뉩니다.
첫 번째 측면은 로직 설계 자체, 즉 Verilog(또는 VHDL) 코드입니다. 물론 로직이 충분히 '빠르다'는 당연한 요구 사항이 있습니다. 더 정확히 말하면, 로직 설계가 원하는 주파수에서 클록이 동작할 수 있게 해 주어야 한다는 뜻입니다. 그에 더해 기억해 둘 것이 몇 가지 더 있습니다.
- 올바른 Verilog(또는 VHDL) 코드를 작성하기 위한 기본 규칙, 특히 RTL 패러다임이 지켜져야 합니다. 그렇지 않으면 툴은 합성 도구(synthesizer)가 생성한 로직에 타이밍 제약을 강제할 수 없습니다.
- 클록 도메인 교차(clock domain crossing) 구간에서는 적절한 기법을 사용해야 합니다(자세한 내용은 여기를 참조하세요).
- 클록은 혼동이 생기지 않도록 잘 정리되어야 합니다. 특히 의도하지 않은 클록 도메인 교차가 생기지 않도록 하는 것이 중요합니다.
두 번째 측면은 타이밍 제약을 작성하는 일입니다. 이 부분은 때로는 정말 쉽고, 때로는 세심한 작업이 필요합니다. 다른 설계에서 타이밍 제약을 복사해 오는 실수는 흔합니다. 특히 클록 주기 제약 하나만 복사해 오고는 작업이 끝났다고 생각하는 경우가 많습니다.
세 번째 측면은 툴이 설계의 안정적인 동작을 보장하는 역할을 실제로 수행했는지 확인하려고 타이밍 리포트를 생성하고 읽는 일입니다. 이 부분이 가장 어렵습니다. 주된 이유는 FPGA 내부에서 어떻게 동작하는지 이해해야 하기 때문입니다. 타이밍 리포트는 FPGA의 가장 작은 구성 요소들을 기준으로 작성됩니다. 따라서 FPGA에 대한 그러한 이해 없이는 리포트에서 유용한 결론을 얻기 어렵습니다.
사람들은 보통 문제를 해결하기 위해 타이밍 리포트를 읽습니다. 특히 툴이 타이밍 제약이 요구하는 조건을 달성하지 못했을 때가 그렇습니다. 이와 같은 문제를 해결하는 과정을 타이밍 클로저(timing closure)라고 합니다. 가장 흔한 문제는 로직 설계에 비해 클록 주파수가 너무 높은 것입니다. 반대로 클록에 비해 로직이 너무 느리다고 말할 수도 있습니다.
앞서 언급했듯이, 타이밍 제약을 충족하고 모든 것이 완벽하게 동작하더라도 FPGA 설계의 타이밍을 가끔 점검해 보는 것이 좋습니다. 여기에는 특히 타이밍 리포트를 확인하는 일이 포함되며, 타이밍 제약이 로직의 요구 사항을 정확히 반영하는지 확인하는 일도 포함됩니다. 어려운 점은 그러한 점검이 단기적으로는 별다른 보람이 없다는 데 있습니다. 점검에는 시간과 노력이 들고, 결과는 아무 문제가 없거나 문제가 발견되는 둘 중 하나로 끝나기 마련입니다. 따라서 점검에 성과가 있었다면, 이는 실제로 아무도 볼 수 없는 문제를 해결하기 위한 더 많은 작업이 필요하다는 뜻입니다.
타이밍 관련 페이지들은 어떻게 구성되어 있나
이 페이지들은 여러분과 FPGA 툴 사이의 암묵적인 약속 가운데 두 번째와 세 번째 측면, 즉 타이밍 제약을 작성하는 일과 타이밍 리포트를 읽는 일에 초점을 맞춥니다. 이러한 작업에는 이론적 지식뿐 아니라 실무에서 실제로 사용할 수 있는 도구가 필요합니다.
타이밍 제약의 실무적인 측면은 비교적 배우기 쉽습니다. 어려운 부분은 타이밍 제약이 정확히 무엇을 뜻하며 설계에 어떤 영향을 주는지 이해하는 것입니다. 이 시리즈의 다음 페이지에서는 기본적인 이론 개념을 살펴봅니다. 이후 페이지에서는 몇 가지 타이밍 리포트 예시를 통해 이론 논의를 이어갑니다. 타이밍 분석의 사소한 세부 사항에 모든 이야기가 담겨 있습니다.
다음 페이지 바로 뒤에 이어지는 두 페이지에서는 가장 중요하고 가장 유용한 타이밍 제약인 클록 주기 제약(period constraint)을 다룹니다. 그 중요성 때문에, 이 두 페이지에는 타이밍 리포트에 대한 자세한 논의도 포함됩니다.
그다음 두 페이지에서는 타이밍 클로저를 다룹니다. 이 주제를 지금 다루기에는 조금 이른 감이 있을 수 있습니다. 하지만 이 내용이 뒤에 이어질 주제들의 목적을 설명해 줍니다. 뒤이어 로직 패브릭(logic fabric)과 관련된 다섯 페이지 분량의 타이밍 제약(SDC 문법)이 나옵니다. 그 뒤에는 I/O 타이밍 제약에 관한 두 페이지가 이어집니다.
이 시리즈의 마지막 페이지는 기존 설계를 점검하는 내용입니다. 그 페이지에는 새로운 내용이 없습니다. 이미 논의한 주제를 반복할 뿐이며, 다만 이번에는 점검해야 할 항목들의 목록으로 제시됩니다.
주제들은 처음부터 끝까지 이 페이지 시리즈를 읽을 수 있는 순서로 배치되어 있습니다. 하지만 모든 주제가 서로 관련되어 있어 페이지 사이의 참조도 많습니다.
여기에서 계속 읽기에 가장 좋은 곳은 다음 페이지입니다. 타이밍 이론을 살펴보는 것은 결코 나쁠 것이 없습니다.