Использование Интерфейсов 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]

Никто не сталкивался или непонятен вопрос? =\

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

Может для этого есть более удобный и понятный инструментарий чем интерфейсы? посоветуйте...
иначе проект станет очень неудобным из-за стремительного обрастания сигналами. =\ а я до этого доводить не хочу.

[IL-76]

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

[bark]

Но вопрос остаётся открытым. как сделать чтобы генерировало модули с интерфейсами?

Как в текстовом виде по-людски удобно генерировать и вставлять меги типа PLL, памяти и т.п.?
в блок диаграмме такие вещи вставляются удобно и понятно.

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

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

[vadimuzzz]

Как в текстовом виде по-людски удобно генерировать и вставлять меги типа PLL, памяти и т.п.?

пишется элементарная обертка к мегафункции, делов-то. а память так вообще напрямую из кода инферится.

[bark]

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

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

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

[vadimuzzz]

пример обертки:

CODE

module scfifo_wrapper
#(parameter depth_log = 9, dw = 12, showahead = "ON")
(
input aclr,
input clock,
input [dw-1:0] data,
input rdreq,
input wrreq,
output [dw-1:0] q
);
scfifo scfifo_component
(
.aclr(aclr),
.clock(clock),
.data(data),
.rdreq(rdreq),
.wrreq(wrreq),
.q(q),
.almost_empty(),
.almost_full(),
.empty(),
.full(),
.sclr(),
.usedw()
);
defparam
scfifo_component.add_ram_output_register = "OFF",
scfifo_component.intended_device_family = "Cyclone III",
scfifo_component.lpm_numwords = 2**depth_log,
scfifo_component.lpm_showahead = showahead,
scfifo_component.lpm_type = "scfifo",
scfifo_component.lpm_width = dw,
scfifo_component.lpm_widthu = depth_log,
scfifo_component.overflow_checking = "ON",
scfifo_component.underflow_checking = "ON",
scfifo_component.use_eab = "ON";
endmodule

пример памяти (смотрите в квартус-хендбуке главу Recommended HDL Coding Styles
)

CODE

module sc_wr_ram
#(parameter num_words = 256, dw = 8)
(
input clk,
input [dw-1:0] d,
input [$clog2(num_words)-1:0] write_address,
input [$clog2(num_words)-1:0] read_address,
output reg [dw-1:0] q,
input we
);
localparam aw = $clog2(num_words);
reg [dw-1:0] mem [2**aw-1:0];
integer i;
initial begin
for (i = 0; i < 2**aw; i++)
mem[i] = '0;
end
always_ff @(posedge clk)
begin
if (we)
mem[write_address] = d;
q = mem[read_address];
end
endmodule

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

[bark]

Спасибо за разъяснения.
ещё вопрос:
вот все эти параметры scfifo.. откуда их брать? сами строки

defparam

scfifo_component.add_ram_output_register = "OFF",
scfifo_component.intended_device_family = "Cyclone III",
scfifo_component.lpm_numwords = 2**depth_log,
scfifo_component.lpm_showahead = showahead,
scfifo_component.lpm_type = "scfifo",
scfifo_component.lpm_width = dw,
scfifo_component.lpm_widthu = depth_log,

это надо просто знать или где-то заготовки есть?

я это похоже тоже где-то упустил.


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

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

[vadimuzzz]

это надо просто знать или где-то заготовки есть?

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

[IL-76]

Как в текстовом виде по-людски удобно генерировать и вставлять меги типа PLL, памяти и т.п.?
в блок диаграмме такие вещи вставляются удобно и понятно.

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

Если вы нужную функцию генерите МегаВизардом, то делать вообще ничего не надо. Визард, наряду с bsf файлом для графики, генерит и готовые файлы для вставки уже сконфигурированных модулей в текстовые файлы.

Если генерите мегафункции на Верилоге, то смотрите к примеру файлы, заканчивающиеся на _inst.v. Они, собственно говоря, для этого и предназначены - чтобы не надо было все параметры в общем файле прописывать.

[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

[des00]

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

мыши плакали, кололись, но продолжали жрать кактус (с)

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

[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]

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

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

[Krys]

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

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

[dxp]

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

Это всё "детские" болезни. Пройдёт.

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

Когда модулей будет реально много, то никакой наглядности там не будет. Наглядность получается, когда можно выделить функционально законченные блоки и показать их связи, причём блоков должно быть в пределах десятка, иначе всё это "размывается", загромождается и сам чёрт ногу сломит. Поэтому куда реальнее набросать структурную схемку проекта (или его частей, которые этого заслуживают) в каком-нить редакторе вроде Visio, и по ней уже писать код. А в Top'е просто описать межсоединения модулей. Только делать это аккуратно, с отступами. И, кстати, поиск (и замену) в тексте делать куда удобнее и средства для этого более развитые.

[des00]

И, кстати, поиск (и замену) в тексте делать куда удобнее и средства для этого более развитые.

а уж до чего ляпота смотреть в системе контроля версий кто и что делал %)

[warrior-2001]

а уж до чего ляпота смотреть в системе контроля версий кто и что делал %)

Не вижу проблем смотреть то же самое для графики. Средства Mentor типа HDL Designer позволяют это делать. Осталось дождаться нормальной графики для SV.
Ох не люблю я холивары, но всё же...
Для себя остановился на таком подходе - верхний уровень иерархии - всегда графика. Кол-во блоков на верхнем уровне должно соответствовать структурной схеме конфигурации ПЛИС.
Далее - на усмотрение разработчиков этих блоков. При правильном структурированном подходе глубина иерархии 12 - не так уж и страшно.

[Krys]

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

Согласен. И именно при таком условии мы это используем.

[bark]

Все тут правы. )
видно что все люди не по одному десятку проектов написали.

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

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

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

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

но вообще сейчас новые мелко-проекты стараюсь начинать с кода а не bsf, дабы оценить возможности "тёмной" силы )
удобства от этого окнечно тоже есть свои.

[dxp]

Ещё один минус графического ввода - это привязка к конкретному специализированному инструменту. Например, Active-HDL. А я вот слез с него с третьей попытки (о чём не жалею ни разу) на квесту - и чтоб я делал, если бы у меня часть проектов были в графике?

[alexadmin]

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

Если действительно хочется generate в графике, то посмотрите на HDL Designer - он позволяет делать if generate и loop generate специальными рамочками. Изврат редкий, но работает ;-)

Мне вот реально не хватает в графике (как квартуса, так и HDL Designer) возможности комментирования. Не в смысле написать поясняющий текст, а в плане "закомментировать" участок кода (картинки), так, чтобы она никак не обрабатывалась синтезатором, но была легко доступна при необходимости.

[bark]

alexadmin, можно отключать входы/выходы такого блока. тогда квартус, например, выкинет блок из проекта при оптимизации.

dxp, на основе графики можно сгенерировать код. делов на пол часа и проект переделывается полностью с графики на код.
активHDL вообще очень вроде любил всякие генерации кодов на основе графики. (я кстати когда-то студентом стажировался в Алдеке =) )

[warrior-2001]

Если действительно хочется generate в графике, то посмотрите на HDL Designer - он позволяет делать if generate и loop generate специальными рамочками. Изврат редкий, но работает ;-)

Мне вот реально не хватает в графике (как квартуса, так и HDL Designer) возможности комментирования. Не в смысле написать поясняющий текст, а в плане "закомментировать" участок кода (картинки), так, чтобы она никак не обрабатывалась синтезатором, но была легко доступна при необходимости.

Странный пост. Вы же сами написали, что " HDL Designer - он позволяет делать if generate и loop generate специальными рамочками. " Вот возьмите, обведите картинку рамочкой и поставьте IF const_1 = 0 GENERATE .
Вот вам и комментирование участка кода.
Нередко, для того, чтобы сделать универсальный IP блок необходимо по пол схемы через if generate делать. И ничего. А если кому-то понадобится чистый код - он генерится автоматом.
Вообще вопрос удобства настолько индивидуален, что спорить об этом бесполезно. Лучше делиться тонкостями работы с тем или иным САПРом.

[alexadmin]

Странный пост. Вы же сами написали, что " HDL Designer - он позволяет делать if generate и loop generate специальными рамочками. " Вот возьмите, обведите картинку рамочкой и поставьте IF const_1 = 0 GENERATE .
Вот вам и комментирование участка кода.

Неравнозначно. Конструкции внутри рамочек условной генерации обрабатываются как обычный код. Т.е. синтаксически неверная картинка вызовет ошибку компиляции (генерации VHDL/Verilog текста). Ровно то же самое, как кусок некорректного кода попытаться в VHDL огородить с помощью IF false GENERATE, вместо того, чтобы закомментировать через "--".