Обработка параметризации в пакетах SystemVerilog - PullRequest
Новая
       9

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

10 голосов
/ 09 октября 2010

SystemVerilog добавил пакеты для предоставления пространств имен для общих частей кода (функций, типов, констант и т. Д.). Но поскольку пакеты не создаются, они не могут быть параметризованы, поэтому работа с параметризованными членами проблематична. На практике я нашел это довольно ограничивающим, поскольку очень часто мои пользовательские типы имеют некоторые параметры, определяющие ширину поля и т. Д.

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

package my_pkg;
    parameter ADDR_MSB = 7;
    parameter DATA_MSB = 31;

    typedef struct {
        logic [ADDR_MSB:0] address;
        logic [DATA_MSB:0] data;
    } simple_struct_t;

endpackage

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

Ответы [ 7 ]

3 голосов
/ 01 сентября 2013

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

`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;
...
3 голосов
/ 23 октября 2010

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

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

3 голосов
/ 17 октября 2010

Да, я согласен. Это недостающая особенность пакетов.

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

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

2 голосов
/ 19 марта 2011

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

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

1 голос
/ 18 июля 2013

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

// определяет.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 разрабатываются до каких-либо модулей, поэтому их содержимое не может быть изменено параметрами во время компиляции.

0 голосов
/ 03 сентября 2014

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

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

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

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

0 голосов
/ 08 ноября 2010

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

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

...