Использование Интерфейсов SV в Quartus BlockDiagramFile Опции

[bark]

Не могу Сгенерировать Символ модуля если у него в портах используется Интрефейс СистемВерилога.

Взялся за изучение системверилога. (до этого пользовал обычный).
хочу использовать Интерфейсы в своём проекте.

TOP проекта - bdf файл. ну т.е. блок-диаграм-файл.

описал тестовый модуль вида:

создаю один из текстовых фалйлов проекта *.sv

module processor (

// main_bus interface port
main_bus bus,

// other ports
input logic clock,
input logic resetN,
);

// ... // module functionality code
endmodule

в итоге есть несколько модулей. проект компилируется нормально.

НО!

теперь при попытке сгенерировать "символ файл" мне пишется ошибка:
Error (10016): Can't create symbol/include/instantiation/component file for module "processor" because port "bus" has an unsupported type

т.е. интерфейсы нельзя использовать при построении блок-схем или я что-то не так пользую?

З.Ы. Quartus 10.1

Сообщение отредактировал bark - Feb 7 2011, 12:24

[bark]

вобщем похоже что есть способ всё это скрестить.

попробую использовать структукы struct.
выполняет похожую функцию с некоторыми ограничениями.

на выходе из модуля собирать всё в шину суммарной ширины.
на входе модуля-потребителя снова разбивать в аналогичную структуру для сохранения удобства пользования.

Код

struct {
  logic    [7:0]     adr;
  logic    [15:0]    data;
  logic              rd;
  logic              wr;
    } bus;

wire [25:0] bus_out    = { bus.data, bus.adr, bus.rd, bus.wr };

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

Сообщение отредактировал bark - Feb 8 2011, 13:11

[Krys]

вобщем похоже что есть способ всё это скрестить.

попробую использовать структукы struct.
выполняет похожую функцию с некоторыми ограничениями.

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

Мы тоже так пытались сделать. Правда, в Active-HDL и для Xilinx. Проблема в том, что шина может содержать в себе только сигналы одного направления. Т.е. либо все выходы либо все входы. А вот в интерфейс можно было запихивать сигналы любой направленности. В случае с шинами придётся делать отдельно шину на вход, шину на выход, что уже приводит к обрастанию связями.

[bark]

Мы тоже так пытались сделать. Правда, в Active-HDL и для Xilinx. Проблема в том, что шина может содержать в себе только сигналы одного направления. Т.е. либо все выходы либо все входы. А вот в интерфейс можно было запихивать сигналы любой направленности. В случае с шинами придётся делать отдельно шину на вход, шину на выход, что уже приводит к обрастанию связями.

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

под весом авторитетных мнений потихоньку буду пытаться отказываться от bdf.

[Krys]

под весом авторитетных мнений потихоньку буду пытаться отказываться от bdf.

Я вот себе не представляю, как бы без графики соединял огромное количество блоков на верхнем уровне друг с другом... Застрелиться... Я для себя пока принял так: логику автомата описываю текстом на языке, а соединяю отдельные блоки всё равно в графике... Хоть какая-то наглядность...

[Postoroniy_V]

Я вот себе не представляю, как бы без графики соединял огромное количество блоков на верхнем уровне друг с другом... Застрелиться... Я для себя пока принял так: логику автомата описываю текстом на языке, а соединяю отдельные блоки всё равно в графике... Хоть какая-то наглядность...

А как Вы опишете в графике generate, при чём на пару сотен модулей внутри?

[bark]

А как Вы опишете в графике generate, при чём на пару сотен модулей внутри?

никто ведь не запрещает использовать вложения bsf в bsf.

у меня например прошлый проект был с очень развитой иерархией.

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

в итоге очень удобная и наглядная визуализация структуры проекта.
минусы конечно тоже свои есть... но удобство в этом есть вполне определённое.

[Postoroniy_V]

никто ведь не запрещает использовать вложения bsf в bsf.

у меня например прошлый проект был с очень развитой иерархией.

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

в итоге очень удобная и наглядная визуализация структуры проекта.
минусы конечно тоже свои есть... но удобство в этом есть вполне определённое.

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

[Krys]

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

В коде это тоже не очень красиво и не очень быстро. Да и в графике не так трудно подправить один порт.
У нас была необходимость выводить сигналы не напостоянно, а при отладке. Тогда мы, чтобы не переделывать графику, временно дописывали нужные порты прямо в коде. Когда отладка заканчивалась, достаточно было перегенерировать код из схемы - и всё возвращалось на пути своя.
А чтобы выводить сигналы напостоянно - это нам не требовалось, т.к. в сложных проектах необходимо заранее продумывать интерфейсы стыков между блоками