Е (язык проверки) - Википедия - e (verification language)

Не путать с E (язык программирования).
е
ПарадигмаАспектно-ориентированный
РазработаноЙоав Холландер
Впервые появился1992 (1992)
Стабильный выпуск
IEEE 1647-2016 / 6 января 2017 г.; 3 года назад (2017-01-06)
Расширения имени файла.e
Интернет сайтTWiki @ eda.org

е это язык проверки оборудования (HVL), который предназначен для реализации очень гибкой и многоразовой проверки испытательные стенды.

История

е был впервые разработан в 1992 году в Израиле Йоавом Холландером для его Спецман программного обеспечения. В 1995 году он основал компанию, InSpec (позже переименован Достоверность ), чтобы коммерциализировать программное обеспечение. Продукт был представлен в 1996 году. Конференция по автоматизации проектирования.[1] Verisity с тех пор была приобретена Системы дизайна Cadence.

Функции

Основные особенности е находятся:

  • Генерация случайных и ограниченных случайных стимулов
  • Определение и сбор метрики функционального покрытия
  • Темпоральный язык, который можно использовать для написания утверждений
  • Аспектно-ориентированное программирование язык с возможностью отражения
  • Язык не зависит от DUT в том смысле, что вы можете использовать один е testbench для проверки модели SystemC / C ++, модели RTL, модели уровня ворот или даже DUT, находящегося в блоке аппаратного ускорения (с использованием ускорения UVM для е Методология)
  • Может создавать многоразовый код, особенно если тестовая среда написана после Универсальная методология проверки (УВМ)
    • Ранее известный как е Методология повторного использования (еRM)
    • UVM е библиотеку и документацию можно скачать здесь: UVM мир

Особенности языка

В е язык использует аспектно-ориентированное программирование (АОП) подход, который является расширением объектно-ориентированного программирования подход, специально предназначенный для удовлетворения потребностей, необходимых для функциональной проверки. АОП - это ключевая функция, поскольку она позволяет пользователям легко добавлять дополнительные функции к существующему коду неинвазивным способом. Это позволяет легко повторно использовать и поддерживать код, что является огромным преимуществом в мире аппаратного обеспечения, где дизайн постоянно изменяется в соответствии с требованиями рынка на протяжении всего жизненного цикла проекта. АОП также легко решает сквозные проблемы (функции, которые затрагивают различные разделы кода), позволяя пользователям расширять либо отдельные, либо все экземпляры конкретной структуры для добавления функций. Пользователи могут расширить несколько структур, чтобы добавить функциональность, относящуюся к конкретной функции, и при желании объединить расширения в один файл, обеспечивая более организованное разделение файлов.

Комментарии

Исполняемый е код заключен в маркеры сегментов кода <'и'>:

Пример

Все, что находится за пределами маркеров, является комментарием <'extend sys {// Это комментарий в стиле Verilog - это комментарий в стиле VHDL post_generate () также {out ("... а все остальное внутри маркеров является исполняемым кодом . "); };}; '>

Классы

е также есть два вида классов:

  • Динамические классы помечаются ключевым словом struct. Структуры используются для создания данных, которые существуют только временно и могут быть очищены сборщиком мусора.
  • Статические классы помечаются ключевым словом unit. Единицы используются для создания постоянной структуры тестового стенда.

Класс может содержать поля, методы, порты и ограничения. Поля могут быть целочисленными, действительными, перечисляемыми, строковыми и даже сложными объектами. Сегмент кода показывает блок под названием "environment_u", экземпляр которого создается в корне e "sys". Этот класс environment_u содержит список из 5 объектов packet_s, а этот класс packet_s содержит два поля и метод.

Пример

<'// This is a dynamic class with two fieldsstruct packet_s {  field0: uint (bits: 32);   // This field is called 'field0' and is a                             // 32 bit wide unsigned integer.  field1: byte;             // This field is called 'field1' and is a byte.    // This method is called once a packet_s object has been generated  post_generate() is also {     out(field0);            // Printing the value of 'field0'  };};// This is a static class with a list of five packet structunit environment_u {  my_pkt[5]: list of packet_s;};// sys is the root for every e environment and instantiates the 'test_env' objectextend sys {  test_env: environment_u is instance;};'>

Рандомизация

В е каждое поле по умолчанию рандомизировано. Рандомизацию полей можно контролировать с помощью жестких ограничений, мягких ограничений или даже полностью отключить. Мягкие ограничения используются в качестве ограничений по умолчанию и могут быть автоматически отменены тестовым слоем в случае возникновения конфликта. В противном случае он ведет себя как обычное ограничение.

Пример

<'struct my_pkt_s {  destination_address: uint (bits: 48);   // this field is randomized and is not constrained.  data_payload       : list of byte;       !parity_field      : uint (bits: 32);   // '!' prevents the parity_field from being randomized.    keep soft data_payload.size() in [64..1500];  // a soft constraint, used to provide a default randomization  keep data_payload.size() not in [128..256];   // this is a hard constraint};'>

Утверждения

е поддерживает утверждения с временными выражениями. Временное выражение используется на том же синтаксическом уровне, что и поля и методы, и поэтому является декларативным по своей природе. Временное выражение описывает синхронизированное поведение.

Пример

<'unit temporal_example_u {  event a;   // declaring an event 'a'  event b;   // declaring an event 'b'  event c;   // declaring an event 'c'    // This assertion expects that the next cycle after event a  // has been detected that event b followed by event c occurs.  expect @a => {@b;@c}};'>

Покрытие

е поддерживает покрытие, которое сгруппировано в соответствии с выбранным событием, и эти группы внутренне структурированы с элементами. Предметы могут быть простыми или сложными, например перечеркнутыми или переходными.

Пример

unit cover_example_u {событие cov_event_e; // сбор покрытия будет привязан к этому событию cover cov_event_e is {item a: uint (bits: 4); // этот элемент имеет 16 сегментов от 0 до 15 item b: bool; // у этого элемента два сегмента: ИСТИНА и ЛОЖЬ cross a, b; // этот элемент содержит матрицу перекрестного умножения a и b trans b; // этот элемент является производным от элемента b и имеет четыре сегмента // с переходом каждой комбинации ИСТИНА - ЛОЖЬ};};

Сообщения и отчеты

Обмен сообщениями внутри е можно делать разными способами.

Пример

unit message_example_u {example_message_method () is {out ("Это безусловное, неформатированное выходное сообщение."); outf ("Это безусловное форматированное сообщение вывода, отображаемое в HEX% x", 15); print "Это безусловное сообщение."; message (LOW, «Это условное сообщение, обычно привязанное к регистратору сообщений.», «Вы также можете объединять такие строки и даже добавлять в этот вывод такие объекты, как«, me ».»); messagef (LOW, "Этот условный вывод отформатирован% x.", 15); };};

Взаимодействие с другими языками

An е testbench, вероятно, будет работать с моделями RTL или более высокого уровня. Имея это в виду, е способен взаимодействовать с VHDL, Verilog, C, C ++ и SystemVerilog.

Пример е <-> Verilog Hookup

// Этот код находится в файле Verilog tb_top.vмодуль testbench_top;  рег a_clk;     всегда #5 a_clk = ~a_clk;  исходный начинать    a_clk = 0;  конецконечный модуль
Этот код находится в файле signal_map.e <'unit signal_map_u {// Определите порт с именем' a_clk_p 'a_clk_p: in simple_port of bit is instance; // Устанавливаем свойство порта hdl_path так, чтобы оно указывало на сигнал 'a_clk' в тестовой среде верхнего уровня keep a_clk_p.hdl_path () == "~ / testbench_top / a_clk";}; '>

Поддержка аспектно-ориентированного программирования в е

Процесс функциональной верификации требует повышения уровня абстракции любого тестируемого проекта (DUT) за пределы уровня RTL. Эта необходимость требует языка, способного инкапсулировать данные и модели, который легко доступен в объектно-ориентированных языках. Для удовлетворения этой потребности была разработана е объектно-ориентированный язык и, кроме того, был дополнен аспектно-ориентированными механизмами, которые не только облегчают написание очень гибких и многоразовых тестовых стендов, но также помогают инженерам по верификации, позволяя исправлять обнаруженные ошибки RTL без необходимости переписывать или трогать какие-либо из уже существующая кодовая база.
Аспектно-ориентированное программирование в е позволяет инженерам по верификации структурировать свой стенд по аспектам. Таким образом, объект - это сумма всех его аспектов, которые могут быть распределены по нескольким файлам. Следующие разделы иллюстрируют основные аспектно-ориентированные механизмы в e.

Механизм подтипа

Создание подтипов - яркий пример того, чего не могут достичь объектно-ориентированные языки без аспектно-ориентированных функций. Подтипирование позволяет инженеру по верификации добавлять функциональные возможности к уже определенному / реализованному классу, не производя его от базового класса. В следующем коде показана исходная реализация базового класса и способы ее расширения. После того, как расширение имело место, все объекты базового класса также содержат расширения. Ограничения, указанные в двух разных подтипах, обычно вызывают противоречие, однако оба подтипа обрабатываются отдельно, и, таким образом, каждый подтип дает разные вычисления ограничения.

Пример механизма подтипа

subtyping_example.e <'// Это определение типа перечисления используется для объявления подтипов ODD и EVENtype ctrl_field_type_t: [ODD, EVEN]; unit base_ex_u {// Subtype_field является определяющим полем, вычисление которого применяется subtype_field: ctrl_field_type_t; data_word: uint (биты: 32); parity_bit: бит; // Подтип типа ODD, когда ODD'subtype_field base_ex_u {// Это простое ограничение, которое выполняет операцию XOR над индексным битом 0 слова data_word и увеличивает это значение, сохраняя parity_bit == (data_word [0: 0] ^ data_word [0: 0] + 1); }; // Создание подтипа для типа EVEN, когда EVEN'subtype_field base_ex_u {// Это ограничение такое же, как указано выше, но приращение не выполняется 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. ^ Самир Пальниткар: Проверка дизайна с помощью e, Prentice Hall PTR. 5 октября 2003 г. ISBN  978-0-13-141309-2

Источники