Microsemi 인서킷 FPGA 디버그

제품 정보

명세서

• 장치 유형: Microsemi SmartFusion2 SoC FPGA
• 출시일: 2014년 XNUMX월
• 디버깅 기능: 회로 내 FPGA 디버그, 임베디드 로직 분석기
• 최대 데이터 캡처 주파수: 최대 100MHz

추상적인
FPGA는 많은 설계상의 이점을 제공하는 임베디드 시스템의 강력한 설계 요소입니다.tag하지만 이러한 장치는 복잡한 설계를 가지고 있어 디버깅이 필요한 복잡한 설계 문제가 발생할 수 있습니다. 정의 오류, 시스템 상호작용 문제, 시스템 타이밍 오류와 같은 설계 문제를 추적하는 것은 어려울 수 있습니다. FPGA에 인서킷 디버그 기능을 포함하면 하드웨어 디버깅을 획기적으로 개선하고 수많은 시간 동안 발생하는 좌절을 피할 수 있습니다. 본 논문에서는 FPGA의 인서킷 디버그에 대한 여러 가지 접근 방식을 설명하고, 주요 장단점을 파악하며, 예시를 통해ampMicrosemi SmartFusion®2 SoC FPGA 장치를 대상으로 한 디자인은 새로운 기능을 사용하여 디버깅 및 테스트 속도를 높이는 방법을 보여줍니다.

소개

FPGA는 널리 보급되고 강력한 설계 요소이며 현재 거의 모든 임베디드 시스템에서 찾아볼 수 있습니다. 용량이 증가하고 복잡한 온칩 기능 블록과 고급 직렬 인터페이스가 포함됨에 따라 이러한 디바이스는 디버깅이 필요한 복잡한 설계 문제도 가질 수 있습니다. 기능 정의 오류(FPGA 또는 시스템 레벨), 기능 시스템 상호 작용 문제, 시스템 타이밍 문제, IC 간 신호 충실도 문제(노이즈, 크로스토크 또는 반사 등)와 같은 문제를 추적하는 것은 고급 FPGA를 사용할 때 훨씬 더 복잡해집니다. 시뮬레이션은 확실히 많은 설계 문제를 식별하는 데 큰 도움이 되지만 많은 실제 상호 작용은 설계가 하드웨어에 구현될 때까지 나타나지 않습니다. 복잡한 설계 문제를 디버깅하기 위한 여러 가지 기술이 프로세스를 단순화하기 위해 개발되었습니다. 다양한 장점을 포함하여 이러한 핵심 기술 각각에 대한 신중한 이해tages와 단점tag즉, 특정 디자인에 어떤 기술이나 기술 조합이 적합한지 고려할 때 유용합니다.
전ampMicrosemi SmartFusion2 SoC FPGA 장치를 대상으로 하는 FPGA 설계는 일부 장점을 시연하는 데 사용될 수 있습니다.tages와 단점tag이러한 표준 기술과 최신 인서킷 디버그 기능의 es. 이 설명적인 examp이 글에서는 다양한 기술을 사용하여 하드웨어 디버그 중에 하드웨어 문제를 빠르게 식별하고 제거하는 방법을 보여드리겠습니다.

FPGA 디버깅이 시스템 설계 및 개발의 중요한 측면인 이유는 무엇입니까?
FPGA는 다른 설계 요소와 차별화되는 두 가지 주요 사용 모델을 가지고 있습니다. FPGA는 생산 제품에 사용되거나 생산 설계 개념을 증명하거나 프로토타입을 만드는 개발 도구로 사용될 수 있습니다. 생산 도구로 사용될 때 FPGA는 ASIC 또는 CPU 기반 생산 도구보다 훨씬 더 유연한 대상이 될 수 있습니다. 이는 아직 하드웨어에 구현되지 않은 새로운 설계에 특히 중요합니다. 다양한 아키텍처 옵션이 있는 설계를 쉽게 만들고 테스트하여 최적의 설계를 식별할 수 있습니다. 온칩 프로세서(SoC FPGA)가 있는 FPGA는 CPU 기반 처리와 하드웨어 지원 FPGA 기반 가속 기능을 절충할 수도 있습니다. 이러한 이점은tag이를 통해 신제품 개발을 위한 설계, 검증, 테스트 및 실패 분석에 필요한 시간을 획기적으로 줄일 수 있습니다.
설계 프로토타입을 만드는 데 사용될 때, 아마도 생산 ASIC의 경우, FPGA 유연성은 핵심적인 이점입니다. 최대 속도로 실행되지 않는 실제 하드웨어 플랫폼이라도 자세한 시스템 성능 지표, 처리량 분석 데이터 및 아키텍처 개념 증명 결과를 얻는 것이 훨씬 더 쉽습니다. 산업 표준 버스(예: PCIe®, 기가비트 이더넷, XAUI, USB, CAN 등)의 강화된 구현을 위한 FPGA 지원은 이러한 인터페이스와 관련된 테스트를 간소화합니다. 온칩 ARM 프로세서(SoC FPGA)가 있는 최신 FPGA 제품군은 임베디드 프로세서를 사용하여 구현을 프로토타입으로 만드는 것을 쉽게 만듭니다. 이전에 개발된 프로세서 코드를 프로토타입으로 이식할 수 있으며 하드웨어 설계 작업과 병행하여 새 코드를 생성할 수 있습니다.

표준 프로세서와 표준 인터페이스 버스의 이러한 조합은 사용 가능한 코드 라이브러리, 드라이버, 기능적 API, 실시간 운영 체제, 심지어 전체 운영 체제의 방대한 생태계를 활용하여 훨씬 더 빠르게 작동하는 프로토타입을 만들 수 있습니다. 또한 설계가 확정되면 FPGA 프로토타입을 사용하여 실제 시스템 데이터를 반영하는 광범위한 시뮬레이션 테스트 세트(자극 및 응답 모두)를 캡처할 수 있습니다. 이러한 데이터 세트는 ASIC 또는 기타 프로덕션 구현을 위한 최종 시뮬레이션을 만드는 데 매우 귀중할 수 있습니다. 이점tagFPGA를 설계 프로토타입으로 사용하면 최종 제품 구현에 필요한 설계, 검증, 테스트 및 고장 분석 시간을 획기적으로 줄일 수 있습니다.
이 두 가지 일반적인 FPGA 사용 모델 모두에서 설계 대상으로서 FPGA의 유연성은 핵심적인 장점입니다.tage. 즉, ​​많은 디자인 변경과 반복이 표준이 될 것이고, 따라서 가능한 한 많은 디자인 옵션을 활성화하는 데 디자인 오류를 빠르게 디버깅하는 기능이 중요할 것입니다. 효율적인 디버깅 기능 없이는 많은 이점이 있습니다.tagFPGA 설계의 유연성은 필요한 추가 디버깅 시간으로 인해 감소합니다. 다행히도 FPGA는 실시간 디버깅을 극적으로 단순화하는 추가 하드웨어 기능도 제공할 수 있습니다. 이러한 기능을 살펴보기 전에 먼저 FPGA 설계가 직면할 수 있는 가장 일반적인 유형의 문제를 살펴보겠습니다. 그러면 다양한 디버깅 도구의 효율성과 관련된 상충 관계를 평가할 적절한 배경을 갖게 됩니다.

FPGA 설계 디버깅 시 일반적인 문제

최신 FPGA가 제공하는 확장된 기능과 더불어, 이와 관련된 복잡성 증가는 오류 없는 설계를 더욱 어렵게 만듭니다. 실제로 디버깅이 임베디드 시스템 설계 주기의 50% 이상을 차지하는 것으로 추산됩니다. 출시 기간 단축의 압박이 개발 주기를 계속해서 압박함에 따라, 초기 시스템의 하드웨어 디버깅은 부차적인 문제로 전락하고 있습니다. 검증(그 자체로 상당한 비중을 차지함)이 개발 주기의 중요한 부분을 차지한다고 생각하는 경우가 너무 많습니다.tag개발 일정의 e)는 초기 시스템 가동 전에 모든 버그를 포착합니다. 초기 시스템 가동 중에 일반적인 설계가 직면하게 될 과제를 더 잘 이해하기 위해 몇 가지 일반적인 유형의 시스템 문제를 살펴보겠습니다.

기능 정의 오류는 설계자가 특정 요구 사항을 오해했기 때문에 찾기가 두 배나 어려울 수 있으므로 설계 세부 사항을 주의 깊게 살펴보더라도 오류를 간과할 수 있습니다.amp일반적인 기능 정의 오류의 한 가지 예는 상태 머신 전환이 올바른 상태로 끝나지 않는 경우입니다. 오류는 시스템 인터페이스에서 상호 작용 문제로 나타날 수도 있습니다. 예를 들어 인터페이스 지연ample가 잘못 지정되어 예상치 못한 버퍼 오버플로 또는 언더플로 상황이 발생할 수 있습니다.
시스템 레벨 타이밍 문제는 또 다른 매우 일반적인 설계 오류의 원천입니다. 특히 비동기 이벤트는 동기화 또는 교차 타이밍 도메인 효과가 신중하게 고려되지 않을 때 발생하는 일반적인 오류 원천입니다. 빠른 속도로 작동할 때 이러한 유형의 오류는 매우 문제가 될 수 있으며 매우 드물게 나타날 수 있으며, 아마도 특정 데이터 패턴이 나타날 때만 나타날 수 있습니다. 많은 일반적인 타이밍 위반이 이 범주에 속하며 일반적으로 시뮬레이션하기가 매우 어렵거나 불가능합니다.

타이밍 위반은 또한 집적 회로 간의 낮은 신호 충실도의 결과일 수 있으며, 특히 각 회로에 여러 전원 레일이 있는 시스템에서 그렇습니다. 낮은 신호 충실도는 신호 노이즈, 크로스토크, 반사, 과도한 부하 및 전자기 간섭(EMI) 문제를 초래할 수 있으며, 이는 종종 타이밍 위반으로 나타납니다. 과도 전류(특히 시스템 시작 또는 종료 시), 부하 변동 및 높은 전력 소모 응력과 같은 전원 공급 장치 문제는 종종 전원 공급 장치로 쉽게 추적되지 않는 신비한 오류를 초래할 수 있습니다. 설계가 완전히 올바른 경우에도 보드 제작 문제로 인해 오류가 발생할 수 있습니다. 예를 들어, 잘못된 솔더 조인트 및 부적절하게 부착된 커넥터ample는 오류의 근원이 될 수 있으며 온도나 보드 위치에 따라 달라질 수도 있습니다. 고급 FPGA 패키징 기술을 사용하면 인쇄 회로 기판의 신호를 프로브하기 어려울 수 있으므로 원하는 신호에 액세스하는 것만으로도 종종 문제가 될 수 있습니다. 종종 많은 설계 문제는 즉각적인 오류를 생성하지 않고 오류가 실제로 나타날 때까지 설계 전체에 영향을 미칩니다. 시작 오류를 근본 원인으로 추적하는 것은 종종 좌절스럽고 어렵고 시간이 많이 걸리는 작업이 될 수 있습니다.

예를 들어amp변환 표에서 단 하나의 비트만 잘못되어도 여러 사이클이 지나야 오류가 발생할 수 있습니다. 이 논문의 뒷부분에서 다룰 일부 도구는 전용 회로 내 디버깅 하드웨어를 사용하며, 이러한 '버그 헌팅'을 더욱 빠르고 쉽게 만드는 데 중점을 두고 있습니다. 이러한 도구에 대해 자세히 살펴보기 전에, 먼저 널리 사용되는 소프트웨어 기반 디버깅 기술 시뮬레이션을 살펴보겠습니다. 이를 통해 이 기술의 장점을 더 잘 이해할 수 있습니다.tages와 단점tag디버깅을 위해 시뮬레이션을 사용하는 방법.

디버깅을 위한 시뮬레이션 사용
일반적으로 설계 시뮬레이션에서 설계 내부 및 외부의 모든 실제 구성 요소는 표준 CPU에서 순차적으로 실행되는 소프트웨어 프로세스로 수학적으로 모델링됩니다. 설계에 광범위한 자극을 적용하고 예상 출력을 시뮬레이션된 설계 출력과 비교하는 것은 가장 명백한 설계 오류를 포착하는 쉬운 방법입니다. 일반적인 시뮬레이션 실행을 보여주는 창은 아래 그림 1에 나와 있습니다. 명확한 이점tag시뮬레이션과 하드웨어 기반 디버깅의 차이점은 시뮬레이션은 소프트웨어에서 수행할 수 있다는 것입니다. 실제 하드웨어 기반 설계나 테스트벤치가 필요하지 않습니다. 시뮬레이션은 많은 설계 오류, 특히 잘못된 사양, 인터페이스 요구 사항 오해, 기능 오류, 그리고 간단한 자극 벡터를 통해 쉽게 감지되는 기타 여러 '심각한' 유형의 오류를 신속하게 포착할 수 있습니다.

시뮬레이션은 설계자가 광범위한 자극 조합을 사용할 수 있고 결과 출력이 잘 알려져 있을 때 특히 효과적입니다. 이러한 경우 시뮬레이션을 통해 설계를 거의 완벽하게 테스트할 수 있습니다. 하지만 대부분의 설계는 광범위한 테스트 스위트에 쉽게 접근할 수 없으며, 테스트 스위트를 만드는 과정에는 매우 많은 시간이 소요될 수 있습니다. 대규모 FPGA 기반 설계의 경우 설계의 100%를 포괄하는 테스트 스위트를 만드는 것은 사실상 불가능하며, 설계의 핵심 요소를 포괄하기 위해 지름길을 사용해야 합니다. 시뮬레이션의 또 다른 어려움은 '실제' 구현이 아니기 때문에 비동기 이벤트, 고속 시스템 상호 작용 또는 타이밍 위반을 포착할 수 없다는 것입니다. 마지막으로, 시뮬레이션 프로세스는 매우 느릴 수 있으며, 반복 횟수가 많을 경우 시뮬레이션은 개발 프로세스에서 가장 시간이 많이 소요되고 비용이 가장 많이 드는 부분이 됩니다.

대안으로(또는 더 나은 표현으로 시뮬레이션에 추가) FPGA 설계자는 FPGA 설계에 디버그 하드웨어를 추가하여 장치 내의 주요 신호를 관찰하고 제어할 수 있다는 것을 알게 되었습니다. 이러한 기술은 원래 임시 접근 방식으로 개발되었지만 점차 표준 하드웨어 디버그 전략으로 발전했습니다. 회로 내 디버그 기능을 사용하면 상당한 이점이 있습니다.tagFPGA 기반 설계를 위한 es와 다음 섹션에서는 가장 일반적인 세 ​​가지 전략과 다양한 이점을 살펴보겠습니다.tages와 단점tag에스.

FPGA를 위한 일반적인 인서킷 디버그 접근 방식
FPGA에서 인서킷 디버그 기능을 구현하는 가장 일반적인 기술은 임베디드 로직 분석기, 외부 테스트 장비 또는 FPGA 패브릭 내에 임베디드된 전용 신호 프로브 하드웨어를 사용합니다. 임베디드 로직 분석기는 일반적으로 FPGA 패브릭을 사용하여 구현되고 설계에 삽입됩니다. JTAG 포트는 분석기에 액세스하는 데 사용되고 캡처된 데이터는 PC에 표시할 수 있습니다. 외부 테스트 장비를 사용하는 경우 테스트 중인 FPGA 설계가 수정되어 선택된 내부 FPGA 신호가 출력 핀으로 라우팅됩니다. 그런 다음 이러한 핀을 외부 테스트 장비를 통해 관찰할 수 있습니다. 전용 신호 프로브 하드웨어를 사용하는 경우 광범위한 내부 신호를 실시간으로 읽을 수 있습니다. 일부 프로브 구현은 레지스터 또는 메모리 위치에 쓰는 데 사용되어 디버그 기능을 더욱 향상시킬 수도 있습니다. 이점을 더 자세히 살펴보겠습니다.tages와 단점tag이러한 각 기술의 es를 살펴본 다음 ex를 살펴보세요.amp다양한 접근 방식이 전체 디버깅 시간에 어떤 영향을 미치는지 살펴보기 위해 디자인을 진행했습니다.

인서킷 FPGA 디버그 임베디드 로직 분석기
임베디드 로직 분석기의 개념은 FPGA가 처음 사용되었을 때 설계자가 구현한 임시 인서킷 디버깅 기능의 직접적인 결과였습니다. 임베디드 로직 분석기는 새로운 기능을 추가하고 설계자가 자체 분석기를 개발할 필요성을 없앴습니다. 대부분의 FPGA는 이러한 기능을 제공하고 타사는 표준 분석기를 제공합니다(Synopsys의 Identify®는 인기 있는 예 중 하나입니다.amp생산성을 더욱 향상시키기 위해 상위 레벨 도구와 쉽게 인터페이스할 수 있는 도구입니다.

로직 분석기 기능은 그림 2에 나와 있듯이 FPGA 패브릭과 임베디드 메모리 블록을 트레이스 버퍼로 사용하여 설계에 삽입됩니다. 트리거링 리소스도 생성되어 복잡한 신호 상호 작용을 쉽게 선택하고 캡처할 수 있습니다. 제어 및 데이터 전송을 위한 분석기에 대한 액세스는 일반적으로 표준 J를 통해 수행됩니다.TAG 인터페이스 요구 사항을 단순화하기 위한 포트. 캡처된 데이터는 일반적인 PC를 사용하여 표시할 수 있습니다. view소프트웨어를 사용하고 일반적으로 로직 시뮬레이터 파형 출력을 미러링합니다. view스타일을 적용합니다.

이점tag이 접근 방식의 장점은 추가 FPGA I/O 핀이 사용되지 않고 표준 J만 사용된다는 것입니다.TAG 신호. 임베디드 로직 분석기 IP 코어는 일반적으로 비교적 저렴하며 어떤 경우에는 기존 FPGA 합성 또는 시뮬레이션 도구에 대한 옵션이 될 수 있습니다. 어떤 경우에는 임베디드 로직 분석기가 더 편리하다면 사용되지 않는 I/O에 추가 출력을 제공할 수도 있습니다. 단점 중 하나tag이 접근 방식의 단점은 많은 양의 FPGA 리소스가 필요하다는 것입니다. 특히 트레이스 버퍼를 사용하면 사용 가능한 블록 메모리 수가 감소합니다. 넓은 버퍼가 필요한 경우, 이는 메모리 깊이와 상충되는 결과를 초래합니다(넓은 메모리를 사용하면 메모리 깊이가 얕아지기 때문입니다). 이는 큰 단점입니다.tage 더 작은 장치를 사용할 때. 아마도 이 기술의 가장 큰 단점은 프로브 배치를 조정할 때마다 설계를 다시 컴파일하고 다시 프로그래밍해야 한다는 것입니다. 대형 장치를 사용할 때 이 프로세스는 상당한 시간이 걸릴 수 있습니다. 설계에 신호 프로브를 배치하는 방식으로 인해 신호 타이밍 관계를 상관시키기 어려울 수 있습니다. 또한 신호 프로브 간의 지연이 일관되지 않아 타이밍 관계를 비교하기 어렵습니다. 이는 비동기 신호나 다른 시간 영역의 신호를 비교할 때 특히 어렵습니다.

인서킷 FPGA 디버그 – 외부 테스트 장비
외부 테스트 장비와 함께 인서킷 디버그 코드를 사용하는 것은 시스템 테스트를 위해 외부 로직 분석기를 이미 사용할 수 있을 때 자연스러운 발전이었습니다. 그림 3과 같이 내부 테스트 신호를 식별하고 선택하여 FPGA I/O에 적용하는 간단한 디버그 코드를 생성함으로써 분석기의 고급 기능(예: 대형 트레이스 버퍼, 복잡한 트리거링 시퀀스, 다중 viewing 옵션)을 사용하여 간단하면서도 강력한 디버그 환경을 만듭니다. 고급 트리거링 옵션을 위한 더 복잡한 회로 내 기능은 필요한 출력 수를 최소화할 수 있습니다. 예를 들어amp따라서 외부 핀이 필요한 경우 넓은 버스에서 특정 주소를 선택하는 것은 금지될 수 있습니다.
내부 FPGA 로직을 사용하면 I/O 요구 사항이 크게 줄어들고 더 복잡한 문제를 디버깅하기 위해 특정 주소 패턴(아마도 호출 및 반환 시퀀스)을 찾을 수도 있습니다. 공통 사용자 인터페이스가 사용 가능한 경우 학습 곡선을 간소화하고 생산성을 향상시킬 수 있습니다.

이점tag이 접근 방식의 장점은 외부 테스트 장비의 비용을 활용하므로 추가 도구 비용이 없다는 것입니다. 일부 디버그 회로 IP 코어는 장비 제조업체 또는 FPGA 제조업체에서 구입할 수 있으며 비용이 매우 낮거나 무료일 수도 있습니다. 신호 선택 논리를 구현하는 데 필요한 FPGA 리소스의 양은 매우 적고, 추적 기능은 외부 논리 분석기를 사용하여 수행되므로 블록 메모리가 필요하지 않습니다. 선택 논리는 저렴하므로 광범위한 트리거링이 있는 많은 수의 채널도 지원할 수 있습니다. 논리 분석기는 타이밍 모드와 상태 모드에서 모두 작동할 수 있어 일부 타이밍 문제를 격리하는 데 도움이 됩니다.
단점tag이 접근 방식의 단점에는 프로젝트에 이미 할당되지 않은 경우 논리 분석기를 구매해야 할 필요성이 포함될 수 있습니다. 이 단점은tage는 많은 경우 이 접근 방식을 단념시키기에 충분할 수 있습니다. 그러나 PC나 태블릿을 디스플레이에 사용하는 일부 저가 로직 분석기 옵션이 출시되고 있어 간단한 디버그 요구 사항에 이 옵션이 훨씬 더 비용 효율적이라는 점에 유의하세요.
소모되는 FPGA 핀의 수는 또 다른 단점이 될 수 있습니다.tage 그리고 넓은 버스를 관찰해야 하는 경우 보드 레이아웃에 대한 상당한 계획과 디버그 커넥터 추가가 필요합니다. 이 요구 사항은 대부분 설계 단계 초기에 예측하기 어렵고 또 다른 원치 않는 복잡성입니다. 임베디드 로직 분석기 접근 방식과 유사하게 외부 테스트 전략은 새로운 실험이 필요할 때마다 설계를 다시 컴파일하고 다시 프로그래밍해야 합니다.

일반적인 단점tag이 두 가지 기술의 단점은 다음과 같습니다. 온칩 리소스 사용(설계의 타이밍 성능에 영향을 미치고 추가적인 디버깅 요구 사항을 발생시킬 수 있음), 설계 재컴파일 및 재프로그래밍 필요성(디버그 일정에 몇 시간 또는 며칠이 추가될 수 있음), 발생 가능한 테스트 시나리오를 파악하기 위한 사전 계획, 그리고 추가적인 칩 I/O 리소스 사용은 이러한 단점을 해결해야 하는 접근 방식의 필요성을 야기했습니다. 한 가지 해결책은 일부 장치의 FPGA 패브릭에 전용 디버그 로직을 추가하는 것이었습니다. 그 결과, 하드웨어 프로브를 사용한 인서킷 디버그가 탄생했습니다.

인서킷 FPGA 디버그 – 하드웨어 프로브
하드웨어 프로브를 사용하면 FPGA의 인서킷 디버그 기술이 극적으로 간소화됩니다. SmartFusion2®SoC FPGA 및 IGLOO®2 FPGA 디바이스에서 라이브 프로브 기능으로 구현된 이 기술은 FPGA 패브릭에 전용 프로브 라인을 추가하여 모든 논리 요소 레지스터 비트의 출력을 관찰합니다. 그림 4의 블록 다이어그램에 표시된 대로 하드웨어 프로브는 두 개의 프로브 채널 A와 B에서 사용할 수 있습니다.

그림 하단에 소스된 것과 같은 선택된 레지스터 출력(프로브 포인트)은 두 프로브 채널 위로 라우팅되고, 선택된 경우 A 또는 B 채널에 적용될 수 있습니다. 이러한 실시간 채널 신호는 장치의 전용 프로브 A 및 프로브 B 핀으로 전송될 수 있습니다. 프로브 A 및 프로브 B 신호는 내장된 로직 분석기로 내부적으로 라우팅될 수도 있습니다.

프로브 핀의 타이밍 특성은 규칙적이며 프로브 지점 간에 무시할 수 있는 편차가 있어 실시간 신호의 타이밍 특성을 비교하기가 훨씬 쉽습니다. 최대 100MHz에서 데이터를 캡처할 수 있으므로 대부분의 대상 설계에 적합합니다.
아마도 가장 중요한 것은 프로브 포인트 위치가 구현된 설계의 일부로 선택되지 않기 때문에(설계가 FPGA에서 실행되는 동안 전용 하드웨어를 통해 선택됨) 선택 데이터를 장치에 보내기만 하면 빠르게 변경할 수 있다는 것입니다. 설계 재컴파일 및 재프로그래밍이 필요하지 않습니다.
Live Probe 기능의 사용을 더욱 단순화하기 위해 관련 디버그 소프트웨어 도구는 자동 생성된 디버그를 통해 모든 프로브 신호 위치에 액세스할 수 있습니다. file. 그림 5에서 보듯이, 신호 이름은 신호 목록에서 선택하여 원하는 채널에 적용할 수 있습니다. 이는 설계가 실행 중일 때도 수행할 수 있으므로 설계 내에서의 프로빙 활동이 원활하고 매우 효율적입니다.

많은 경우, 라이브 프로브와 같은 하드웨어 프로브 기능은 이전에 설명한 임베디드 로직 분석기 및 외부 테스트 기술과 함께 사용할 수 있습니다.

그림 6에서 볼 수 있듯이, 라이브 프로브(Live Probe) 기능을 사용하면 신호를 '즉시' 선택할 수 있어 설계를 다시 컴파일하지 않고도 관찰 대상 신호를 빠르고 쉽게 변경할 수 있습니다. 그림 오른쪽 상단의 전용 프로브 출력 핀에서 볼 수 있듯이, 외부 로직 분석기나 스코프를 사용하여 프로브 신호를 쉽게 관찰할 수 있습니다. 또는 내부 로직 분석기(그림에 표시된 ILA Identify 블록)를 사용하여 프로브 핀을 관찰할 수도 있습니다. ILA는 프로브 신호를 캡처하여 파형 창에서 관찰할 수 있습니다. 프로브 위치는 대상 설계를 다시 컴파일하지 않고도 변경할 수 있습니다.
트리거 및 추적을 위한 추가 기능을 사용하면 프로브 기능을 향상시켜 복잡한 설계 문제도 쉽게 찾을 수 있습니다.

SmartFusion2 SoC FPGA 및 IGLOO2 FPGA 디바이스에서는 추가적인 하드웨어 디버깅 기능도 사용할 수 있습니다. 이러한 기능 중 하나인 액티브 프로브(Active Probe)는 모든 논리 요소 레지스터 비트에 동적으로 비동기적으로 읽고 쓸 수 있습니다. 기록된 값은 단일 클럭 사이클 동안 유지되므로 정상적인 작동을 계속할 수 있어 매우 유용한 디버깅 도구입니다. 액티브 프로브는 내부 신호를 빠르게 관찰해야 하는 경우(예: 리셋 신호처럼 신호가 활성화되어 있거나 원하는 상태인지 확인하기 위해) 또는 프로브 포인트에 데이터를 기록하여 논리 함수를 빠르게 테스트해야 하는 경우에 특히 유용합니다.
(아마도 제어 흐름 문제를 분리하기 위해 입력 값을 빠르게 설정하여 상태 머신 전환을 시작하기 위함일 수 있음).

Microsemi에서 제공하는 또 다른 디버그 기능은 메모리 디버그입니다. 이 기능을 사용하면 설계자가 선택한 FPGA 패브릭 SRAM 블록을 동적으로 비동기적으로 읽거나 쓸 수 있습니다. 디버그 도구(그림 7)의 화면 샷에서 볼 수 있듯이 메모리 블록 탭을 선택하면 사용자가 읽을 원하는 메모리를 선택하고 메모리의 스냅샷 캡처를 실행하고 메모리 값을 수정한 다음 값을 다시 장치에 쓸 수 있습니다. 이는 특히 계산 지향 스크래치 패드 또는 임베디드 CPU에서 실행하는 코드에 사용되는 통신 포트에서 사용되는 데이터 버퍼를 확인하거나 설정하는 데 유용할 수 있습니다. 메모리를 매우 빠르게 관찰하고 제어할 수 있으면 복잡한 데이터 종속 오류를 디버깅하는 것이 훨씬 빠르고 쉽습니다.

설계가 디버깅되면 민감한 정보를 보호하기 위해 하드웨어 디버깅 기능을 끄는 것이 좋습니다. 공격자는 이와 동일한 기능을 사용하여 중요한 정보를 읽거나 시스템의 민감한 부분에 쉽게 액세스할 수 있는 시스템 설정을 변경할 수 있습니다. Microsemi는 디버깅이 완료된 후 설계자가 장치를 보호할 수 있도록 기능을 추가했습니다. 예를 들어ample, Live Probe 및 Active Probe에 대한 액세스를 잠가 공격 수단으로 사용할 수 있는 기능을 완전히 비활성화할 수 있습니다(프로브 활동이 공급 전류에서 패턴을 생성하여 간접적으로 프로브 데이터를 관찰하는 데 사용될 가능성도 없앱니다). 또는 설계의 선택된 부분에 대한 액세스를 잠가 해당 섹션에만 액세스하지 못하도록 할 수 있습니다. 설계의 일부만 보안하면 되고 나머지 설계는 현장 테스트 또는 오류 분석을 위해 여전히 액세스할 수 있는 경우 이 방법이 편리할 수 있습니다.

회로 내 디버그 비교 차트
이제 자세한 내용을 다시view 8가지 주요 인서킷 하드웨어 디버그 기술 중 하나를 설명했으며 그림 XNUMX에 표시된 것처럼 다양한 장점을 자세히 설명하는 요약 차트가 작성되었습니다.tages와 단점tag각 방법의 es. 일부 기술은 함께 사용할 수 있다는 점을 기억하세요(예: Live Probe 및 Synopsys Identify와 같은 내부 논리 분석기(ILA)).amp각 기법의 주요 강점과 약점을 확인할 수 있습니다. 회로 내 하드웨어 디버깅 기능(라이브 프로브, 액티브 프로브, 메모리 디버그 - 통칭하여 스마트디버그)은 사용 가능한 총 프로브 수(빨간색 원) 측면에서 다른 기법들에 비해 가장 취약하며, 캡처 속도(외부 테스트 장비가 더 빠를 수 있음) 측면에서는 가장 우수한 기법(노란색 원)보다 더 취약합니다.
Synopsys Identify와 같은 ILA 기반 기술은 다른 기술과 비교했을 때 가장 약하고 FPGA 리소스 요구 사항을 고려할 때 가장 약합니다. 외부 테스트 장비 기반 기술은 비용, 설계 타이밍 영향, 프로브 이동 오버헤드(설계를 다시 컴파일해야 하기 때문에)가 가장 부담스러운 여러 고려 사항에서 가장 약합니다. 아마도 최적의 솔루션은 SmartDebug와 다른 기술 중 하나를 결합하여 SmartDebug의 채널 수 약점을 완화하고 프로브 포인트 이동 단점을 개선하는 것입니다.tag다른 기술의 효과도 감소했습니다.

신호 분류
가장 일반적인 신호 유형 중 일부 사이에 유용한 구별을 할 수 있으며 이는 디버깅 접근 방식을 계획할 때 도움이 될 수 있습니다. 예를 들어amp시스템 리셋, 블록 리셋, 초기화 레지스터와 같이 시스템 시작 시 외에는 변경되지 않는 신호는 정적 신호로 분류할 수 있습니다. 이러한 유형의 신호는 긴 재컴파일 주기 없이 신호를 쉽게 관찰하고 제어할 수 있는 기능을 통해 가장 효율적으로 액세스할 수 있습니다. 액티브 프로브(Active Probe)는 정적 신호 디버깅에 매우 유용한 기능입니다. 마찬가지로, 더 자주 변경되지만 대부분의 시간 동안 정적인 신호는 의사 정적 신호로 분류할 수 있으며 액티브 프로브를 사용하여 가장 효과적으로 디버깅할 수 있습니다. 클럭 신호와 같이 자주 변경되는 신호는 동적 신호로 분류할 수 있으며 액티브 프로브를 통해 쉽게 액세스할 수 없습니다. 라이브 프로브(Live Probe)는 이러한 신호를 관찰하는 데 더 적합한 선택입니다.

간단한 디버그 사용 사례

이제 다양한 회로 내 디버그 옵션에 대해 더 잘 이해했으므로 간단한 설계 예를 살펴보겠습니다.amp이러한 기술이 어떻게 수행되는지 보려면 le를 참조하십시오.그림 9는 SmartFusion2 SoC FPGA 디바이스의 간단한 FPGA 설계를 보여줍니다.마이크로컨트롤러 서브시스템(MSS)은 CoreSF2Reset Soft IP 블록에 의해 재설정됩니다.이 블록의 입력은 Power On Reset, User Fabric Reset 및 External Reset입니다.출력은 User Fabric에 대한 재설정, MSS 재설정 및 M3 재설정입니다.오류 증상은 디바이스가 POR 상태를 성공적으로 종료하더라도 I/O에서 활동이 없다는 것입니다.이 오류를 디버깅하는 세 가지 다른 옵션도 그림에 설명되어 있습니다.파란색 상자(ETE로 표시됨)는 외부 테스트 장비 방법을 위한 것입니다.녹색 상자(ILA로 표시됨)는 내부 로직 분석기 방법을 위한 것입니다.주황색 상자(AP로 표시됨)는 액티브 프로브 방법을 위한 것입니다.오류의 잠재적인 근본 원인은 CoreSF2Reset Soft IP 블록에 대한 잘못 어설션된 재설정 입력이라고 가정합니다.

이제 이전에 설명한 세 가지 인서킷 방법에 대한 디버그 프로세스를 살펴보겠습니다.

외부 테스트 장비
이 방법을 사용하면 테스트 장비가 사용 가능하고 더 높은 우선순위의 프로젝트에서 사용되지 않는다고 가정합니다. 또한 일부 FPGA I/O를 사용할 수 있고 테스트 장비에 쉽게 연결할 수 있도록 미리 계획하는 것이 중요합니다. 예를 들어 PCB에 헤더가 있는 경우ample는 매우 유용할 것이며, '유력한 용의자'를 식별하고 연결하거나 프로빙 중 핀 단락 가능성을 최소화하는 데 소요되는 시간을 최소화할 수 있습니다. 조사할 신호를 선택하기 위해 설계를 다시 컴파일해야 합니다. 초기 조사가 종종 더 많은 의문을 불러일으키기 때문에 '양파 껍질을 벗기는' 식으로 추가 조사를 위해 추가 신호를 선택하지 않기를 바랍니다. 어떤 경우든 재컴파일 및 재프로그래밍 프로세스는 상당한 시간이 소요될 수 있으며, 타이밍 위반이 발생하면 재설계가 필요합니다(특히 설계 버그를 찾기 위해 설계를 변경할 때 타이밍 클로저 문제를 해결하는 것이 얼마나 힘든지 잘 알고 있습니다. 전체 프로세스는 몇 분에서 몇 시간까지 걸릴 수 있습니다)! 설계에 사용 가능한 사용자 I/O가 없으면 이 방법을 구현할 수 없다는 점을 기억하는 것이 중요합니다. 더욱이 이 방법은 설계에 구조적으로 방해가 되며, 타이밍 관련 버그는 반복 작업 사이에 사라지거나 다시 나타날 수 있습니다.

내부 논리 분석기
이 방법을 사용하면 패브릭 리소스를 사용하여 ILA를 설계에 삽입한 다음 다시 컴파일해야 합니다. ILA가 이미 인스턴스화된 경우 조사하려는 신호가 계측되지 않았을 수 있으며, 이 경우에도 다시 컴파일해야 합니다. 이 프로세스는 원래 설계를 변경하고 타이밍 제약 조건을 위반할 위험이 있습니다. 타이밍이 충족되면 설계를 다시 프로그래밍하고 다시 초기화해야 합니다. 이 전체 프로세스는 다시 컴파일하는 데 시간이 오래 걸리고 여러 패스가 필요한 경우 몇 분 또는 몇 시간이 걸릴 수 있습니다. 이 접근 방식은 구조적으로 방해가 되며 위의 방법을 사용할 때 설명한 것과 유사한 문제가 발생할 수 있습니다.

액티브 프로브
이 방법을 사용하면 Active Probe를 다양한 재설정 신호의 소스로 지정할 수 있으며, 이 모든 신호는 레지스터 출력에서 ​​소싱됩니다(모든 우수한 디지털 설계 관행에서 일반적인 방식). 아래 그림 10에 표시된 Active Probe 메뉴에서 신호를 하나씩 선택합니다. 선택한 신호 값을 읽고 Active Probe 데이터 창에 표시합니다. 잘못된 주장은 쉽게 식별할 수 있습니다. 이 테스트는 장치를 다시 컴파일하고 다시 프로그래밍할 필요 없이 즉시 수행할 수 있으며 구조적으로나 절차적으로 방해가 되지 않습니다. 전체 프로세스는 몇 초 밖에 걸리지 않습니다. 이 방법은 다른 두 가지 방법에서는 허용하지 않는 제어 가능성(비동기적으로 값 변경)을 만들 수도 있습니다. 이 특정 예에서amp즉, 레지스터에서 생성된 재설정 신호는 쉽게 조사되어 활성 상태로 유지되는 것을 발견할 수 있습니다.

리셋 신호의 순간적인 토글은 레지스터를 비동기적으로 조작하여 나머지 신호를 생성함으로써 달성될 수 있습니다.

더 복잡한 디버그 사용 사례
위의 디자인은 매우 간단하며 설명된 디자인 기술을 사용하는 데 대한 소개로 유용하지만 더 복잡한 예입니다.ample는 더욱 설명적일 수 있습니다. 관심 신호는 우리의 단순한 ex에서처럼 정적 신호가 아닌 경우가 많습니다.ample는 동적이지만 동적입니다. 일반적인 동적 신호는 중간 클록으로, 아마도 직렬 인터페이스의 핸드셰이크 타이밍에 사용될 수 있습니다. 그림 11은 사용자 소프트 IP 코어가 있는 이러한 설계를 보여줍니다. 이 경우 사용자 정의 직렬 인터페이스가 시스템 APB 버스에 연결되었습니다. 오류 증상은 사용자 정의 직렬 인터페이스에 활동이 없고 APB 버스 마스터가 직렬 인터페이스에 액세스하기 위해 트랜잭션을 발행하면 잘못된 핸드셰이크를 나타내는 예외 조건이 발생한다는 것입니다. 이러한 조건은 트랜잭션 상태 머신이 예상 속도로 작동하지 않는 것처럼 보이고 따라서 예외를 발생시키기 때문에 잘못된 재설정 신호와 같은 정적 원인을 배제하는 것으로 보입니다. 근본 원인은 사용자 IP 코어 내의 클록 주파수 생성기인 것으로 생각됩니다.

올바른 주파수에서 실행되지 않으면 설명한 오류가 발생합니다.

이 상황에서는 Active Probe 접근 방식을 Live Probe로 대체하는 것이 더 나은 전략일 것입니다. 이는 위 그림에서 주황색 LP 상자로 J를 사용하여 설명됩니다.TAG 프로브 소스 선택을 위한 신호입니다.

외부 테스트 장비
이 경우 방법론은 이전에 설명한 간단한 예와 매우 유사합니다.ample. 사용자 클록 신호가 테스트 지점(바람직하게는 헤더에)으로 내보내지고 시간이 많이 걸리는 재컴파일이 필요합니다. 참조 신호, 아마도 비교 신호로 사용자 IP를 클록하는 데 사용되는 시스템 클록을 내보내는 것도 도움이 될 수 있습니다. 다시 한 번 재컴파일하고 재프로그래밍해야 하므로 전체 프로세스에 상당한 시간이 걸릴 수 있습니다.

내부 논리 분석기
이 사례는 간단한 ex와 매우 유사합니다.ample. ILA를 삽입하거나 원하는 신호를 정의하고 재컴파일 및 재프로그램 주기를 실행해야 합니다. 이전에 설명한 모든 문제는 여전히 상당한 디버그 주기 시간을 초래합니다. 그러나 추가적인 복잡성이 있습니다. ILA를 구동하는 클록은 동기식이어야 하며 이상적으로는 사용자 소프트 IP 코어에서 관찰되는 클록에 비해 훨씬 더 빨라야 합니다. 이러한 클록이 비동기식이거나 올바른 타이밍 관계가 없는 경우 데이터 캡처는 예측할 수 없으며 디버그 프로세스에 혼란을 줄 수 있는 원인이 될 수 있습니다.
사용자 소프트 IP 클록이 칩상에서 생성되지 않는 경우(아마도 직렬 인터페이스에서 복구되는 경우) 설계자는 추가 리소스를 사용하여 더 빠른 ILA 클록을 생성하는 클록 모듈을 추가해야 할 수도 있으며, 아마도 타이밍 위반이 발생할 수도 있습니다.

라이브 프로브
이 방법을 사용하면 Live Probe를 레지스터에서 사용자 클록 소스와 다른 클록 소스로 빠르게 가리켜 오류의 근본 원인을 추적할 수 있습니다. Live Probe는 선택한 신호 출력을 실시간으로 표시하므로 신호 간의 타이밍 관계를 훨씬 더 쉽게 확인할 수 있습니다. 전체 프로세스는 몇 초 밖에 걸리지 않습니다.

직렬 인터페이스에 대한 기타 디버그 기능
또한 SmartFusion2 SoC FPGA 및 IGLOO2 FPGA 장치에는 이전 예제와 같은 직렬 인터페이스에서 사용할 수 있는 많은 추가 디버그 기능이 있다는 점도 지적하는 것이 중요합니다.amp오류가 더욱 복잡한 le 디자인. 예를 들어 SERDES 디버그ample는 전용 고속 직렬 인터페이스에 대한 특정 디버그 기능을 제공합니다. SERDES 디버그 기능 중 일부에는 PMA 테스트 지원(PRBS 패턴 생성 및 루프백 테스트 등), 전체 설계 흐름을 사용하여 구성을 변경하지 않도록 하는 레지스터 수준 재구성을 통한 여러 SERDES 테스트 구성 지원, 구성된 프로토콜, SERDES 구성 레지스터 및 Lane 구성 레지스터를 보여주는 텍스트 보고서가 포함됩니다. 이러한 기능은 SERDES 디버그를 훨씬 더 쉽게 만들고 Live Probe 및 Active Probe와 함께 사용하여 복잡한 회로의 디버깅 속도를 더욱 높일 수 있습니다.
앞서 설명한 메모리 디버그 툴은 SERDES 디버그와 함께 사용하여 테스트 속도를 높일 수 있습니다. 메모리 디버그를 사용하면 메모리 버퍼를 빠르고 쉽게 검사하고 변경할 수 있으므로 '테스트 패킷'을 빠르게 생성하고 루프백 또는 시스템 간 통신 결과를 관찰할 수 있습니다. 설계자는 이러한 기능을 활용하여 추가 FPGA 패브릭을 소모하고 칩 타이밍에 영향을 미칠 수 있는 특수 '테스트 하네스'의 필요성을 최소화할 수 있습니다.

결론
본 논문에서는 FPGA 및 SoC FPGA의 인서킷 디버깅을 구현하는 여러 가지 접근 방식(통합 로직 분석기 사용, 외부 테스트 장비 사용, FPGA 패브릭에 통합된 전용 프로브 회로 사용)을 자세히 설명했습니다. Microsemi가 SmartFusion2 SoC FPGA 및 IGLOO2 FPGA 디바이스에 제공하는 액티브 프로브(Active Probe) 및 라이브 프로브(Live Probe)와 같은 특수 전용 프로브 회로를 추가하면 디버깅 프로세스가 크게 단축되고 간소화되는 것으로 나타났습니다. 내부 신호 선택을 신속하게 수정할 수 있는 기능(시간이 많이 소요되는 재컴파일 및 재프로그래밍 사이클을 실행할 필요 없음)과 내부 신호를 프로브할 수 있는 기능(FPGA 패브릭을 사용하거나 타이밍 위반을 유발할 필요 없음)이 주요 장점으로 나타났습니다.tagFPGA 설계를 디버깅할 때 es. 또한, 더욱 포괄적인 디버깅 기능을 제공하기 위해 함께 작동할 수 있는 여러 방법론의 사용이 설명되었습니다. 마지막으로, 두 가지 examp설명된 방법들 간의 상충관계를 설명하기 위해 디버그 사용 사례가 주어졌습니다.

더 알아보려면

1. IGLOO2 FPGA
2. SmartFusion2 SoC FPGA

Microsemi Corporation(Nasdaq: MSCC)은 통신, 방위 및 보안, 항공우주 및 산업 시장을 위한 포괄적인 반도체 및 시스템 솔루션 포트폴리오를 제공합니다. 제품에는 고성능 및 내방사선 아날로그 혼합 신호 집적 회로, FPGA, SoC 및 ASIC가 포함됩니다. 전력 관리 제품; 시간에 대한 세계 표준을 설정하는 타이밍 및 동기화 장치와 정확한 시간 솔루션; 음성 처리 장치; RF 솔루션; 이산 부품; 보안 기술 및 확장 가능한 안티 Tamper 제품, PoE(Power-over-Ethernet) IC 및 미드스팬, 그리고 맞춤형 설계 역량과 서비스를 제공합니다. Microsemi는 캘리포니아주 알리소 비에호에 본사를 두고 있으며 전 세계적으로 약 3,400명의 직원을 보유하고 있습니다. 자세한 내용은 다음에서 확인하세요. www.microsemi.com.

© 2014 마이크로세미 코퍼레이션. 판권 소유. Microsemi 및 Microsemi 로고는 Microsemi Corporation의 상표입니다. 기타 모든 상표 및 서비스 마크는 해당 소유자의 자산입니다.

마이크로세미 본사

• 하나 기업, Aliso Viejo CA 92656 USA
• 이내에 미국: +1 800-713-4113
• 밖의 미국: +1 949-380-6100
• 매상: +1 949-380-6136
• 팩스: +1 949-215-4996
• 이메일: sales.support@microsemi.com

자주 묻는 질문

• 질문: 이 장치의 최대 데이터 수집 빈도는 얼마입니까?
  답변: 이 장치는 최대 100MHz의 데이터 캡처를 지원하므로 대부분의 대상 설계에 적합합니다.
• 질문: 디버깅을 위해 프로브 회로를 사용할 때 설계를 다시 컴파일해야 합니까?
  A: 아니요. 설계를 다시 컴파일하거나 재프로그래밍하지 않고도 프로브 포인트 위치를 빠르게 변경할 수 있습니다.

문서 / 리소스

Microsemi 인서킷 FPGA 디버그 [PDF 파일] 지침 인서킷 FPGA 디버그, FPGA 디버그, 디버그

참고문헌

• 사용자 설명서