Что нового в VHDL 2019?

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

Далее мы рассмотрим две важнейшие особенности новой версии: интерфейсы и расширенные универсальные типы кардинально меняют способ использования VHDL. Они улучшают безопасность и удобочитаемость типов, уменьшая при этом многословие. Во второй статье обсуждаются интерфейсы, а в третьей - расширенные универсальные типы.

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

Нововведения

VHDL 2019 улучшает многие аспекты популярного языка проектирования оборудования. Наиболее важным улучшением является возможность связывать порты в интерфейсе. Эта функция значительно снижает количество подробностей при создании экземпляров, улучшая ремонтопригодность и ясность кода. По возможности был упрощен язык, сняты ограничения и устранены различные несоответствия. Новые API-интерфейсы, улучшенные защищенные и универсальные типы позволяют разработчикам создавать библиотеки проверки следующего поколения. Для достижения этих улучшений рабочая группа VHDL продолжает опираться на существующие сильные стороны VHDL: строгую типизацию, раннее обнаружение ошибок и четкую семантику языка.

Возрождение стандарта VHDL

Прежде чем мы углубимся в новые функции, интересно сделать шаг назад и проверить, есть ли еще смысл развивать этот стандарт VHDL, которому уже более тридцати лет. Актуален ли VHDL в 2019 году? Это вопрос, на который члены рабочей группы VHDL должны были ответить.

Ливен на DVCON 2018

В последние годы VHDL отошел на второй план, поскольку другие языки привлекли к себе все больше внимания. Редко можно увидеть на конференциях доклады, посвященные VHDL. Некоторые компании EDA и некоторые лидеры мнений даже объявили язык мертвым. Предыдущий выпуск, VHDL 2008, до сих пор полностью не поддерживается симуляторами, а поддержка синтеза встречается редко. Но, несмотря на негативную прессу и пренебрежение некоторыми поставщиками инструментов, VHDL по-прежнему остается очень популярным языком. Итак, почему он не исчез?

Когда пользователей спрашивают, что им нравится в VHDL, они обычно упоминают строгую систему типов и четкую семантику кода. Код может быть подробным, но он также удобочитаемым, с некоторыми неожиданностями. VHDL построен таким образом, что инструменты могут обнаруживать множество проблем во время компиляции. Многие виды ошибок устранены конструктивно. Это дает разработчику больше уверенности в том, что как только он начинает моделировать код, он действительно работает. Четкий код означает, что пользователи VHDL могут легко обмениваться кодом. VHDL в его нынешнем виде имеет ряд уникальных преимуществ. Задача рабочей группы - развивать язык, сохраняя при этом эти преимущества.

Чтобы объяснить, как VHDL достигает этих преимуществ, нам нужно посмотреть, как построен язык. С точки зрения языковой инженерии VHDL - интересный язык. В базовом языке, основанном на Ada, нет никаких концепций, связанных с проектированием оборудования. Вместо этого основной язык определяет только три вещи:

1. Примитивные и агрегатные типы
2. Некоторые предопределенные операции с этими типами
3. Четко определенная имитационная модель

Аппаратно-ориентированные функции не определены непосредственно в языке, а, скорее, на более высоком уровне: в библиотеке IEEE. Однако с точки зрения пользователя это различие не наблюдается. Сложные определяемые пользователем типы и гибкие литералы в сочетании с обширной перегрузкой операторов и подпрограмм делают типы данных, описанные в библиотеках IEEE, похожими на типы данных, встроенные в язык.

Это может показаться надуманным способом создания языка описания оборудования, но у него есть много преимуществ. Прежде всего, грамматика должна охватывать только основной язык, в результате чего язык намного меньше. Семантику меньшего языка легче определить, а простые спецификации имеют меньше угловых случаев. Базовый язык также легче реализовать, что снижает вероятность различий между реализациями. Поскольку библиотеки IEEE указаны на самом языке VHDL, их реализация является их спецификацией. Это означает, что их поведение не нужно описывать в LRM, и это исключает вариации в реализации. Еще одно преимущество заключается в том, что язык предназначен для расширения. Пользователи могут определять свои собственные сложные типы данных, расширяя библиотеку IEEE. Эти расширения работают как встроенные или предоставленные типы данных IEEE. Это позволяет пользователям расширять язык без привлечения инженеров по языку VHDL.

У этого подхода есть и недостатки. Многие разработчики воспринимают VHDL как очень абстрактный язык, более близкий к программному языку, чем другие языки описания оборудования. Система типов кажется очень негибкой, и типы часто приходится явно преобразовывать. Такой подход затрудняет добавление некоторых функций, потому что основной язык не обращает внимания на тактирование и сбросы. Производительность моделирования также может быть проблемой, специализированные встроенные типы дадут симулятору больше возможностей для оптимизации. Источники этих проблем и их решения не рассматриваются в этой серии статей, но рабочая группа VHDL знает о них.

Рабочая группа считает, что разделение языка и библиотеки IEEE в целом выгодно для VHDL. Если предлагается изменить базовый язык, оно сначала оценивается, возможно ли реализовать его как библиотеку. Например: важным предметом для языков проектирования аппаратного обеспечения является верификация. Рабочая группа сделала явный выбор не включать функции проверки в VHDL 2019. Вместо этого группа решила, что проверка должна быть реализована в виде библиотеки.

Методологии проверки быстро развиваются. Трудно оправдать добавление ограниченной случайной генерации в основной язык, когда эта методология может когда-нибудь быть заменена, например, формальными методами или чем-то еще неизвестным. Существует множество методологий проверки, и, в зависимости от требований к проектированию, используемая методология должна соответственно отличаться. В некоторых случаях может быть достаточно простого модульного тестирования, в других случаях может потребоваться вариация ограниченного случайного или формального. Поддержка всех известных методологий проверки со специализированным синтаксисом на базовом языке сделает спецификацию языка слишком большой и сложной. Это означало бы, что его сложнее реализовать, и значительно увеличило бы вероятность ошибок и несоответствий. Для VHDL 2008 уже разработано несколько проверочных библиотек с открытым исходным кодом. VUnit, OSVVM и UVVM доказали, что библиотечный подход к проверке с помощью VHDL - хороший выбор.

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

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

Определение VHDL 2019

Работа над VHDL 2019 началась в 2014 году с проведения опроса. Чтобы сконцентрировать усилия по стандартизации, людей, включенных в список рассылки VHDL, попросили оценить набор предложений. Результаты были очень ясными: интерфейсы были самой востребованной функцией. На тот момент было много разных предложений по достижению этой функциональности. На то, чтобы прийти к единому мнению по поводу этой функции, потребовалось более двух лет.

Тем временем были обсуждены и другие предложения функций, разделенных на две группы.

Одна группа функций направлена на упрощение использования VHDL. Это простые функции, которые легко реализовать, но они могут иметь огромное значение для пользователя.

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

Интерфейсы VHDL

Интерфейсы - центральный элемент в разработке оборудования. Существует множество стандартизованных интерфейсов, таких как I²C, AXI или VGA, и каждая конструкция также имеет внутренние интерфейсы для соединения различных частей системы. К сожалению, эти интерфейсы сложно моделировать с помощью VHDL. Как правило, они явно не определены. Вместо этого их описание повторяется на каждом объекте. Единственный способ идентифицировать их - использовать какое-либо соглашение об именах, например все порты подчиненного интерфейса AXI могут иметь префикс slave_axi_0_.

У этого подхода много недостатков. Поскольку нет централизованного определения, а решение основывается на соглашениях об именах, может быть сложно идентифицировать интерфейс в сложных объектах. Также сложно задокументировать интерфейс без центрального определения. Интерфейс повторяется не только для каждой сущности, которая его использует, но и для каждого экземпляра. Весь этот дублированный код очень неудобно поддерживать. Например, изменение типа или имени элемента интерфейса требует редактирования многих файлов, даже в архитектурах, которые просто передают интерфейс экземпляру. Эта ситуация неприемлема для языка, который высоко ценит строгую типизацию и раннее обнаружение ошибок; требуется языковая поддержка интерфейсов.

За прошедшие годы программисты разработали обходные пути для моделирования интерфейсов на VHDL. Одно из решений - смоделировать интерфейс как запись. Но разные элементы записи не могут иметь разные направления портов. Есть два решения этой проблемы: смоделировать эту запись как inout или разделить запись на несколько записей, по одной для каждого направления порта. Последний метод часто называют методом Гайслера 3.

Преимущество моделирования интерфейса как записи inout состоит в том, что интерфейс определяется в одном месте и его можно легко передавать. Вы можете вкладывать интерфейсы, вкладывая записи, и можете создавать массив интерфейсов. Однако у этого подхода есть один большой недостаток: компилятор больше не может проверять направление порта. По этой причине он почти не используется. Часто используется метод Гайслера. К сожалению, он не может обрабатывать вложенные интерфейсы и по-прежнему полагается на некоторые соглашения об именах.

Когда рабочая группа VHDL изучила, как могут быть реализованы интерфейсы, было обсуждено множество подходов. Вы можете сделать маршруты частью подтипа, создать новый тип записи или определить новый контейнер с различными типами объектов, такими как константы и сигналы. Было выбрано самое простое решение, названное «режим просмотра». Представление режима определяет направления портов для элементов записи. Вы можете рассматривать это как определяемый пользователем режим для записей, вместо того, чтобы вводить или выводить, вы обращаетесь к «режиму просмотра».

package interfaces is
 type streaming_bus is record -- the record definition
 valid : std_logic;
 data : std_logic_vector(7 downto 0);
 ack : std_logic;
 end record;

 view streaming_master of streaming_bus is -- the mode view of the record
 valid, data : out;
 ack : in;
 end view;
 
 alias streaming_slave is streaming_master’converse;
end;

В этом пакете интерфейсов определена запись streaming_bus. Эта запись определяет все имена и типы элементов записи. Действительные элементы записи и данные используются для передачи данных по шине, элемент ack используется для обеспечения некоторого противодавления. В режиме просмотра streaming_master мы создаем интерфейс для записи streaming_bus. Режим порта применяется к каждому элементу записи. Для максимального повторного использования кода одна запись может иметь несколько режимов просмотра. Поскольку они определены в пакете, определение можно использовать повторно. Запись и режим просмотра не обязательно должны быть определены в одном пакете. Используя атрибут converse, мы можем инвертировать направления режима просмотра в одну строку. В качестве альтернативы вы также можете явно определить streaming_slave следующим образом:

view streaming_slave of streaming_bus is
 valid, data : in;
 ack : out;
end view;
Давайте посмотрим, как можно использовать этот интерфейс.

entity source is
 port(clk, rst : in std_logic; output : view streaming_master);
end;

entity processor is
 port(clk, rst : in std_logic;
 input : view streaming_slave;
 output : view streaming_master);
end;

entity sink is
 port(clk, rst : in std_logic; input: view streaming_slave);
end;

architecture a of e is
 signal clk, rst : std_logic;
 signal input, output : streaming_bus;
begin
 producer : entity work.source port map(clk, rst, input);
 processing : entity work.processor port map(clk, rst, input, output);
 consumer : entity work.sink port map(clk, rst, output);
end;

В этом примере у нас есть три экземпляра, которые связаны с помощью двух шин. Производитель экземпляра считывает некоторые данные и отправляет их на вход шины. Эти данные обрабатываются обработкой создания экземпляра и отправляются на выход шины. Который затем потребляется экземпляром потребителя.

Обратите внимание, что режим просмотра, используемый в источнике, процессоре и приемнике сущностей, фактически записан в его краткой форме. Полная форма - это view streaming_master из streaming_bus. Но в этом примере ссылка на тип избыточна. Он уже определен в представлении режима, и в этом случае мы не используем конкретный подтип. Необходимость в длинной форме станет ясна в следующем примере.

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

type streaming_bus is record
 valid : std_logic;
 data : std_logic_vector;
 ack : std_logic;
end record;

streaming_bus теперь не ограничен, эта функция была введена в VHDL 2008. Наши определения режима просмотра не должны меняться. Мы можем изменить определение исходной сущности, чтобы сделать размер шины явным в качестве универсального параметра.

entity source is
 generic(size : natural);
 port(
 clk, rst : in std_logic;
 output : view streaming_master of streaming_bus(data(size - 1 downto 0))
 );
end;

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

Также возможно вложение интерфейсов, например вы можете объединить интерфейсы ввода и вывода объекта процессора в один интерфейс.

type processing_element_rec is record
 input, output : streaming_bus;
end record type;

view processing_element of processing_element_rec is
 input : view streaming_slave;
 output : view streaming_master;
end view;

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

type streaming_bus_array is array (natural range <>) of streaming_bus;
type processing_element_rec is record
 inputs : streaming_record_array(0 to 9);
 output : streaming_rec
end record type;

view processing_element of processing_element_rec is
 inputs : view (streaming_slave);
 output : view streaming_master;
end view;

В этом случае режим просмотра применяется к массиву с streaming_bus в качестве элемента массива. Определение должно быть заключено в круглые скобки, потому что режим просмотра применяется к массиву, а не к записи. Этот синтаксис аналогичен тому, как функции разрешения применяются к типам массивов.

Наконец, также можно передать интерфейс процедуре или функции. Невозможно вернуть интерфейс из функции.

procedure p(signal b : view streaming_slave; ...);
function f(signal b : view streaming_slave; ...) return ...;

Возможность четко выражать интерфейсы является наиболее заметным улучшением в VHDL 2019. Это значительно улучшает читаемость и удобство обслуживания проектов VHDL. Как показано в примерах, предоставляемые функции очень гибкие и позволяют разработчику моделировать любой интерфейс.

Расширенные универсальные типы

VHDL 2019 улучшает общие типы и подпрограммы. В VHDL 2008 были введены универсальные типы, эти универсальные типы могут быть привязаны к любому типу. В дополнение к универсальному типу с типом может быть предоставлен ряд универсальных операций. Например:

entity max is
 generic (
 type element_t;
 type array_t;
 function maximum(l : array_t) return element_t
 );
 port (
 clk : in std_logic;
 input : in array_t;
 output : out element_t
 );

Операции, переданные с универсальным типом, описывают возможности этого типа. Неявно операторы = и / = также передаются в универсальном списке для каждого универсального типа.

В VHDL 2019 рабочая группа решила упростить использование универсальных типов, позволив конструктору ограничить тип классом типа. После этого автоматически становятся доступными неявные объявления этого класса типа.

entity max is
 generic (
 type element_t is <>; -- "<>" means "scalar type"
 type index_t is <>;
 type array_t is array(index_t) of element_t
 );
 port (
 clk : in std_logic;
 input : in array_t;
 output : out element_t
 );
end;

Теперь мы ограничили element_t и index_t скалярными типами. Это означает, что все неявные объявления, такие как =,> =, to_string,… и все атрибуты, определенные для скаляров, доступны для этих типов. Максимум подпрограммы неявно определяется для скалярных типов, поэтому больше нет необходимости явно передавать подпрограмму. Мы также ограничили array_t типом массива. Помимо скаляра и массива, VHDL 2019 определяет еще семь общих типов, каждый со своими собственными неявными операциями, такими как максимум, to_string и =. В заключение, мы достигли безопасности типов, ограничив универсальные типы, и решение менее подробное, поскольку многие неявные операции не нужно передавать явно.

Чтобы сделать общие типы еще менее подробными, вводятся неполные формальные типы портов. Короче говоря, это позволяет нам описывать вложенный универсальный тип, не давая ему имени.

entity max is
 generic (
 type array_t is array(type is <>) of type is <>
 );
 port (
 clk : in std_logic;
 input : in array_t;
 output : out array_t’element
 );
end;

Этот пример можно еще улучшить: определение универсального типа можно переместить в определение порта.

entity max is
 port (
 clk : in std_logic;
 input : in type array_t is array(type is <>) of type is <>;
 output : out input’subtype’element
 );
end;

VHDL 2019 позволяет использовать неполные формальные типы в декларации порта. Мы использовали это, чтобы объявить вход порта. Для согласованности списки портов теперь анализируются по порядку, как и общие списки с 2008 года. Это означает, что вы можете ссылаться на ранее определенный порт для объявления порта, именно так объявляется тип вывода порта. В результате не только объявление объекта max становится менее подробным, но и его создание более кратким. Это связано с тем, что не требуется передавать общие параметры, аргументы универсального типа выводятся из списка портов.

maximizer : entity work.max port map(clk, input, output);

Вариант использования этих универсальных типов не ограничивается RTL. Динамические структуры данных теперь можно разрабатывать как библиотеку, эти структуры данных необходимы для проверочных библиотек. В следующем примере показано, как можно использовать такую структуру данных.

type int_list is new generic_list
 generic map(vect => integer_vector);

variable lst : int_list;
lst.addAll((1, 2, 3)); -- (1, 2, 3)
lst.add(10); -- (1, 2, 3, 10)
lst.index_of(3); -- returns 2
lst.remove_all(2); -- (1, 3, 10)

type int_to_string is new generic_map
 generic map(key => integer, value => string);

variable lookup_table : int_to_string;
lookup_table.put(1, "this"); -- (1 -> "this")
lookup_table.put(8, "that"); -- (1 -> "this", 8 -> "that")
lookup_table.get(8); -- returns "that"
lookup_table.exists(3); -- returns false

Чтобы построить эти динамические структуры данных, в язык пришлось добавить несколько других функций. Прежде всего, защищенные типы могут быть параметризованы универсальными типами, в этом примере generic_list и generic_map являются защищенными типами.

Пришлось снять многие ограничения на то, где и как могут использоваться защищенные типы. Была добавлена сборка мусора, так что разработчику не нужно вручную удалять эти динамические структуры данных после использования. Эти структуры данных не являются частью стандарта 2019 года. Скорее они служат в качестве экспериментов для проверочных библиотек.

В заключение, улучшения, которые были внесены в универсальные типы, сделали их более безопасными по типу и уменьшили их многословность. Они также позволяют использовать новые виды библиотек.

Удобство использования

Помимо улучшения некоторых основных конструкций VHDL, также важно обращать внимание на небольшие ежедневные неудобства цифрового дизайна.

Условные выражения

Пользователи часто пропускали тернарный оператор в VHDL. Для этой версии рабочая группа расширила возможности использования конструкции when-else:

1. Внутренние выражения: y <= a xor b after (3 нс, если БЫСТРО, иначе 5 нс); Выражение when-else должно быть заключено в круглые скобки.
2. Чтобы инициализировать константы и атрибуты:

constant DELAY : time := 3 ns when FAST else 5 ns;

attribute RAM_STYLE of RegFile : signal is

"distributed" when SMALL else "block";

 3.Взамен заявления:

return when condition; -- only return when the condition is true
return a when condition else b;

Условный анализ

Добавлен препроцессор для выполнения условной компиляции. Препроцессор имеет доступ к шести предопределенным переменным: VHDL_VERSION, TOOL_TYPE, TOOL_VENDOR, TOOL_NAME, TOOL_EDITION, TOOL_VERSION. Синтаксис препроцессора полностью соответствует синтаксису VHDL, например:

`if TOOL_VENDOR = "SIGASI" then
 attribute dont_touch of sig1 : signal is "true";
`endif

Эти предопределенные переменные также доступны как обычные константы VHDL в пакете std.env, что позволяет использовать их в регулярных выражениях следующим образом:

if env.tool_type = "SIMULATION" then ... endif;

Это позволяет разработчикам обходить проблемы с инструментами, которые нельзя решить с помощью языка VHDL. Библиотеки теперь могут ориентироваться на несколько версий VHDL или несколько наборов инструментов, предлагая функции в зависимости от среды.

Последовательные области объявления

Часто запрашиваемая функция позволяла разработчикам объявлять константы и переменные внутри последовательных областей. Для этого был добавлен последовательный блок-оператор. В следующем примере мы показываем оператор if внутри оператора for. У каждого из них есть блоки внутри для объявлений. Метки блоков необязательны.

p : process is
begin
 for i in some_vector’range then
 b1 : block
 constant element : integer := some_vector(i);
 begin
 if element > CONST then
 b2 : block
 variable result : integer;
 begin
 some_procedure(element, result);
 report result’image;
 end block b2;
 end if;
 end block b1;
 end for;
end process p;

В VHDL переменные могут быть синтезированы либо в комбинаторной логике, либо в регистрах, в зависимости от того, как они используются. Если значение переменной считывается в синхронизированном процессе, прежде чем оно будет записано, переменная приведет к созданию регистра. Иногда разработчики делают это по ошибке, что приводит к ошибкам проектирования. С последовательными объявлениями этой путаницы можно избежать: переменные, объявленные в последовательной декларативной части, всегда будут комбинаторной логикой.

p : process is
 variable combinatorial_or_register : unsigned(8 downto 0);
begin
 if rising_edge(clk) then
 b : block
 variable only_combinatorial : unsigned;
 begin
 ...
 end block b;
 end if;
end process p;

Большое целое число

Минимальный размер целого числа увеличен с 32-битного до 64-битного.

Для реализации физических типов 32-битные целые числа стали ограничением. Например, для хранения времени в наносекундах в течение одного часа требуется 40 бит. Поскольку большинство процессоров рабочих станций поддерживают 64-битные вычисления, вычисление 64-битных целых чисел при моделировании не должно замедлять моделирование.

Для конструкций оборудования, где полный 32-битный или 64-битный целочисленный диапазон не требуется, все же имеет смысл объявить целочисленный подтип или ограничить диапазон при объявлении переменной или сигнала.

Улучшенные атрибуты

Теперь у объектов есть прямой доступ к атрибутам своего типа. Это упрощает использование многих атрибутов.

Пример: получение строкового значения объекта

report o’subtype’image(o); -- VHDL 2008
report o’image -- VHDL 2019

Все атрибуты были проверены, и многие несоответствия были устранены. Например, атрибут изображения теперь доступен для записей и массивов.

Атрибуты для PSL

Поддержка PSL обновлена до последней версии (IEEE 1850-2010). Кроме того, теперь можно взаимодействовать с директивами PSL. Есть два способа сделать это.

Разработчики могут взаимодействовать с директивами PSL, используя два атрибута. Атрибут signal используется для чтения значения директивы PSL и атрибута события, чтобы определить, что директива PSL завершилась в этом цикле моделирования.

С помощью новых подпрограмм в пакете std.env библиотека проверки может проверять, не завершились ли какие-либо утверждения PSL, проверять, были ли покрыты все объекты PSL, сбрасывать состояние объектов PSL и многое другое.

Новые и улучшенные API

Были обновлены или добавлены несколько API для взаимодействия с операционной системой.

Файловый API

В API std.textio были добавлены четыре функции:

• Теперь файлы можно открывать в read_write_mode
• Вы можете определить, открыт ли еще файл, используя функцию file_state
• Вы можете определить и изменить размер файла с помощью подпрограмм file_size и file_truncate
• Добавлен случайный доступ к файлам с помощью подпрограмм file_position, file_seek и file_rewind.

API файловой системы

В пакете std.env добавлено несколько подпрограмм для взаимодействия с файловой системой.

• Каталоги можно исследовать с помощью подпрограммы dir_open и типа данных каталога.
• Файлы и каталоги можно создавать и удалять

procedure DIR_OPEN(Dir : out DIRECTORY; Path : in STRING; Status : out DIR_OPEN_STATUS);
impure function DIR_OPEN(Dir : out DIRECTORY; Path : in STRING) return DIR_OPEN_STATUS;
procedure DIR_CLOSE(Dir : in DIRECTORY);

type DIRECTORY is record
 Name : LINE; -- current directory name; resolved to its canonical form
 Items : DIRECTORY_ITEMS; -- list of pointers to directory item names
end record;
-- The predefined operations for this type are as follows:
-- function "="(anonymous, anonymous: DIRECTORY) return BOOLEAN;
-- function "/="(anonymous, anonymous: DIRECTORY) return BOOLEAN;

procedure DIR_CREATEDIR(Path : in STRING; Status : out DIR_CREATE_STATUS);
procedure DIR_CREATEDIR(Path : in STRING; Parents : in BOOLEAN; Status : out DIR_CREATE_STATUS);
impure function DIR_CREATEDIR(Path : in STRING; Parents : in BOOLEAN := FALSE) return DIR_CREATE_STATUS;
procedure DIR_DELETEDIR(Path : in STRING; Status : out DIR_DELETE_STATUS);
procedure DIR_DELETEDIR(Path : in STRING; Recursive : in BOOLEAN; Status : out DIR_DELETE_STATUS);
impure function DIR_DELETEDIR(Path : in STRING; Recursive : in BOOLEAN := FALSE) return DIR_DELETE_STATUS;
procedure DIR_DELETEFILE(Path : in STRING; Status : out FILE_DELETE_STATUS);
impure function DIR_DELETEFILE(Path : in STRING) return FILE_DELETE_STATUS;

Дата и время API

API даты и времени был добавлен в пакет std.env. Он имеет следующие особенности:

• Возможность запрашивать время с момента EPOCH как реальное
• Возможность запрашивать время как запись time_record, используя либо местный часовой пояс, либо UTC.
• Минимальный API для увеличения и уменьшения объектов time_record
• Возможность красиво распечатать время с помощью to_string

type time_record is record
 microsecond : integer range 0 to 999_999
 second : integer range 0 to 61;
 minute : integer range 0 to 59;
 hour : integer range 0 to 23;
 day : integer range 1 to 31;
 month : integer range 0 to 11;
 year : integer range 1 to 4095;
 weekday : dayofweek;
 dayofyear : integer range 0 to 365;
end record time_record;

Переменные среды

В std.env был добавлен минимальный API для запроса переменных среды.

API для разработчиков библиотек

Самоанализ

API интроспекции позволяет пользователям проверять произвольные типы данных. Эта функция ориентирована на библиотеки проверки и не предназначена для RTL.

Самоанализ состоит из двух частей: атрибутов для преобразования любого объекта в общий зеркальный объект и библиотеки std.reflect, которую можно использовать для проверки зеркальных значений и типов. API предлагает безопасный для типов метод проверки значений во время выполнения.

Наиболее распространенный вариант использования интроспекции - преобразование произвольных значений в известный тип. Например: преобразование значения VHDL в строковое представление, запись его в файл в формате JSON или преобразование любой записи в std_logic_vector.

API интроспекции основан на исследовании зеркального отражения, проведенном Гиладом Браха. Это проверенный подход, который использовался во многих других языках. В этой первоначальной версии невозможно создавать или изменять значения, в будущей версии эта функция может быть добавлена.

Asserts

Этот API похож на новый PSL API. Вы можете проверить, сколько утверждений не удалось, изменить сообщения об ошибках, очистить результаты утверждений и многое другое.

Этот API жизненно важен для проверочных библиотек. Подпрограммы добавлены в пакет std.env.

Вызов пути

Были внесены два дополнения, чтобы предоставить пользователям проверочных библиотек лучшую отладочную информацию.

API предоставляет функции для получения имени файла, пути к файлу и строки в текущем файле VHDL. Другой набор подпрограмм и типов можно использовать для получения и проверки пути вызова, также называемого трассировкой стека.

Заключение

Эта статья о новом стандарте VHDL 2019, которая пытается охватить наиболее существенные улучшения VHDL 2019. Этот новый стандарт значительно улучшает как RTL, так и проверку. Добавлены интерфейсы, улучшены универсальные типы и упрощен язык. Новая версия также увеличивает поддержку и доступные инструменты для разработчиков библиотек проверки.

Результат должен вдохнуть новую жизнь в сообщество VHDL. Пересмотр был проголосован и выпущен в 2019 году. Готовые предложения публично доступны на вики 7 рабочей группы VHDL.

Пакеты IEEE и STD имеют открытый исходный код и общедоступны на

https://opensource.ieee.org/vasg/Packages.

Статья переведена каналом: NR.electronics:

Вы можете помочь каналу через Яндекс-деньги:

или через банковскую карту: 4377 7237 6190 5714

для большего числа переводов статей.