Добрый день!

Передо мной стоит задача написать систему для обнаружения модемного сигнала. Поскольку частота дискретизации низкая (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...

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

Это не недостаток, это меганедостаток. Классический вишбон и так тормоз: 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~ пусть извинит, прекращаю (свое могу почистить).