Verilog 또는 VHDL에서 로직(칩) 설계를 위한 TDD(Test Driven Development) 경험

StackOverflow https://stackoverflow.com/questions/1633559

문제

웹을 살펴보니 토론/예제가 전통적인 소프트웨어 개발에 관한 것 같습니다.Verilog 및 VHDL 이후(칩 설계에 사용됨, 예:FPGA 및 ASIC)은 소프트웨어 개발 C 및 C++와 유사하므로 의미가 있는 것 같습니다.그러나 근본적으로 병렬이고 완전한 테스트를 위해 하드웨어가 필요한 몇 가지 차이점이 있습니다.

당신은 좋은 경험과 나쁜 경험을 했나요?이 특정 애플리케이션에 대해 제안할 수 있는 링크가 있습니까?

편집/설명:2009년 10월 28일:특히 TDD에 대해 묻고 있습니다.나는 자체 점검을 포함하여 테스트 벤치를 수행하는 데 익숙합니다.또한 SystemVerilog에는 테스트 벤치를 위한 몇 가지 특정 기능이 있다는 것도 알고 있습니다.

2009년 10월 28일:암시된 질문에는 1) 시뮬레이션에 파형을 사용하지 않고 모든 기능에 대한 테스트를 작성하는 것과 2) 테스트/테스트벤치를 먼저 작성하는 것이 포함됩니다.

2009년 11월 29일:~ 안에 경험적 연구에 따르면 테스트 주도 개발이 품질을 향상시킵니다. (소프트웨어) TDD에 대해 보고합니다. "코드 천 줄당 결함으로 측정된 4개 제품의 출시 전 결함 밀도는 TDD를 사용하지 않은 프로젝트에 비해 40%~90% 감소했습니다.팀 경영진은 TDD를 사용하는 팀의 초기 개발 시간이 15~35% 증가했다고 주관적으로 보고했지만, 팀은 이것이 유지 관리 비용 절감으로 상쇄된다는 데 동의했습니다." 버그가 줄어들면 테이프 아웃 위험이 줄어듭니다. 중간 정도의 일정 영향. 이것 또한 일부 데이터가 있습니다.

2009년 11월 29일:저는 DSP 코드가 아닌 제어 및 데이터패스 코드를 주로 하고 있습니다.DSP의 경우 일반적인 솔루션에는 Matlab 비트 정확도 시뮬레이션이 포함됩니다.

10/03/02:TDD의 장점은 테스트가 먼저 실패하는지 확인하는 것입니다.나는 이것이 주장으로도 이루어질 수 있다고 생각합니다.

도움이 되었습니까?

해결책

저는 ASICS가 아닌 FPGA용 코드를 작성합니다...하지만 TDD는 여전히 내가 선호하는 접근 방식입니다.나는 내가 작성하는 모든 기능 코드에 대한 전체 테스트 모음을 갖고 싶어하며 (항상 성공적인 것은 아니지만) 테스트 코드를 먼저 작성하려고 노력합니다.디버깅 중 어느 시점에서 파형을 쳐다보는 것은 항상 발생하지만 코드를 검증하는 좋은 방법은 아닙니다(IMHO).

실제 하드웨어에서 적절한 테스트를 수행하는 것이 어렵고(특이한 경우를 자극하는 것은 특히 어렵습니다) VHDL 컴파일에 몇 초가 걸린다는 사실("하드웨어로" 컴파일하는 데는 몇 분(또는 몇 시간)이 소요됨)을 감안할 때 다른 사람이 어떻게 다른 방식으로 작업할 수 있는지 알 수 없습니다!

또한 나는 RTL을 작성할 때 절대 일어나지 말아야 할 일을 포착하기 위해 RTL에 단언문을 작성합니다.검증 엔지니어는 주장을 작성하고 RTL 설계자는 그렇지 않다는 인식이 있기 때문에 이것은 약간 "이상한" 것으로 보입니다.하지만 대부분은 검증 엔지니어이기 때문에 아마도 그게 이유일 것입니다!

다른 팁

나는 사용한다 V단위 VHDL을 사용한 테스트 중심 개발을 위한 것입니다.

VUnit은 VHDL 컴파일러와 시뮬레이터를 호출하고 시뮬레이션 결과를 읽는 Python 라이브러리입니다.또한 다음과 같은 더 나은 테스트 벤치를 훨씬 쉽게 작성할 수 있는 여러 가지 멋진 VHDL 라이브러리를 제공합니다. 커뮤니케이션 도서관, 로깅 라이브러리 그리고 라이브러리 확인.

Python에서 호출되기 때문에 많은 가능성이 있습니다.테스트 데이터를 생성하는 것뿐만 아니라 Python에서 테스트의 출력 데이터를 확인하는 것도 가능합니다.저번에 그들이 사용한 이 예를 봤습니다. Octave - Matlab 사본 - 테스트 결과 플롯용.

VUnit은 매우 활동적인 것 같아서 여러 번 실제로 개발자에게 직접 질문을 할 수 있었고 매우 빠르게 도움을 받을 수 있었습니다.

단점은 라이브러리에 동일한 이름을 가진 함수/프로시저 변형이 너무 많기 때문에 컴파일 오류를 디버깅하기가 더 어렵다는 것입니다.또한 일부 작업은 코드 전처리를 통해 백그라운드에서 수행되는데, 이는 일부 오류가 예상치 못한 위치에 나타날 수 있음을 의미합니다.

IEEE Verilog 표준에 대한 SystemVerilog 확장에는 복잡한 디지털 논리 설계를 확인하기위한 철저한 테스트 스위트를 작성하는 다양한 구성이 포함되어 있습니다.SystemVerilog는 시뮬레이션 (에뮬레이션 또는 FPGA 사용)을 통해 ASIC 칩 설계를 검증하는 데 사용되는 HVL (Hardware Verification Languages) 중 하나입니다.

기존 하드웨어 설계 언어(Verilog)에 비해 중요한 이점은 다음과 같습니다.

  • 제한된 무작위화
  • 주장
  • 기능 및 주장 적용 범위 데이터의 자동 수집

핵심은이 최근 (2005) 표준을 지원하는 시뮬레이션 소프트웨어에 액세스하는 것입니다.모든 시뮬레이터가보다 고급 기능을 완전히 지원하는 것은 아닙니다.

IEEE 표준 외에도 VMM Central에서 사용할 수있는 오픈 소스 시스템 Verilog 검증 구성 요소 라이브러리가 있습니다.http://www.vmmcentral.com).테스트 환경을 만들기 위한 합리적인 프레임워크를 제공합니다.

Verfication Guild Forum을 검색하여 주제에 대한 더 많은 연구를 할 수도 있습니다.

SystemVerilog는 유일한 HVL이 아니며 VMM은 유일한 라이브러리가 아닙니다.하지만 저는 둘 다 추천드리고 싶습니다. 만약에 적절한 도구에 액세스 할 수 있습니다.나는 이것이 디자인 버그를 찾는 효과적인 방법론이라는 것을 알았습니다. ~ 전에 실리콘이 됩니다.

나는 하드웨어/칩 설계에 대해서는 잘 모르지만 TDD에 깊이 빠져 있기 때문에 적어도 프로세스의 적합성에 대해서는 여러분과 논의할 수 있습니다.

제가 가장 적절하다고 생각하는 질문은 다음과 같습니다.테스트를 통해 설계에 대한 피드백을 얼마나 빨리 얻을 수 있습니까?관련:얼마나 빨리 새로운 테스트를 추가할 수 있나요?그리고 귀하의 도구는 디자인의 리팩토링(동작 변경 없이 구조 변경)을 얼마나 잘 지원합니까?

TDD 프로세스는 소프트웨어의 "부드러움"에 크게 좌우됩니다. 우수한 자동화 단위 테스트는 몇 초 만에(외부에서는 몇 분) 실행되며 집중적인 구성 및 리팩토링이 짧게 집중적으로 이루어집니다.귀하의 도구는 테스트 작성과 실행 사이를 빠르게 순환하고 짧은 반복으로 테스트 중인 시스템을 구축하는 이러한 종류의 워크플로우를 지원합니까?

하드웨어 언어용 리팩토링 도구와 관련하여 우리 도구를 알려드리고 싶습니다. 시가시 HDT.Sigasi는 VHDL 분석기와 VHDL 리팩토링이 내장된 IDE를 제공합니다.

필립 파스, 시가시

모루– 또 다른 Verilog Interaction Layer가 이에 대해 이야기합니다.나는 그것을 시도하지 않았습니다.

나는 RTL 디자인에서 TDD를 적극적으로 시도한 적이 없지만 이에 대한 내 생각은 있었습니다.

제가 생각하기에 흥미로울 것은 단언과 관련하여 이 접근 방식을 시도해 보는 것입니다.기본적으로 먼저 모듈에서 가정/기대하는 내용을 주장 형식으로 작성하고 RTL을 작성한 다음 나중에 공식 도구 및/또는 시뮬레이션을 사용하여 이러한 주장을 확인할 수 있습니다."일반" 테스트 케이스(지시된 테스트 케이스를 작성해야 하는 경우)와 달리 훨씬 더 나은 적용 범위를 가져야 하며 주장/가정은 나중에 사용할 수 있습니다(예:시스템 수준에서도).

그러나 나는 주장에 완전히 의존하지 않을 것입니다. 이것은 매우 털이 될 수 있습니다.

어쩌면 당신이 요구하는 대로 이것에 대한 당신의 생각을 표현할 수도 있을 것입니다. 당신의 머리 속에 몇 가지 아이디어가 있다고 생각합니까?

당신에게 TDD란 무엇인가요?항상 자동 테스트를 통해 모든 코드를 실행한다는 의미입니까, 아니면 더 나아가 테스트가 코드보다 먼저 작성되고 테스트가 실패하지 않는 한 새 코드가 작성되지 않는다는 의미입니까?

어떤 접근 방식을 선호하든 HDL 코드 테스트는 소프트웨어 테스트와 크게 다르지 않습니다.장점(훨씬 더 나은 적용 범위와 테스트 깊이)과 단점(설정이 어렵고 소프트웨어에 비해 상대적으로 번거로움)이 있습니다.

저는 합성 가능한 HDL 모듈에 대한 포괄적이고 자동 테스트를 구현하기 위해 Python 및 일반 HDL 트랜잭션을 사용하는 데 매우 좋은 경험을 갖고 있습니다.아이디어가 좀 비슷하네요 재닉 버거론 그의 책에는 SystemVerilog 대신 Python을 사용하여 (1) Python으로 작성된 테스트 시나리오에서 VHDL 코드를 생성하고 (2) 시뮬레이션 중에 설계의 파형을 받아들이는 모니터링 트랜잭션이 작성한 결과를 검증합니다.

이 기술에 관해 쓸 내용이 훨씬 더 많지만 무엇에 집중하고 싶은지 잘 모르겠습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top