Добрый день!

Передо мной стоит задача написать систему для обнаружения модемного сигнала. Поскольку частота дискретизации низкая (9600 Гц), а ресурсов в ПЛИС немного (ПЛИС Cyclone III 25K ячеек, из которых треть занята DDC'ом), необходимо активно применять расшаривание ресурсов. Это приводит к необходимости соединения управляющих автоматов, нескольких массивов памяти и аппаратных вычислителей в единую систему. Опишу примерный состав этой системы:
1) Основной управляющий КА (возможно впоследствие будет заменён на простенький самописный софт-процессор).
2) Мост на шину EBIU процессора Blackfin. Должен иметь абсолютный приоритет на моей шине.
3) Специализированные процессоры (FIR, FFT), которые должны управляться главным КА (то есть иметь SLAVE-интерфейс), но при этом иметь доступ к памяти в качестве MASTER'а. Причём доступ к памяти должен быть в виде burst-транзакций.
4) Аппаратные вычислители (CORDIC-процессор, NCO, DIV, SQRT), являющиеся SLAVE'ами на шине (обмен данными через регистры, вписанные в общее адресное пространство шины).
5) Несколько секций памяти, каждая со своим AAU (address ariphmetic unit) для обеспечения кольцевой адресации (circle pointer) с выбранным шагом инкремента. AAU также должен управляться по шине.

Все компоненты системы самописные (на SystemVerilog), поэтому интерфейс к ним можно прикрутить любой. Саму шину планирую описать в виде SystemVerilog-интерфейса с параметризованным количеством Master'ов и Slave'ов.
Вопрос состоит в том, какой стандарт шины больше всего подходит для моей системы.
Ещё вопрос - можно ли где-нибудь достать в качестве примера открытые исходники AMBA AXI. Wishbone на opencores представлен очень широко, а адекватных примеров AMBA я не нашёл...

Решил пока начать с wishbone.
Для любителей красивых решений на SystemVerilog - параметризованный Wishbone INTERCON для N мастеров и M слейвов в виде SV-интерфейса в аттаче. Конструктивная критика, багрепорты и предложения приветствуются.

Из того что видно не вооруженным глазом.
1. Есть задержка на арбитраж.
2. Арбитр приоритетный, что в сложной системе чревато дедлоками.
3. Есть вероятность залипа на арбитраже старшего мастера, если он запросил BLOCK WRITE/READ. В связи с этим вы его тестировали хоть как то ?

ЗЫ. 4. Не применимо на Xilinx (вивадо/симплифай не поддерживают генерейты модпортов).

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

UPD2. нет обработки ошибок декодирования адреса. арбитра можно навечно повесить адресацией не туда.

des00
Да, это недостаток, согласен. Попробую убрать.
Я специально так сделал, для моей системы такой удобнее, так как устройства в ней должны обслуживаться строго в соответствии с заданным приоритетом. Возможно, потом сделаю round-robin как вариант generate'a, если вдруг понадобится.
Да, я тестировал в QuestaSim систему с двумя мастерами и двумя слейвами, причём как в RTL, так и в gate (нетлист из квартуса 13.1). Не залипал ни разу ни на block, ни на single.
Насчёт ксайлинкса не знаю, у нас есть только cyclone III.
Ни разу не видел таких... Где можно почитать?
Ok, my bad...

Это не недостаток, это меганедостаток. Классический вишбон и так тормоз: 2 такта на транзакцию, так еще вы тратите 1 такт на активацию арбитража и 1 такт на выход. Т.е. вы провалили шину в 2 раза (!!!) относительно классической на пустом месте.

Не верю, либо вы сформировали удобный именно вам тест (т.е. что бы работало), либо вам повезло в рандомном тестировании (вы не доконца рандомизировали тест).

И вот почему :

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

ЗЫ. для вашей системы больше подходят Stream-Based интерфейсы на основе crossbarr switch.


любой даташит на соксистемы(микропоцессоры) там все просто, есть базовый адрес, есть маска, ну а дальше просто

if ((addr & ~pS_ADDR_MASK[i]) == pS_ADDR_BASE[i]) bla-bla-bla

синтезатор выкидывает маскированные биты адреса оставляя только нужные. Правда тут не совсем эффективно расходуется карта адресов, но тем не менее декодирование - банальные 1-2 люта

PS. Посмотрите в конце этой темы, может почерпнете идей

des00
Да, приоритетный мастер всегда захватывает шину, если она свободна, в ущерб другим. Так в том и суть, что blackfin и main FSM имеют приоритет, так как они редко раздают короткие команды сопроцессорам. А всякие там FIR, FFT, DMA и им подобные с их длинными бурстами должны уступать.

Это меня тоже заинтересовало, когда я читал стандарты на wishbone и AXI. Там вроде как указано, что wishbone поддерживает crossbar, но примеров вообще никаких, рассматривается только point2point и shared bus. Насчёт stream-based интерфейсов у меня есть сомнения, так как он однонаправленный, как я понял из стандарта на AXI. А crossbar memory mapped - это как раз то что мне нужно.

вот какой нить ДМА сядет на шину, прерываясь на блекфин и main FSM, а FIR/FFT будут курить бамбук. Делайте crossbar switch для быстрого интерконнекта + shared bus для шины управления.

des00
Благодарю за ссылку на ваш вариант интерконнекта, буду изучать и исправлять свою сырую альфу, потом выложу чего получилось. Уж больно удачная концепция SV-интерфейсов, странно что почти никто не применяет их на практике для синтеза RTL.

вот только с переносимостью плохо.

ЗЫ. а вариант разделения шин продумайте, так кстати многие поступают (та же xilinx шина MCB или разделение ABMA APB и AMBA AHB/AXI)

По поводу шины - сказать нечего, а по следующим позициям кое-что имеется:
Как-то занимался аппаратным за один такт CORDIC (алгоритм Волдера) для arctg(X/Y) и sqrt(X*X +Y*Y). Для Cyclone III получилось 70 нс для 16-разрядных данных.
Также были аппаратные (матричные, тоже за один такт) DIV и SQRT.
По поводу простого софт-процессора, есть 8-разрядный miniByte с системой из 32 команд, для Cyclone III с тактом 100МГц.

2 ~Elrond~

Может есть смысл оптимизировать как-то эту часть проекта? Не понятно откуда такой расход ресурсов, если только у вас не целая куча каналов. Для узкой полосы на Cyclone III FIR для двух квадратур ~500-600 LE, 8 DSP x9 и немного памяти... Всё остальное явно меньше.

А концепция, предлагаемая альтерой, имеется ввиду Avalon неприемлима в принципе? И размещать и интерконектить всю систему в Qsys? Кроме того свои модули можно делать с поддержкой AXI Lite/AXI Stream, которые просты в реализации (полноценная AXI вам я думаю не нужна), а QSys делает автоматическое согласование шины AXI и Avalon. При этом вы можете сделать как собственный хардверный мастер, так и поставить софтовый проц. Для вашей полосы можно на обычном ниосе делать обработку верхнего уровня, векторные вычисления (Фурье, фильтрация) поддержать в железе, а-ля сопроцессоры.

2 Serhiy_UA

Можно и Nios II поставить, благо есть урезанная версия, если ресурс ограничен.

А можно доку про это какую нибудь, или пример реализации?

Основная книга - Байков В. Д., Смолов В. Б. Аппаратурная реализация элементарных функций в ЦВМ.
Пример выложу в ближайшие дни.

а чем это отличается от обычного кордика с убранными конвейерными регистрами ?

Serhiy_UA
Это получается довольно длинная комбинационная цепь, для которой в таймквесте нужно задавать multipath. К тому же, много ресурсов съест. Поэтому я написал итеративные варианты кордика, деления и корня. Не так уж часто они нужны. А если нужны часто, или частота высокая - то развернуть в конвейер всегда можно (для кордика я это делал, для остальных не было необходимости). Свой вариант реализации я недавно выкладывал на форум. Спасибо, гляну. 1) DDS на основе LUT с коррекцией через разложение в ряд Тейлора первого порядка - 180 ячеек, 1M9K и 6 DSP.
2) CIC дециматор на 250 для двух квадратур (5 секций) - 1300 ячеек.
3) FIR resampler 320 -> 48 kHz 510 порядка для двух квадратур (32-битная арифметика) 600 ячеек, 8 DSP, 4 M9K.
4) 4-х канальная НЧ-часть для двух квадратур, 32-битная арифметика (частотный сдвиг -> дециматор на 5 90 порядка -> фильтр-селектор до 128 порядка -> частотный сдвиг, всё это для 4 каналов, плюс пятый канал-частотомер для измерения допплеровского сдвига) - 3000 ячеек, 8 DSP, 13 M9K. По ячейкам оптимизировать здесь можно, я знаю. Займусь как время будет.
5) есть ещё всякие интерфейсные модули, помимо DDC. Ещё 2000 ячеек.
Мне не нравится использовать GUI и скриптовые генераторы. Я придерживаюсть такого подхода, что нужно досконально знать, что и как в системе работает, ну и люблю красивый код, в котором нет ничего лишнего. Альтеровские генераторы по этому критерию не катят, единственное что я из них на данный момент использую - генератор для floating point functions. Насчёт ниоса я вообще сомневаюсь, слишком уж он огромен и не подходит для DSP. Вообще для систем без внешней памяти 32-bit general purpose CPU - явное расточительство в плане ценной памяти ПЛИС. Если у вас есть опровергающие доводы - готов их выслушать.
Вот в этой теме, в конце, выкладывали CORDIC for dummies, ну и мой вариант кордика на SV, сделанный по этой статье. http://electronix.ru/forum/index.php?showtopic=126481

Ничем. Большая комбинационная схема, где все выполняется за один такт, в данном случае 70 нс и без транспортных задержек на конвейере. Просто схема составлена на verilog с применением generate, для сокращения записи....
Если засоряю тему, то ~Elrond~ пусть извинит, прекращаю (свое могу почистить).

Много. 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 займёт та система, о которой эта тема. Для нас проблема.

Например,
Нажмите для просмотра прикрепленного файла

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

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

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 будут держать весь берст.

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

Есть вопрос по modport expressions. В документе Нажмите для просмотра прикрепленного файла говорится, что они не поддерживаются квартусом. Я пробовал синтезировать простейший интерфейс с expressions, вроде все проходит, но этот пункт в документе и ворнинги насторожили. Поэтому пока их выпилил из своего проекта. Может кто-нибудь просветить как на самом деле обстоят дела? Мб документ уже устарел (2010 год) и поддержку уже добавили?

serjj
Да, говорят что не поддерживаются, но на самом деле всё работает идеально как минимум с версии 9.1 (на более ранних не проверял). Причём без всяких варнингов. В 9.1 не поддерживается импорт тасков и функций, в 11.1 уже всё норм. Попробуйте сделать какую-нибудь простую систему из пары мастеров и пары слейвов на том интерконнекте, который я выложил в предыдущем посте.