[serjj1333 0]

CIC дециматор на 250 для двух квадратур (5 секций) - 1300 ячеек.

Много. 600 LE + 10 памяти. Можно еще делать без памяти, но там получается (если не изменяет "память", 2000+ LE).

В дециматоре использовать везде 32 битную арифметику избыточно, требуемая разрядность считается исходя из разрядности АЦП и суммарной DECIM_RATE. При этом она растет постепенно, так на входе CIC она меньше чем на входе FIR, что позволяет сыкономить ресурс и избежать провалов по времянке.

Насчёт ниоса я вообще сомневаюсь, слишком уж он огромен и не подходит для DSP. Вообще для систем без внешней памяти 32-bit general purpose CPU - явное расточительство в плане ценной памяти ПЛИС.

На 25ке, если нет внешней памяти, то возможно. Для ниоса нужно ставить хотя бы 64 кбайта памяти. Впрочем поставить DDR2/3 не проблема обычно... А по поводу DSP задач - для полос до сотен кГц вполне сносно выполняет вычисления, проверено на практике. Его задача в таком подходе заниматься пост-обработкой, никто не предлагает его грузить векторными рассчетами.

[ElrondTelvanni 0]

serjj

Много. 600 LE + 10 памяти. Можно еще делать без памяти, но там получается (если не изменяет "память", 2000+ LE).

CIC-дециматорна блочной памяти? О_о Первый раз такое слышу. Где-нибудь есть примеры таких? У меня сделан обычный 5-секционный с 24-битными входами и 32-битными выходами, получается 1300 ячеек для двух каналов. 32-битная арифметика используется так как 18-битной для приёмника мало (у нас АЦП 16 бит, 80 МГц, при децимации нужно наращивать разрядность пропорционально сужению полосы). Вариант с 24 битами был, разрядности не хватало, а по ресурсам получалось ненамного меньше.

На 25ке, если нет внешней памяти, то возможно. Для ниоса нужно ставить хотя бы 64 кбайта памяти.

У нашей ПЛИС всего 66к памяти. Из них 20 занимает 4-хканальный DDC, и минимум 10 займёт та система, о которой эта тема. :)

Впрочем поставить DDR2/3 не проблема обычно...

Для нас проблема.

[serjj1333 0]

CIC-дециматорна блочной памяти?

Например,

cic_mem.zip

[ElrondTelvanni 0]

Гуру системного дизайна, к вам есть ещё несколько вопросов:

1) что вы можете сказать об использовании Qsys для интеграции самописных компонентов (то есть системы без NIOS и других альтеровских IP)? Что вы выбрали для себя, самописный интерконнект на основе, например, стандарта wishbone или же Qsys с интерконнектом на основе авалона?

2) может ли Qsys генерировать AXI4-интерконнект вместо авалона?

3) Какой из способов подключения вычислительных модулей к системе наиболее удачный? Я пока что использую mutex'ы для безопасного подключения слейвов к нескольким мастерам, а сигнализация об окончании вычислений через отдельный сигнал rdy от каждого слейва. Считаю этот подход слишком медленным, неудобным и некрасивым, есть ли альтернатива?

4) Использовал ли кто-нибудь концепцию mailbox'ов в RTL-синтезе систем? Насколько это удачная идея?

Изменено 16 марта, 2015 пользователем ~Elrond~

[serjj1333 0]

А советы от не-гуру принимаются? :rolleyes:

что вы можете сказать об использовании Qsys для интеграции самописных компонентов (то есть системы без NIOS и других альтеровских IP)? Что вы выбрали для себя, самописный интерконнект на основе, например, стандарта wishbone или же Qsys с интерконнектом на основе авалона?

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

может ли Qsys генерировать AXI4-интерконнект вместо авалона?

Вообще они идут в эту сторону, но пока как то медленно. К слову, Qsys осуществляет автоматическое согласование AXI4 и Avalon, т.к. у HPS например AXI4, но он без проблем соединяется с авалоновскими ядрами, для пользователя соединение прозрачно. Но это касается MM интерфейсов, стримы я не проверял даже.

 

[ElrondTelvanni 0]

Попробовал сгенерить систему из 2 мастеров и 3 слейвов в Qsys. Он нафлудил over9000(это не преувеличение) строк кода для интерконнекта. Куда ему столько? Как в этом всём разбираться, если что-то пойдёт не так? Не знаю. Не доверяю я столь многословному коду... Остаюсь на своей реализации вишбона, где 250 строк на всё. ))

[serjj1333 0]

Qsys интерконнект это готовый продукт, если что-то идёт не так это с высочайшей вероятностью проблема интерфейса на стороне кастомной логики, а не интерконнекта. И никто не лазит внутрь смотреть что же там такое. У всех сред есть свои ньюансы и подводные камни, но на форуме очень многие используют Qsys/SOPC и если что-то пойдет не так, вам смогут подсказать и направить на путь решения проблемы. Кроме того еще есть форум altera. Если вы будете делать собственное решение, то этот Путь воина придётся проходить самостоятельно :rolleyes:

[ElrondTelvanni 0]

des00

Возник вопрос по работе wishbone: при работе в pipelined режиме какой сигнал должен использовать мастер, чтобы начать инкрементировать адрес при чтении? На первом такте он поднимает cyc и stb, выставляет адрес и sel. По идее, в pipelined режиме он должен на следующий такт инкрементировать адрес, но в то же время, не дождавшись ack (который придёт только через <latency> тактов), он не имеет права это делать. Как мастер должен поступать в этой ситуации?

[Timmy 1]

des00

Возник вопрос по работе wishbone: при работе в pipelined режиме какой сигнал должен использовать мастер, чтобы начать инкрементировать адрес при чтении? На первом такте он поднимает cyc и stb, выставляет адрес и sel. По идее, в pipelined режиме он должен на следующий такт инкрементировать адрес, но в то же время, не дождавшись ack (который придёт только через <latency> тактов), он не имеет права это делать. Как мастер должен поступать в этой ситуации?

У вас некоторая путаница: pipelined mode - это более новый продвинутый режим, в котором используется сигнал stall, вместо ack, тогда мастер может не ждать ack, у вас этого сигнала нет. В классическом берсте мастер может выставлять новый адрес/данные только в ответ на активный ack, в результате как минимум один такт в начале берста бесполезно теряется. Об этом такте не надо специально беспокоиться, оно само получается. Берст поддерживается в основном за счёт действий слэйва, который получает право(и использует его:)) держать активный ack непрерывно, увидев, что мастер хочет берст.

[ElrondTelvanni 0]

Timmy

У меня в первой версии были stall и lock, но я их повыпиливал, так как не понял зачем они мне нужны. :) Stall нужен, как я понял из стандарта, чтобы слейв мог приостанавливать бёрст. Но как он поможет решить проблему, которую я описал?

[Timmy 1]

Timmy

У меня в первой версии были stall и lock, но я их повыпиливал, так как не понял зачем они мне нужны. :) Stall нужен, как я понял из стандарта, чтобы слейв мог приостанавливать бёрст. Но как он поможет решить проблему, которую я описал?

Правила поведения при берсте для мастера ничем не отличаются от оных при одиночном обмене(точнее, при блочном). За исключением того, что мастер выставляет уведомления о берсте на CTI. Это и есть ответ на ваш вопрос. Адрес можно инкрементировать только в ответ на ack, как обычно. И при этом не расчитывать, что ack будут держать весь берст.

Изменено 20 марта, 2015 пользователем Timmy

[des00 25]

при работе в pipelined режиме какой сигнал должен использовать мастер, чтобы начать инкрементировать адрес при чтении? .... Как мастер должен поступать в этой ситуации?

Если речь про спецификацию b3, то ЕМНИП мастер работает как классический мастер. Т.е. адрес изменяется по ack, pipeline фича это фича слейва, т.е. слейв может не ждать новой фазы адреса, а генерировать адреса внутри. В основном это помогает при чтении, максимум прочитаете лишнее слово (правда с ФИФО есть особенности). А вот запись по прежнему, если есть cyc & stb & we

 

У вас некоторая путаница:

есть 2 реализации стандарта b3 и b4 в них режимы реализованы по разному и разные название и назначение сигналов.

 

И еще до кучи. В сложной системе pipelined feedback должен быть поддержан арбитром шины, иначе он может и умом тронуться, увидев хвосты ack ов

[ElrondTelvanni 0]

des00

Я только B4 читал. И там в пункте 3.3.1 block read cycle, в описании pipelined mode, не рассмотрена ситуация, при которой мастеру доступ к шине даётся не сразу. В этом случае ему надо знать момент, в который происходит передача ему права доступа. В принципе, можно как-то решить этот вопрос, заведя на мастера сигнал grant от арбитра, но насколько это соответствует стандарту, и почему не рассмотрено в нём?

[des00 25]

Я только B4 читал. И там в пункте 3.3.1 block read cycle, в описании pipelined mode, не рассмотрена ситуация, при которой мастеру доступ к шине даётся не сразу. В этом случае ему надо знать момент, в который происходит передача ему права доступа. В принципе, можно как-то решить этот вопрос, заведя на мастера сигнал grant от арбитра, но насколько это соответствует стандарту, и почему не рассмотрено в нём?

мой ответ был про b3. посмотрел b4, судя по всему они разгрузили ack, сигналом stall + убрали необходимость городить мультиплексор адреса (сигнал с шины + сигнал со счетчика) в слейве. умно. В вашем случае ваш интерконнект должен поддерживать pipelined режим, т.е. пока мастер не получит доступа к слейву, он должен быть остановлен.

 

[ElrondTelvanni 0]

Выкладываю новую версию своего интерконнекта. Учёл все замечания, кроме декодера (нравится мне регистровое окно, а выше 100 МГц всё равно работать не нужно). Добавил выбор между priority и round-robin арбитрами, проверку ошибок декодирования адреса, арбитр без задержки, сигнал stall, и таски для удобного доступа к функциям чтения/записикак из синтезируемых модулей, так и из тестбенчей. Кому нравится такой подход к реализации интерконнекта - пользуйтесь, буду благодарен за багрепорты, отзывы и пожелания. :)

wb_if.zip