Обработка параметризации в пакетах SystemVerilog

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

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

Да я согласен. Это недостающая функция пакетов.

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

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

Вы можете использовать параметризованные макросы для обозначения типа с определенной шириной:

`define SIMPLE_STRUCT(NAME) \
   simple_struct_t_``NAME``

`define SIMPLE_STRUCT_DEF(NAME, ADDR_MSB, DATA_MSB) \
 typedef struct { \
        logic [ADDR_MSB``:0] address; \
        logic [DATA_MSB:0] data; \
    } `SIMPLE_STRUCT(NAME)

Затем в каком-то месте вашего кода вы можете определить нужную структуру (ы):

`SIMPLE_STRUCT_DEF(narrow, 7, 31)
`SIMPLE_STRUCT_DEF(wide, 15, 63)

А затем используйте его там, где вам это нужно, используя только имя:

`SIMPLE_STRUCT(narrow) narrow1, narrow2;
narrow1.data = 0;
narrow2 = narrow1;
...

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

Пример есть на http://www.doulos.com/knowhow/sysverilog/tutorial/interfaces/

У меня был тот же вопрос, и мой коллега предложил следующее:

//defines.sv:

`ifndef MY_DEFINES
  `define MY_DEFINES
     `define TYPEDEF_VECTOR_T typedef logic [WIDTH-1:0] vector_t;
`endif

//mod_sub.sv:

`include "defines.sv"
module mod_sub #(parameter WIDTH = 32);
...
   `TYPEDEF_VECTOR_T
   vector_t some_reg;
...
endmodule

//mod_top.sv:

module mod_top;

   mod_sub #(.WIDTH(8))  mod_sub8;
   mod_sub #(.WIDTH(64)) mod_sub64;

endmodule

Я считаю, что пакеты System Verilog разрабатываются раньше любых модулей, поэтому их содержимое не может быть изменено параметрами во время компиляции.

Я бы не сказал, что это недостающая функция. То, что вы пытаетесь сделать, было сделано с помощью макросов в Verilog на протяжении десятилетий. Проблема в том, что вы должны быть довольно уникальными в том, как вы называете вещи, чтобы избежать конфликтов между пакетами. Это неприятно, но работает.

Параметры немного другие. Они предназначены для настройки от экземпляра к экземпляру (например, универсальные шаблоны VHDL). Либо на модулях для логики, либо на классах для стендов. Моя единственная критика в их адрес заключается в том, что как только вы начинаете их использовать, они имеют тенденцию распространяться по всей вашей иерархии, а синтаксис не совсем компактный. Тем не менее, очень мощный и отлично подходит для повторного использования кода.

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

См. Раздел 5.6.7 в: http://www.sutherland-hdl.com/papers/2013-SNUG-SV_Synthesizable-SystemVerilog_paper.pdf

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

Может ли кто-нибудь убедиться, что это жизнеспособное решение? Спасибо!