Войти
| Парадигма | Аспектно-ориентированная |
|---|---|
| Разработана | Йоавом Холландером |
| Впервые появилось | 1992 (1992) |
| Стабильная версия | IEEE 1647-2016 / 6 января 2017 г.; 3 года назад (06.01.2017) |
| Расширения имен файлов | .e |
| Веб-сайт | TWiki @ eda.org |
e- это язык проверки оборудования (HVL), который предназначен для гибкая и многоразовая проверка тестовые среды.
Впервые e был разработан в 1992 году в Израиле Йоавом Холландером. за его программное обеспечение Specman. В 1995 году он основал компанию InSpec (позже переименованную), чтобы c коммерциализировать программное обеспечение. Продукт был представлен на конференции Design Automation Conference в 1996 году. С тех пор Verisity была приобретена Cadence Design Systems.
Основные характеристики e:
В языке e используется подход аспектно-ориентированного программирования (АОП), который является расширенным Ион подхода объектно-ориентированного программирования специально для удовлетворения потребностей, необходимых для функциональной проверки. АОП - это ключевая функция, поскольку она позволяет пользователям легко добавлять дополнительные функции к существующему коду неинвазивным способом. Это позволяет легко повторно использовать и поддерживать код, что является огромным преимуществом в мире аппаратного обеспечения, где дизайн постоянно дорабатывается в соответствии с требованиями рынка на протяжении всего жизненного цикла проекта. АОП также легко решает сквозные проблемы (функции, которые затрагивают различные разделы кода), позволяя пользователям расширять либо отдельные, либо все экземпляры конкретной структуры для добавления функций. Пользователи могут расширить несколько структур, чтобы добавить функциональность, относящуюся к конкретной функции, и при желании объединить расширения в один файл, обеспечивая более организованное разделение файлов.
Исполняемый код e заключен в маркеры сегментов кода <' and '>:
Все, что находится за пределами маркеров, является комментарием <' extend sys { // This is a comment Verilog style -- This is a comment in VHDL style post_generate() is also { out("... and everything else within the markers is executable code."); }; }; '>e также имеет два типа классов:
Класс может содержать поля, методы, порты и ограничения. Поля могут быть целочисленными, действительными, перечисляемыми, строковыми и даже сложными объектами. Сегмент кода показывает блок под названием "environment_u", экземпляр которого создается в корне e "sys". Этот класс environment_u содержит список из 5 объектов packet_s, а этот класс packet_s содержит два поля и метод.
<' // This is a dynamic class with two fields struct 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 struct unit environment_u { my_pkt[5]: list of packet_s; }; // sys is the root for every e environment and instantiates the 'test_env' object extend 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 }; '>e поддерживает утверждения с временными выражениями. Временное выражение используется на том же синтаксическом уровне, что и поля и методы, и поэтому является декларативным по своей природе. Временное выражение описывает синхронизированное поведение.
<' 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}}; '>e поддерживает покрытие, которое сгруппировано в соответствии с выбранным событием, и эти группы внутренне структурированы с элементами. Предметы могут быть простыми или сложными, например перечеркнутыми или переходными.
unit_example_u {event 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 и имеет четыре сегмента // с переходом каждой комбинации ИСТИНА - ЛОЖЬ}; };Обмен сообщениями в e можно выполнять различными способами.
unit message_example_u {example_message_method () is {out ("Это безусловное, неформатированное выходное сообщение."); outf ("Это безусловное форматированное сообщение вывода, отображаемое в HEX% x", 15); print «Это безусловное сообщение.»; message (LOW, «Это условное сообщение, обычно привязанное к регистратору сообщений.», «Вы также можете объединять такие строки и даже добавлять в этот вывод такие объекты, как«, me ».»); messagef (LOW, "Этот условный вывод отформатирован% x.", 15); }; };Тестовая среда e, вероятно, будет работать с моделями RTL или более высокого уровня. Имея это в виду, e может взаимодействовать с VHDL, Verilog, C, C ++ и SystemVerilog.
// Этот код находится в файле Verilog tb_top.v module testbench_top; reg a_clk; всегда # 5 a_clk = ~ a_clk; начальное начало a_clk = 0; end endmodule
Этот код находится в файле signal_map.e <' unit signal_map_u { // Define a port named 'a_clk_p' a_clk_p: in simple_port of bit is instance; // Set the port's hdl_path property to point to the 'a_clk' signal in the top-level testbench keep a_clk_p.hdl_path() == "~/testbench_top/a_clk"; }; '>Процесс функциональной проверки требует повышения уровня абстракции любой тестируемой конструкции (DUT) за пределами уровня RTL. Эта необходимость требует языка, способного инкапсулировать данные и модели, который легко доступен в объектно-ориентированных языках. Чтобы удовлетворить эту потребность, он был разработан как объектно-ориентированный язык и, кроме того, был дополнен аспектно-ориентированными механизмами, которые упрощают не только написание очень гибких и многоразовых тестовых стендов, но также помогают инженерам по верификации, позволяя исправлять обнаруженные RTL. ошибки без необходимости переписывать или касаться какой-либо из уже существующей кодовой базы.. Аспектно-ориентированное программирование на e позволяет инженерам по верификации структурировать свои средства тестирования по аспектам. Следовательно, объект - это сумма всех его аспектов, которые могут быть распределены по нескольким файлам. Следующие разделы иллюстрируют основные аспектно-ориентированные механизмы в e.
Подтипирование является ярким примером того, чего не могут достичь объектно-ориентированные языки без аспектно-ориентированных функций. Подтипирование позволяет инженеру по верификации добавлять функциональные возможности к уже определенному / реализованному классу без необходимости наследовать его от базового класса. В следующем коде показана исходная реализация базового класса и способы ее расширения. После того, как расширение имело место, все объекты базового класса также содержат расширения. Ограничения, заданные в двух разных подтипах, обычно вызывают противоречие, однако оба подтипа обрабатываются отдельно, и, таким образом, каждый подтип дает разные вычисления ограничений.
subtyping_example.e <' // This enum type definition is used to declare the subtypes ODD and EVEN type ctrl_field_type_t: [ODD, EVEN]; unit base_ex_u { // The subtype_field is the determinant field which calculation is being applied subtype_field: ctrl_field_type_t; data_word : uint (bits: 32); parity_bit : bit; // Subtyping the ODD type when ODD'subtype_field base_ex_u { // This is a simple constraint that XORs the index bit 0 of data_word and increments that value keep parity_bit == (data_word[0:0] ^ data_word[0:0] + 1); }; // Subtyping the EVEN type when EVEN'subtype_field base_ex_u { // This constraint is the same as above, however the increment is not done keep parity_bit == (data_word[0:0] ^ data_word[0:0]); }; }; '>Исходное определение единицы приведено в file1.e. Аспектно-ориентированный механизм, используемый в этом примере, показывает, как выполнить код до и после уже реализованного метода.
Этот код находится в file1.e <' unit aop_example_u { meth_ext() is { out("This is the original method implementation."); }; }; '>Этот код находится в file2.e <' extend aop_example_u { meth_ext() is first { out("This method extension is executed before the original method implementation."); }; meth_ext() is also { out("This method extension is executed after the original method implementation."); }; }; '>