e(검증 언어)

e (verification language)
E(프로그래밍 언어)와 혼동하지 마십시오.
e
패러다임애스펙트 지향
설계자요브 홀랜더
처음 등장한1992년(1992년)
안정된 릴리스
IEEE 1647-2016 / 2017년 1월 6일, 5년 전(2017-01-06)
파일 이름 확장자.e
웹 사이트TWiki @ eda.org


e는 매우 유연하고 재사용 가능한 검증 테스트벤치를 구현하기 위해 맞춤화된 Hardware Verification Language(HVL; 하드웨어 검증 언어)입니다.

역사

e는 1992년 Yoav Hollander에 의해 Specman 소프트웨어를 위해 이스라엘에서 처음 개발되었습니다.1995년 그는 소프트웨어를 상용화하기 위해 InSpec(나중에 Verisity로 개명)이라는 회사를 설립했습니다.이 제품은 1996년 디자인 자동화 컨퍼런스에서 [1]소개되었습니다.이후 Cadence Design Systems에 의해 Verisity가 인수되었습니다.

특징들

e의 주요 기능은 다음과 같습니다.

  • 무작위 및 제약된 무작위 자극 생성
  • 기능 적용 범위 메트릭의 정의 및 수집
  • 어설션 작성에 사용할 수 있는 시간 언어
  • 반사 기능을 갖춘 애스펙트 지향 프로그래밍 언어
  • 언어는 단일 테스트벤치를 사용하여 SystemC/C++ 모델, RTL 모델, 게이트 레벨 모델 또는 하드웨어 액셀러레이션 박스에 있는 DUT를 확인할 수 있다는 점에서 DUT에 의존하지 않습니다(UVM Acceleration for e Methodology 사용).
  • 특히 범용 검증 방법론(UVM)에 따라 테스트 벤치를 작성할 경우 재사용성이 높은 코드를 생성할 수 있습니다.
    • 이전에는 e-재사용 방법론(eRM)으로 불렸습니다.
    • UVM e 라이브러리 및 매뉴얼은 UVM World에서 다운로드할 수 있습니다.

언어 기능

e언어에서는 AOP(Aspect-Oriented Programming) 접근방식을 사용합니다.이는 기능 검증에 필요한 요구에 특히 대응하기 위한 객체 지향 프로그래밍 접근방식의 확장입니다.AOP는 사용자가 비침습적인 방법으로 추가 기능을 기존 코드에 쉽게 고정할 수 있도록 하는 핵심 기능입니다.이를 통해 재사용이 용이하고 코드 유지보수가 용이하며 프로젝트 라이프사이클 전반에 걸쳐 시장의 요구에 맞게 설계가 지속적으로 조정되는 하드웨어 세계에서 큰 이점이 있습니다.또한 AOP는 사용자가 특정 구조의 특정 인스턴스 또는 모든 인스턴스를 확장하여 기능을 추가할 수 있도록 함으로써 크로스 컷 우려 사항(코드의 다양한 섹션에 걸쳐 절단되는 기능)에 쉽게 대처합니다.사용자는 여러 구조를 확장하여 특정 기능과 관련된 기능을 추가하고 필요에 따라 확장자를 단일 파일로 번들할 수 있으므로 보다 체계적인 파일 파티셔닝이 가능합니다.

평.

실행 가능한 e코드는 코드 세그먼트 마커 <' 및 '> 안에 포함되어 있습니다.

예

마커 외부에 있는 것은 모두 코멘트 <' extend sys {// 이것은 코멘트 Verilog 스타일입니다.이것은 VHDL 스타일의 코멘트 post_generate()도 {out("...)이며, 마커 내의 다른 모든 것은 실행 가능한 코드입니다."; }; }; '>

반

e에는 2종류의 클래스도 있습니다.

  • 동적 클래스에는 키워드 'struct'로 레이블이 지정됩니다.구조는 일시적으로만 존재하며 가비지 컬렉터에 의해 지워질 수 있는 데이터를 생성하는 데 사용됩니다.
  • 스태틱 클래스에는 키워드 'unit'로 라벨이 붙습니다.유닛은 영구 테스트벤치 구조를 작성하는 데 사용됩니다.

클래스에는 필드, 메서드, 포트 및 제약 조건을 포함할 수 있습니다.필드는 정수, 실수, 열거, 문자열 및 복잡한 개체 유형일 수 있습니다.코드 세그먼트는 'environment_u'라는 단위가 e 루트 'sys' 내에서 인스턴스화되는 것을 보여줍니다.이 environment_u 클래스에는 5개의 packet_s 객체의 목록이 포함되어 있으며 이 packet_s 클래스에는 2개의 필드와 메서드가 포함되어 있습니다.

예

</' // 이것은 2개의 필드 structure packet_s { field0:uint (bits:32);// 이 필드는 'field0'이라고 불리며 // 32비트 폭의 부호 없는 정수입니다.field1: byte; // 이 필드는 'field1'로 불리며 바이트입니다.// 이 메서드는 post_generate() 패킷 객체가 생성되면 {out(field0)}, // 'field0' 값 인쇄 중; }, // 이것은 5개의 패킷 구조 단위 environment_u {my_pk[5]목록을 가진 정적 클래스입니다.packet_s; }; // sys는 모든 e 환경의 루트이며 'test_env' 개체 확장 sys { test_env: environment_u is instance; }; '>를 인스턴스화합니다.

랜덤화

e에서는 기본적으로 각 필드가 랜덤화됩니다.필드 랜덤화는 하드 제약이나 소프트 제약에 의해 제어되거나 완전히 꺼질 수도 있습니다.소프트 구속조건은 기본 구속조건으로 사용되며 경합이 발생하면 테스트레이어에 의해 자동으로 덮어쓰게 됩니다.그렇지 않으면 일반 제약 조건처럼 작동합니다.

예

<' structure my_destination_s {destination_address: uint(비트: 48)'; // 이 필드는 랜덤화되어 제약되지 않습니다.data_data: 바이트 목록, !snot_field: uint(비트: 32); //!'는 패리티_field가 랜덤화되는 것을 방지합니다.소프트 data_soft.size()를 [64]에 보관합니다.1500]; // [128]에 없는 디폴트 랜덤화 keep data_size()를 제공하기 위해 사용되는 소프트 제약 조건.256]; // 이것은 하드 제약입니다.}; '>

어설션

e는 시간 표현을 사용한 어사션을 지원합니다.시간식은 필드 및 메서드와 동일한 구문 수준에서 사용되며, 따라서 본질적으로 선언적이다.시간식은 시간적 동작을 나타냅니다.

예

<' unit temporal_example_u { event a ; // 이벤트 'a' 이벤트 b ; // 이벤트 'b' 이벤트 c ; // 이벤트 'c' 선언 // 이 어설션에서는 이벤트a 이후의 다음 사이클이 검출되어 이벤트 b가 발생하고 이벤트c가 발생할 것으로 예상합니다.@a = > {@b;@c} } ; ' >

범위

e는 샘플링된 이벤트에 따라 그룹화된 커버리지를 지원하며 이러한 그룹은 내부적으로 항목으로 구성됩니다.항목은 단순 항목일 수도 있고 교차 항목 또는 과도 항목과 같은 복잡한 항목일 수도 있습니다.

예

unit coverage_u { event cov _ event _ e ; // 수집 범위는 이 이벤트 커버 cov _ event _ e is { item a : uint ( bits : 4 );/ 이 항목에는 0 ~15 항목 b : bool;/ 이 항목에는 2개의 버킷이 있습니다.TRUE 및 FALSE 크로스 a, b; // 이 항목에는 a와 b 트랜스 b의 교차 곱셈 행렬이 포함되어 있습니다.// 이 항목은 항목 b에서 파생되었으며 4개의 버킷이 있으며 각 TRUE - FALSE 조합을 변환합니다.

메시징 및 보고서

e 내의 메시지는 다양한 방법으로 실행할 수 있습니다.

예

unit message_example_u {example_message_method()는 {out}("이것은 무조건 포맷되지 않은 출력 메시지입니다."; outf("이것은 HEX %x",15에 표시되는 무조건 포맷된 출력 메시지입니다")로 출력합니다.「이것은 무조건 메시지입니다."; message(LOW, "이것은 조건부 메시지이며 보통 메시지 로거에 연결되어 있습니다.", "이 출력에 ",me, "와 같은 문자열을 연결할 수도 있습니다.", messagef( "LOW, "이 조건부 출력은 %x15 형식입니다.";};

다른 언어와의 인터페이스

테스트벤치는 RTL 이상의 모델에서 실행될 가능성이 높습니다.이를 고려하여 e는 VHDL, Verilog, C, C++ 및 SystemVerilog와 인터페이스할 수 있습니다.

e <-> Verilog 훅업 예시

// 이 코드는 Verilog 파일 tb_top.v에 있습니다. 모듈 testbench_top;   조정하다 a_clock;      항상 #5 a_clock = ~a_clock;   초기의 시작한다.     a_clock = 0;   끝. 엔드 모듈 
이 코드는 signal_map.e 파일<' unit signal_map_u {// 비트 is instance의 simple_port에 'a_clk_p:' a_clk_p:'라는 이름의 포트를 정의합니다.// 포트 hdl_path 속성을 설정하여 최상위 테스트벤치 keep_cl_phd/()의 'a_path' 신호를 가리킵니다.

e의 애스펙트 지향 프로그래밍 지원

기능 검증 프로세스에서는 테스트 대상 설계(DUT)의 추상화 수준을 RTL 수준 이상으로 높일 필요가 있습니다.이 필요성에는 데이터 및 모델을 캡슐화할 수 있는 언어가 필요하며, 이는 객체 지향 언어에서 쉽게 사용할 수 있습니다.이 요구에 대응하기 위해 객체 지향 언어를 사용하도록 설계되었으며, 그 외에도 매우 유연하고 재사용 가능한 테스트 벤치를 작성할 수 있을 뿐만 아니라 발견된 RTL 버그를 수정하거나 수정하지 않고도 검증 엔지니어를 지원할 수 있습니다.기존 코드 베이스에 의존하지 않습니다.
e의 애스펙트 지향 프로그래밍을 통해 검증 엔지니어는 테스트 벤치를 애스펙트로 구성할 수 있습니다.따라서 개체는 여러 파일에 분산될 수 있는 모든 요소의 합입니다.다음 섹션에서는 e의 기본적인 애스펙트 지향 메커니즘을 보여 줍니다.

서브타이핑 메커니즘

서브타이핑은 애스펙트 지향 기능이 없는 객체 지향 언어가 달성할 수 없는 주요 예입니다.서브타이핑을 사용하면 검증 엔지니어는 기본 클래스에서 파생할 필요 없이 이미 정의된/실장된 클래스에 기능을 추가할 수 있습니다.다음 코드는 기본 클래스의 원래 구현과 확장 방법을 보여 줍니다.확장이 실행되면 모든 기본 클래스 개체에도 확장이 포함됩니다.두 개의 다른 서브타입에서 주어진 제약조건은 보통 모순을 일으키지만 두 서브타입은 개별적으로 처리되므로 각 서브타입은 다른 제약조건 계산을 산출한다.

서브타이핑 메커니즘의 예시

Subtyping_example.e<>'을 끓여이 열거형 형식 정의는 특이한과의 보복하형 ctrl_field_type_t:[,의 보복하]신고할;단위 base_ex_u{계산 subtype_field가 적용되고 있는 것은 subtype_field을 결정하는 필드:ctrl_field_type_t, data_word:uint(비트:32);parity_bit:비트//, 끓여는 Subtyping 사용된다.ODODD'subtype_field base_ex_u {// 이것은 data_word의 인덱스 비트 0을 XOR하고 해당 값을 keep parity_bit ==(data_word[0:0] ^ data_word[0:0] + 1);/// 이 기본 필드 {:exu}인 경우 짝수 유형을 하위 유형으로 지정하는 단순한 제약 조건입니다.ot keep parity_bit == ( data _ word [ 0 : 0 ]^ data _ word [ 0 : 0 ] ) ; } ; } ; ' >

메서드의 확장

원래 장치 정의는 file1.e에 나와 있습니다.이 예에서 사용되는 애스펙트 지향 메커니즘은 이미 구현되어 있는 메서드 전후에 코드를 실행하는 방법을 보여줍니다.

메서드 확장 예시

이 코드는 file1에 있습니다.e < unit aop _ example _ u { meth _ ext() is { out ( " 이것은 원래 메서드 구현입니다."; }; }; '>
이 코드는 file2에 있습니다.e <' extend aop_example_u {meth_ext() is first {out("이 메서드 확장은 원래 메서드 구현 전에 실행됩니다."; }; meth_ext()도 {out()입니다.이 메서드 확장은 원래 메서드 구현 후에 실행됩니다."; }; }; '>

레퍼런스

  1. ^ Samir Palnitkar:E, 프렌티스 홀 PTR을 통한 설계 검증.2003년 10월 5일 ISBN978-0-13-141309-2

원천