[ElrondTelvanni 0]

Добрый день!

 

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

[ElrondTelvanni 0]

Решил пока начать с wishbone.

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

wb_if.zip

[des00 27]

Конструктивная критика, багрепорты и предложения приветствуются.

Из того что видно не вооруженным глазом.

1. Есть задержка на арбитраж.

2. Арбитр приоритетный, что в сложной системе чревато дедлоками.

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

 

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

 

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

 

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

[ElrondTelvanni 0]

des00

1. Есть задержка на арбитраж.

Да, это недостаток, согласен. Попробую убрать.

2. Арбитр приоритетный, что в сложной системе чревато дедлоками.

Я специально так сделал, для моей системы такой удобнее, так как устройства в ней должны обслуживаться строго в соответствии с заданным приоритетом. Возможно, потом сделаю round-robin как вариант generate'a, если вдруг понадобится.

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

Да, я тестировал в QuestaSim систему с двумя мастерами и двумя слейвами, причём как в RTL, так и в gate (нетлист из квартуса 13.1). Не залипал ни разу ни на block, ни на single.

Насчёт ксайлинкса не знаю, у нас есть только cyclone III.

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

Ни разу не видел таких... Где можно почитать?

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

Ok, my bad...

Edited March 10, 2015 by ~Elrond~

[des00 27]

Да, это недостаток, согласен. Попробую убрать.

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

Да, я тестировал в QuestaSim систему с двумя мастерами и двумя слейвами, причём как в RTL, так и в gate (нетлист из квартуса 13.1). Не залипал ни разу ни на block, ни на single.

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

 

И вот почему :

// Arbiter
always_ff @(posedge clk_i or posedge rst_i) begin : arbiter
    if(rst_i)
        gnt <= '0;
    else
        if(|gnt)                        // gnt persists until master drops cyc_o
            for(int i=0; i<MNUM; i++) begin
                if(gnt[i])
                    gnt[i] <= cyc_o[i];
            end
        else                            // no master currently has gnt
            for(int i=0; i<MNUM; i++) begin
                if(cyc_o[i]) begin        // master i has priority
                    gnt[i] <= 1'b1;
                    break;
                end
            end
end : arbiter

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

 

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

 

Ни разу не видел таких... Где можно почитать?

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

 

if ((addr & ~pS_ADDR_MASK) == pS_ADDR_BASE) bla-bla-bla

 

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

 

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

[ElrondTelvanni 0]

des00

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

 

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

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

[des00 27]

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

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

[ElrondTelvanni 0]

des00

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

[des00 27]

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

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

 

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

 

[Serhiy_UA 1]

По поводу шины - сказать нечего, а по следующим позициям кое-что имеется:

1) Основной управляющий КА (возможно впоследствие будет заменён на простенький самописный софт-процессор).

. . . .

4) Аппаратные вычислители (CORDIC-процессор, NCO, DIV, SQRT),

Как-то занимался аппаратным за один такт CORDIC (алгоритм Волдера) для arctg(X/Y) и sqrt(X*X +Y*Y). Для Cyclone III получилось 70 нс для 16-разрядных данных.

Также были аппаратные (матричные, тоже за один такт) DIV и SQRT.

По поводу простого софт-процессора, есть 8-разрядный miniByte с системой из 32 команд, для Cyclone III с тактом 100МГц.

[serjj1333 0]

2 ~Elrond~

а ресурсов в ПЛИС немного (ПЛИС Cyclone III 25K ячеек, из которых треть занята DDC'ом)

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

Вопрос состоит в том, какой стандарт шины больше всего подходит для моей системы

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

 

2 Serhiy_UA

По поводу простого софт-процессора, есть 8-разрядный miniByte с системой из 32 команд, для Cyclone III с тактом 100МГц.

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

Как-то занимался аппаратным за один такт CORDIC (алгоритм Волдера) для arctg(X/Y) и sqrt(X*X +Y*Y). Для Cyclone III получилось 70 нс для 16-разрядных данных.

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

[Serhiy_UA 1]

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

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

Пример выложу в ближайшие дни.

 

[des00 27]

Как-то занимался аппаратным за один такт CORDIC (алгоритм Волдера) для arctg(X/Y) и sqrt(X*X +Y*Y). Для Cyclone III получилось 70 нс для 16-разрядных данных.

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

 

[ElrondTelvanni 0]

Serhiy_UA

Как-то занимался аппаратным за один такт CORDIC (алгоритм Волдера) для arctg(X/Y) и sqrt(X*X +Y*Y). Для Cyclone III получилось 70 нс для 16-разрядных данных.

Это получается довольно длинная комбинационная цепь, для которой в таймквесте нужно задавать multipath. К тому же, много ресурсов съест. Поэтому я написал итеративные варианты кордика, деления и корня. Не так уж часто они нужны. А если нужны часто, или частота высокая - то развернуть в конвейер всегда можно (для кордика я это делал, для остальных не было необходимости). Свой вариант реализации я недавно выкладывал на форум.

По поводу простого софт-процессора, есть 8-разрядный miniByte с системой из 32 команд, для Cyclone III с тактом 100МГц.

Спасибо, гляну.

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

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 ячеек.

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

Мне не нравится использовать GUI и скриптовые генераторы. Я придерживаюсть такого подхода, что нужно досконально знать, что и как в системе работает, ну и люблю красивый код, в котором нет ничего лишнего. Альтеровские генераторы по этому критерию не катят, единственное что я из них на данный момент использую - генератор для floating point functions. Насчёт ниоса я вообще сомневаюсь, слишком уж он огромен и не подходит для DSP. Вообще для систем без внешней памяти 32-bit general purpose CPU - явное расточительство в плане ценной памяти ПЛИС. Если у вас есть опровергающие доводы - готов их выслушать. :)

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

Вот в этой теме, в конце, выкладывали CORDIC for dummies, ну и мой вариант кордика на SV, сделанный по этой статье. http://electronix.ru/forum/index.php?showtopic=126481

[Serhiy_UA 1]

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

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

Если засоряю тему, то ~Elrond~ пусть извинит, прекращаю (свое могу почистить).