Много. 600 LE + 10 памяти. Можно еще делать без памяти, но там получается (если не изменяет "память", 2000+ LE).
В дециматоре использовать везде 32 битную арифметику избыточно, требуемая разрядность считается исходя из разрядности АЦП и суммарной DECIM_RATE. При этом она растет постепенно, так на входе CIC она меньше чем на входе FIR, что позволяет сыкономить ресурс и избежать провалов по времянке.

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

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

Например,
 cic_mem.zip ( 3.18 килобайт ) Кол-во скачиваний: 76

Гуру системного дизайна, к вам есть ещё несколько вопросов:
1) что вы можете сказать об использовании Qsys для интеграции самописных компонентов (то есть системы без NIOS и других альтеровских IP)? Что вы выбрали для себя, самописный интерконнект на основе, например, стандарта wishbone или же Qsys с интерконнектом на основе авалона?
2) может ли Qsys генерировать AXI4-интерконнект вместо авалона?
3) Какой из способов подключения вычислительных модулей к системе наиболее удачный? Я пока что использую mutex'ы для безопасного подключения слейвов к нескольким мастерам, а сигнализация об окончании вычислений через отдельный сигнал rdy от каждого слейва. Считаю этот подход слишком медленным, неудобным и некрасивым, есть ли альтернатива?
4) Использовал ли кто-нибудь концепцию mailbox'ов в RTL-синтезе систем? Насколько это удачная идея?

Сообщение отредактировал ~Elrond~ - Mar 16 2015, 20:08

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

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

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

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

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

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

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

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

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

Сообщение отредактировал Timmy - Mar 20 2015, 12:04

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


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

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

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

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

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