2014-05-21 7 views
4

제 하드웨어 모델에 대한 UVM 테스트 벤치 (제한된 무작위 검증)가 있습니다. 내 황금 모델은 systemC 및 C++로 작성되었습니다. 내 하드웨어 결과가 소프트웨어 결과와 일치하지 않지만 둘 다 잠재적으로 정확할 수있는 경우가 있습니다.RTL과 Goldenmodel이 다르지만 정확한 출력을 낼 수있는 경우 HW를 검증하는 표준 방법론은 무엇입니까?

예를 들어, HW는 일부 메모리 관리 (할당, 할당 취소)를 수행하며 파이프 라인의 일부 다른 로직에 영향을 미칩니다. "언제"HW가 alloc 또는 dealloc 요청과 시간에 민감한 중재 정책을 얻는 지에 따라 몇 가지 출력을 생성합니다. 황금 모델에는 시간 개념이없고 경우에 따라 출력이 HW와 일치하지 않지만 HW 및 골든 모델 모두가 잠재적으로 정확할 수 있습니다.

이러한 종류의 시나리오를 확인하는 표준 방법은 무엇입니까? 골든 모델과 HW 출력이 모두 정확하지만 값이 다르면 점수 보딩이 정확성을 확인하는 데 도움이되는지 확실하지 않습니다. 나는이 분야에 새로운 사람이다. 그래서, 어떤 충고/포인터가 높게 평가됩니다.

답변

3

UVM의 목표 중 하나는 하드웨어 핀 - 흔들림 수준을 넘어 테스트 추상화 수준을 높이는 것입니다. 주어진 임의의 자극에 대해 출력이 정확하다는 지식이 있다면, 그 지식을 스코어 보드에 넣어야합니다. 모니터의 역할은 많은 시간 도메인 정보를 제거한 트랜잭션을 생성하여 처리를 위해 스코어 보드로 보내는 것입니다.

라우팅을 위해 패킷을 DUT로 보내는 순서가 잘못된 스코어 보드의 간단한 경우를 생각해보십시오.하지만 순서가 다릅니다. 참조 모델은 다른 순서를 만들지 만, 들어가는 모든 패킷은 일정 기간 후에 결국 나타나야합니다. 스코어 보드는 주문을 확인하지 않고 패킷을 받았는지 확인하거나 디자인 요건에 부과 된 주문을 확인합니다.

1

나는 Dave의 답변을 좋아하지만 정확성 논리가 너무 복잡하여 테스트 벤치에 넣을 수없는 경우에도 다른 접근법을 사용했습니다.

  • 요약 모든 비 결정론을 단일 '결정'인터페이스로 요약합니다.
  • HW가 취한 결정을 포착하고이를 systemC 모델에 입력으로 제공하십시오.
  • HW의 결정이 합법적인지 systemC 모델에서 확인한 다음 모델이 동일한 결정을 내 리도록하십시오. 즉 systemC 모델은 HW를 따릅니다.
  • 평소와 같이 나머지 인터페이스를 교차 점검하십시오.

이것은 완벽한 체커는 아니지만 인터페이스를 정의하면 시스템에서 허용되지 않는 비 결정론이 무엇인지 명시하고 있습니다.