Comments 47
Тема языка e плавно позабылась ;)
Ну дык все его находки перенеслись в SystemVerilog. При этом SystemVerilog можно запустить и бесплатно попробовать вместе с Questa или Xilixn Vivado, а вот чтобы получить доступ к интерпретатору e/Specman, нужно или работать в электронной компании или заплатить $50,000 за лицензию https://www.design-reuse.com/news/3130/verisity-specman-elite-version-4.html
Dlang.org позволяeт забыть весь алфавит
Казалось бы, а причем тут язык "е") Статья-то хорошая, но заголовок вообще не соответствует содержанию
Так в языке "e" начались все описываемые механизмы: constrained randomization, functional coverage, выражения темпоральной логики. И на 10 лет раньше, в 1992 году. SystemVerilog это просто инкорпорировал в себя в начале 2000-х.
Точно так же как скажем Паскаль не возник бы без Алгола.
И сколько этой информации уделено места в тексте?) Одно предложение? Я понимаю бы ещё все примеры были на языке "е" или было бы сравнение "как было в е, и как стало в SV".
Но ведь нет) Статья о проблемах валидации железа. Убери из рассказа все упоминания "е" она хуже не станет)
В принципе я могу для каждого примера на SystemVerilog его эквивалент на e. Но насколько это актуально? Лицензия на e стоит 50 тысяч долларов (стоила раньше по крайней мере). Его используют те, кто подсел на него в 1990-е / начале 2000-х и решил не переключаться на SystemVerilog, возможно некоторые группы в Интеле, или там военные, которые смешивали его с VHDL. Он открыл путь для SystemVerilog, а вот SystemVerilog можно скачать и с ним поиграть.
Да проблема-то не содержании статьи) Проблема в заголовке) Заходишь почитать про язык, но читаешь целую статью о верификации железок) Кликбейт получается)
Дык весь язык e - только про верификацию железок. Там все то же что в SystemVerilog, только в профиль + он не объектно-ориентированный, а аспектно-ориентированный:
Например вот его вариант constraints https://www.verilab.com/files/Specman_primer_systemverilog20180124.pdf
Сегодня в топе не менее кликбейтные "У животных есть личности. И это ставит науку в тупик", "ChatGPT провалил тест на ручник" (эта вообще не соответствует содержимому, просто мнение одного анонимуса). Конкурировать с такими по-честному невозможно. Если бы эта статья содержала в названии "SystemVerilog", ее бы прочитало 15 человек и она бы набрала +2.
с <= std_logic_vector (resize (signed (a), 9) + resize (signed (b), 9));
Если a, b и c - integer, то на VHDL выглядит точно так же:
c <= a+b;
Хейт vhdl на пустом месте, имхо
Никогда не видел, чтобы кто-либо использовал integer для сигналов (или variables) в VHDL. Он же вроде только 32-битный, а во всем синтезируемом коде нужно точно количество бит для каждого сигнала или переменной, которая превращается в D-триггер. Вы мне можете показать кодна VHDL в котором все на integer?
Стандартная практика - это std_logic_vector и numeric_std. Или это какое-то нововведение? (Я использовал VHDL много но давно)
numeric_std
определяет арифметику.
Да. А теперь два вопроса. 1) Как в numberic_std сложить два 8-битных числа с переносом в 9 разряд и присвоить их 9-разрядному числу? Со знаком и без знака. В верилоге это просто
logic [7:0] a, b;
wire [8:0] = a + b;
Перенос выясняется автоматически в контексте присваивания.
2) Пользуются ли типами signed и unsigned из numeric_std для портов entity?
Все на integer не будет, т.к. интерфейсы рано или поздно потребуют явной спецификации разрядностей. Внутренняя математика — отчего бы нет? Начиная от тупого счетчика, который современные синтезаторы урежут до нужного числа бит. А если вспомнить что integer бывает с явным заданием диапазонов, так и вовсе можно любую арифметику писать. Заодно автоматически проверяя переполнение на моделировании.
Я не видел синтезируемого кода на VHDL, который вот так бы полагался на то, что синтез все урежет из integer. Я также не встречал таких рекомендаций в литературе.
Насчет явного задания диапазонов - то же самое. Хотя я использовал VHDL в 1999-2003 и может потом кем-то стало принято писать integer c ranges вместо std_logic_vector / signed / unsigned.
Я использу ieee.std_logic_unsigned.all, и тогда std_logic_vector можно складывать без приведения.
Да, в VHDL нет расширения до размера результата, а только до максимальной ширины аргументов, но это спорный вопрос что лучше. Больший контроль за разрядностью - меньше ошибок, но чуть больше кода, когда надо разрядность изменить.
P.S. Сразу скажу, что в моих ПЛИС и чипах нет знаковых чисел совсем (вот такие задачи ;)), да и расширения разрядности тоже не вспомню, чтобы требовались, кроме при выдачи в PCIe, где все регистры, видимые из процессора, 32 битные.
P.P.S. В листинге про 2+2 sum потерялось.
Да, я в курсе про ieee.std_logic_unsigned.all но в 1998-2002 когда я пользовался VHDL, были дискуссии, что это плохо, что у VHDL есть разные несовместимые пакеты для арифметики (numeric_std и std_logic_signed/unsigned), std_logic_signed/unsigned считался менее стандартным (он вроде был связан с Synopsys) и предлагалось переходить на numeric_std. Собственно, это предлагается и сейчас - первая нагугленная ссылка:
https://nandland.com/vhdl-math-std_logic_arith-vs-numeric_std/
Have you ever tried to do math operations inside of an FPGA? If so, you probably have realized that you need to include a special package file to accomplish this task. If you are using std_logic_arith, you are using an unsupported package file. You should be using numeric_std.
Although it might appear that std_logic_arith is an IEEE supported package file, it is not. IEEE created the numeric_std package file and it is the official package file for performing mathematical operations in FPGAs. Std_logic_arith was created by Synopsis before IEEE created numeric_std. Since Synopsis had the first package file to do math, they gained a large user base. Unfortunately their package file is easy to use incorrectly, especially when doing unsigned and signed math. There are two main reasons for this:
Synopsis’ std_logic_arith file does not force you to be explicit in whether your signals are signed or unsigned.
When doing both signed and unsigned math in one file, you will have conflicts with overloaded operators.
P.P.S. В листинге про 2+2 sum потерялось.
Идея, что sum присваивается от инстанциации модуля сумматора вне этого кода
Я когда-то сделал вот такую картинку
О, это хорошо. Не прошло и 20 лет, как я наконец понял отношение между eRM, RVM и uVC. Спасибо
ну да, тут подразумевается соединение всех ранее придуманных методологий верификации в UVM
Это ещё что! Я как-то раз употребил слово "покоалесцирую" в значении "уподоблюсь коале". За что коала на меня обиделась.
В филогенетике, кстати говоря, коалесценция употребляется в обратном значении — где дерево ветвится, там и коалесценция. Ибо когда мы идём назад по времени (что делают коалесцентные методы построения деревьев), то кажется, что ветки коалесцируют, хотя на самом деле они расходятся.
интересный способ интегрированной рекламы, но мне лично больше нравится отдельным блоком в любом месте статьи, чем неочевидно и во многих местах. Спасибо за понимание.
А какие сейчас тенденции в использовании SystemVerilog как HDL?
На том же verilog очень неудобно описывать интерфейсы шин - их нельзя объединить в структуру. В том же VHDL можно - и это очень удобно. В SV можно использовать интерфейсы.
Вполне успешно и широко используется.
SV активно используется для разработки во многих компаниях именно из-за интерфейсов. Кроме того, использование SV для дизайна сильно упрощает использование UVM. В VHDL-2008 нет реализации интерфейсов как таковой, вместо этого можно упаковать порты в record, но без modport это все еще хуже, чем в SV. Интерфейсы добавили только в VHDL-2019, но должно пройти еще лет 10 пока вендоры начнут поддерживать этот стандарт. Т.е. в разработке большие компании скорее отходят от SV, если что-то написано на VHDL, то это скорее легаси, которое просто страшно/лень переписать.
А что стало с Гавриловым?
О нем упоминули в этой статье.
Стал членом совета директоров TSMC https://www.linkedin.com/in/moshe-gavrielov-401b28/
Отличная статья, спасибо. Хотел бы добавить что еще очень важный coverpoint это то что мы наблюдали появление valid при отсутствующем в предыдущем такте ready.
Вот ваш Гаврилов:
https://il.linkedin.com/in/yoav-hollander-aa565630?original_referer=https%3A%2F%2Fwww.google.com%2F
"I created the e verification language, and founded Verisity to commercialize the related tools and methodologies for HW verification. "
Не очень, как то на Гаврилова смахивает...
По вашей ссылке сказано "президент Verisity?" Нет, по вашей ссылке сказано "founder & CTO" - в переводе с английского означает "основатель и CTO". А президент Гаврилов - здесь https://www.linkedin.com/in/moshe-gavrielov-401b28/
Забавно, что в повествовании забыли про язык D. А он, между прочим, в 2018 году был включен в состав GCC. Когда-то пробовал его, нашёл свой старый файл и скомпилировал с помощью gdc на своей системе.
Деды помнят!
Жалко про язык е почти ничего не было. А его придумали в израильском стартапе, купленном позже Cadence. E от слова English. Идея была, в том, что там описания тест кейсов на английском ну и между ними тут и там constraints на вход и инварианты.
Я работал в Кейденсе, как раз в этом израильском отделении, созданном на базе купленного стартапа с е
Сейчас его создатель организовал стартап по тестированию автономных автомобилей.
Слышали ли вы про язык «e»? А ведь он был продан за $315 миллионов долларов