소프트 CPU 검증


18

현재 Xilinx ISE와 ISIM을 사용하여 VHDL에서 간단한 CPU를 설계하고 있습니다. 디자인 부분은 훌륭하게 진행되고 있지만 일관된 방식으로 확인을 수행하는 방법을 찾지 못하는 것 같습니다.

지금은 특정 순간에 작업중 인 기능을 테스트하기 위해 업데이트하는 VHDL 테스트 벤치가 있습니다. 이것은 매우 임시적이며 회귀를 잡는 데 도움이되지 않으며 사양 / 지침 세트의 준수를 확인하는 데 사용할 수 없습니다.

나는 광범위한 테스트 스위트를 개발하려고 생각했지만 문제는 CPU로서 범용 부품의 잠재적 상태가 덜 일반적인 구성 요소에 비해 크다는 것입니다.

보다 통제 된 방식으로 설계 및 테스트를 수행 할 수있는 방법을 찾고 있습니다. 당신이 원한다면 어떤 종류의 "하드웨어 TDD". 그런 것이 있습니까? CPU와 같은 범용 부품에 비교적 쉽게 적용 할 수 있습니까?

답변:


16

CPU 확인의 전체 문제는 매우 크고 어렵습니다. 이것으로 경력을 쌓는 사람들이 있습니다. 나는 당신에게 개요를 줄 것이다 ...

  1. 모든 명령어와 모든 명령어의 작은 세부 사항을 테스트하는 어셈블리 언어 프로그램을 작성하십시오. 예를 들어, ADD 명령어를 테스트 할 때 양수, 음수 및 각각 하나 (두 번)의 숫자로 테스트 할 수 있습니다. 그런 다음 캐리 플래그, 제로 플래그 등을 테스트합니다. 분기 예측 등과 같은 CPU의 다른 특수 기능에는이 테스트의 고유 한 부분이 있습니다.

  2. C / C ++ 또는 CPU 모델을 사용하여 작성하십시오. 이것은 가상 CPU입니다. 이것은 또한 "골든 CPU"입니다. 이는 다른 모든 것과 비교되는 CPU임을 의미합니다. 이상적으로 VHDL을 작성한 사람은 C / C ++ 모델을 쓰는 사람과 동일 하지 않습니다 .

  3. C / C ++ 모델과 VHDL 모델을 나란히 실행할 수있는 시스템을 작성하고 작성하고 결과를 사이클별로 비교하십시오. 1 단계에서 어셈블리 프로그램을 실행하고 두 모델이 일치하는지 확인하십시오.

  4. 임의의 "지침"에서 두 모델을 실행하십시오. 기본적으로 "ram"에 임의의 데이터를 채우고 실제 명령 인 것처럼 임의의 데이터를 실행하십시오. VHDL 및 C / C ++ 모델 모두에서 동일한 무작위 데이터를 실행하고 결과를 비교하십시오. 이 C / C ++ 모델은 일부 워크 스테이션 및 / 또는 서버 (새 CPU 자체가 아님)에서 실행됩니다.

  5. 4 단계를 본질적으로 영원히 반복하도록 머신 또는 여러 머신을 설정하십시오. CPU가 "완료"되어 1 년 이상 프로덕션 상태 인 경우에도이 테스트를 계속 실행합니다.

  6. 시뮬레이션 할 항목이 더있을 때마다이 단계를 반복하십시오. 예를 들어 라우팅 후 VHDL에서 사용 가능한 타이밍으로 실행합니다.

VHDL과 C / C ++ 버전을 비교한다고해서 모든 버그가 발견 될 것이라는 보장은 없지만 실제로 더 좋은 방법은 없습니다. 그리고 임의의 명령으로 CPU를 테스트하는 데 시간이 걸리지 만 매우 유용합니다. 이것에 대한 유일한 대안은 CPU의 다른 부분을 테스트하기 위해 하루 종일 코드를 작성하는 많은 사람들을 고용하는 것입니다. 대기업은이 작업을 수행하지만 임의의 데이터 작업도 수행합니다.

VHDL 코드를 작성하는 한 사람의 경우 일반적으로 1 단계 만 수행하면됩니다. 그러나 CPU를 판매하려는 경우 최소한 다른 단계 중 일부를 수행해야합니다 (실제로 모두 수행해야합니다).


훌륭한 답변, 감사합니다! 이것은 많은 의미가 있습니다. "골든 CPU"는 실제로 테스트 할 때주기 별 검증을 수행 할 수있는 퍼즐의 누락입니다. 이것은 주로 장난감 프로젝트이기 때문에 마지막 단락의 첫 문장을 따르고 1 단계를 수행 할 것이라고 생각합니다. 그러나 내가 해야 할 일을 아는 것은 매우 중요합니다.
drxzcl

황금색이지만 사이클이 정확하지 않은 C ++ 모델을 사용하면 훨씬 간단하고 정확할 수 있습니다. 예를 들어 ALU 기능을 테스트하는 데 유용합니다 (예 : "2 + 2 = 4 및 일부 플래그, I "1 틱 후 2 + 2 = 4 및 2 틱 후 플래그"보다는 "언제나 신경 쓰지 마십시오")
Martin Thompson

또한 코드 커버리지 (모두 연습했는지 확인)와 테스트 커버리지 (빠른 테스트와 실패 테스트를 모두 수행했는지 확인)를 실행하십시오.
Martin Thompson

후속 조치 : "1 단계"절차를 사용하여 어셈블러에서 많은 결함을 발견했습니다. P 코어 자체는 비교적 괜찮은 것 같습니다.
drxzcl
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.