[jojo 0]

Обращение матриц на ПЛИС

 

Тут надо комплексную матрицу 16x16 обратить (эрмитову). Формат исходных данных int32, результат - не хуже float, лучше - double. Есть ли готовые мегафункции, не обязательно нелицензионные?

 

Если кто-то делал похожее, интересно, сколько заняло ресурсов и какое быстродействие получилось.

 

В нынешней реализации обращения на DSP используются квадратный корень и деление (вещественные), сложение, вычитание и умножение (комплексные).

 

Хочу уменьшить нагрузку на DSP и разместить обращение матрицы в относитильно защищенной от взлома ПЛИС.

[cdg 4]

ИМХО если не за 1 такт надо, то с ПЛИС и не стоит заморачиваться - дороже выйдет.

[jojo 0]

Да, я все больше убеждаюсь, что ПЛИС "дороже выйдет", в т.ч. при обращении матриц. Отсутствие похожих функций в Synplify DSP и Altera DSP Builder на ту же мысль наводит.

 

В Tiger Sharc получилось порядка 2*10^3 тактов для матрицы 16*16.

 

Тут теоретики обещают подсказать способ обращения, пригодный для ПЛИС, возможно, с завершающим этапом в процессоре. Отпишу сюда о результатах.

[cdg 4]

В пору аспирантской юности, помнится сталкивался с решением задачи обращения матриц очень большого размера, так там для обращеня использовали модифицированный алгоритм Гаусса с приведением матрицы к виду Вандермонда (давно это было могу и попутать, но точно в киевском политехе ребята над этой задачей бились :) )

[Harbour 0]

На плис проект будет работать все равно быстрее чем на любом супер-пупер DSP, вот только стоить он будет действительно дороже (затраты на HDL-программер 'а). Навскидку пару вариантов :

 

- можно из готового проекта на DSP наиболее муторные места сделать в железе (следует грамотно встроить все это дело в конвейер)

- использовать C-based FPGA design, возможно с последующей оптимизацией

[des00 25]

На плис проект будет работать все равно быстрее чем на любом супер-пупер DSP

 

Не факт, если алгоритм сугубо последовательный и не допускает параллелизма объектов или ветвей,

решение на ДСП будет более быстрое, т.к. тактовая частота дсп больше раза в 2-3 раза чем на ФПГА.

тут от алгоритма все зависит.

[Harbour 0]

Это правда если сравнивать современные DSP с доисторическими FPGA - сейчас получить >200Mhz/такт на каком-то cyc2 не проблема. Даже в случае отсутствия параллелизма, в FPGA pipeline более эффективный получится, так как нет лишних накладных расходов, которые присутствуют в заточенном под универсальные задачи DSP конвейере.

[dxp 53]

Это правда если сравнивать современные DSP с доисторическими FPGA - сейчас получить >200Mhz/такт на каком-то cyc2 не проблема.

В плане быстродействия cyc2 от cyc не особенно отличается, даже кое-где проигрывает. И на обоих можно и на 300 МГц разогнать. Только вот сложность логики, работающей на такой частоте, будет очень малой - не более одного уровня. Если же логику усложнить, то или тактовая сильно упадет, или конвейер придется городить, оптимизировать его. Тоже задача еще та.

 

Даже в случае отсутствия параллелизма, в FPGA pipeline более эффективный получится, так как нет лишних накладных расходов, которые присутствуют в заточенном под универсальные задачи DSP конвейере.

Какие такие универсальные задачи? Там заточенность под пересылку данных и арифметические операции - именно то, что и нужно. Что-то я очень сомневаюсь, что без параллелизма любой Cyclone обгонит тот же Blackfin@600MHz.

[jojo 0]

Думаю, по меньшей мере последние этапы обращения можно в ПЛИС разместить, где используется комплексная арифметика. Как я убедился, сумматоры и умножители (float, а лучше double) занимают сравнительно мало места.

 

Все это ради того, чтобы осложнить копирование устройства, не ради ускорения вычислений. У процессора медленная (100 МГц) внешняя шина, это портит картину.

 

 

Что делать с квадратным корнем и делением на него - мне пока непонятно. Их можно тоже реализовать в ПЛИС (Методом Ньютона-Рафсона, как в процессора). Собственно, если эти деление и корень сделать - останется только конечный автомат реализовать.

 

А деление и sqrt() (float/double)никто не делал? сколько места заняло?

 

 

Добавление: тут надо обогнать не Blackfin, а TigerSharc. В целых числах или с фиксированной точкой динамический диапазон мал будет. Несколько напрягает длина конвейера (5-7) мегафункций с плавающей точкой. Но и так сойдет.

Изменено 9 февраля, 2006 пользователем jojo

[Harbour 0]

Это правда если сравнивать современные DSP с доисторическими FPGA - сейчас получить >200Mhz/такт на каком-то cyc2 не проблема.

В плане быстродействия cyc2 от cyc не особенно отличается, даже кое-где проигрывает. И на обоих можно и на 300 МГц разогнать. Только вот сложность логики, работающей на такой частоте, будет очень малой - не более одного уровня. Если же логику усложнить, то или тактовая сильно упадет, или конвейер придется городить, оптимизировать его. Тоже задача еще та.

 

Даже в случае отсутствия параллелизма, в FPGA pipeline более эффективный получится, так как нет лишних накладных расходов, которые присутствуют в заточенном под универсальные задачи DSP конвейере.

Какие такие универсальные задачи? Там заточенность под пересылку данных и арифметические операции - именно то, что и нужно. Что-то я очень сомневаюсь, что без параллелизма любой Cyclone обгонит тот же Blackfin@600MHz.

Ну-ну ... хотите contest ? Алгоритм в студию (исходник на С например), я делаю на FPGA , Вы на фине. Учтите что данные еще в CPU ввести надо и вывести - а это в пересчете на наны - уйма времени, а FPGA не нуждается в прерываниях и ping-pong буферах, можно и через HPI, но что тогда с пайплайном будет ?

Универсальность, то бишь окаменелость, DSP конвейера в том что данные движутся кажный такт в строго определенных направлениях со строго определенной пропускной способностью, т.е. имеем например в каком-нить DSP 2 datapath'а по 256 бит да конвейер на 8 инструкций и кирдык - и вот берем мы наш несчастный алгоритм и под эту arch точим и кромсаем., т.е. негде развернутся в нашем DSP, не до конца он, так сказать, программируемый. В FGPA же совсем другое дело, может чуть помуторней, но это дело привычки.

 

TIA

[des00 25]

Ну в качестве примера, RLE кодирование большого масива данных из памяти.

Задача сугубо последовательная и практически не обладающая параллелилизмом.

[Harbour 0]

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

Ну давайте Ваш конкретный исходничек, посмотрим что можно сделать, что-то типа :

 

int rle_encode(uchar *src, uchar *dst, uint src_len)

{

uint dst_len = 0;

// your algo comes here

//

return dst_len;

}

 

P.S. Что-то далеко от темы про матрицы уехали ;)

Изменено 9 февраля, 2006 пользователем Harbour

[dxp 53]

Ну-ну ... хотите contest ? Алгоритм в студию (исходник на С например), я делаю на FPGA , Вы на фине. Учтите что данные еще в CPU ввести надо и вывести - а это в пересчете на наны - уйма времени, а FPGA не нуждается в прерываниях и ping-pong буферах, можно и через HPI, но что тогда с пайплайном будет ?

Универсальность, то бишь окаменелость, DSP конвейера в том что данные движутся кажный такт в строго определенных направлениях со строго определенной пропускной способностью, т.е. имеем например в каком-нить DSP 2 datapath'а по 256 бит да конвейер на 8 инструкций и кирдык - и вот берем мы наш несчастный алгоритм и под эту arch точим и кромсаем., т.е. негде развернутся в нашем DSP, не до конца он, так сказать, программируемый. В FGPA же совсем другое дело, может чуть помуторней, но это дело привычки.

Знаете, пиписками мериться что-то неохота, да и времени нет. А если хочеться убедиться, то возьмите например простой КИХ фильтр тапа скажем на 32 и сравните. На блекфине это будет два тапа на такт, т.е. при 600 МГц 1200 мегатапов. Да, конечно, еще есть накладные расходы на настройку хардваре луп и дата адрес генератора, но это порядка 5-10 тактов. Такт 1.67 нс, таким образом вычисление очередного отсчета сигнала займет порядка (считаем по наихудшему случаю 10 тактов на инициализацию + 5 тактов на вызов функции и столько же на возврат): (10 + 5 + 5 + 32/2)*1.67нс = 36*1.67нс = 60 нс. И что?! Какая ПЛИС без параллелизма сможет такое?

 

Что касается пересылки данных, то сведения об аппаратной поддержке этого процесса, в частности, у черного фина у Вас несколько неверные. Там есть 12-канальный DMA, который позволяет делать пересылки на максимальной скорости совершенно без участия CPU. Хоть с последовательного порта наливайте, хоть с PPI, хоть из внешней памяти во внутреннюю и обратно. Типично, скорость обмена с внешней SDRAM 133 МГц. Т.е. отнимем примерно 1% накладных на рефреш и получим (133-1.33)*16 или порядка 260 мегабайт в секунду (если непрерывно лить, а там все можно так организовать - DMA можно настроить один раз и он будет лить по дескрипторам по кругу).

 

И если учесть что младший BF-531 стОит меньше $10 в розницу, то тут множно и подумать, на чем выгоднее делать. Особенно, если учесть, что сложность реализации подобных фильтров на процессоре на порядок (как минимум) меньше, чем на ПЛИС.

 

Резюмируя. Никто не оспаривает того тезиса, что на ПЛИС, при возможности распараллелить и не ограничиваясь по стоимости, всегда можно сделать быстрее. Сказно было лишь то, что последовательлно на проце штатные операции выходят быстрее. И это логично - ведь там тоже железа нехило навернуто - умножитель-аккумулятор, толстые и быстрые шины, быстрое АЛУ и т.д., все это аппаратно на кристале, а не разведено на универсальной логике в ПЛИС. Никакой узел в ПЛИС не может работать быстрее аналогичного узла в аппаратном процессоре, это естественно. Поэтому у ПЛИС преимущества только возможности параллелить и на нестандартных операциях - типа, развернуть слово (чтобы младшие биты стали старшими, а старшие младшими), если проц не поддерживает это на уровне инструкций.

[des00 25]

И если учесть что младший BF-531 стОит меньше $10 в розницу, то тут множно и подумать, на чем выгоднее делать. Особенно, если учесть, что сложность реализации подобных фильтров на процессоре на порядок (как минимум) меньше, чем на ПЛИС.

 

Резюмируя. Никто не оспаривает того тезиса, что на ПЛИС, при возможности распараллелить и не ограничиваясь по стоимости, всегда можно сделать быстрее. Сказно было лишь то, что последовательлно на проце штатные операции выходят быстрее. И это логично - ведь там тоже железа нехило навернуто - умножитель-аккумулятор, толстые и быстрые шины, быстрое АЛУ и т.д., все это аппаратно на кристале, а не разведено на универсальной логике в ПЛИС. Никакой узел в ПЛИС не может работать быстрее аналогичного узла в аппаратном процессоре, это естественно. Поэтому у ПЛИС преимущества только возможности параллелить и на нестандартных операциях - типа, развернуть слово (чтобы младшие биты стали старшими, а старшие младшими), если проц не поддерживает это на уровне инструкций.

 

Или нужно большое кол-во битовых операций

 

А по сабжу Полностью согласен с уважаемым dxp, есть определенный круг задач, решение которых на FPGA по соотношению цена/качество целесообразно,

а городить из ФПГА процессор и ждать от него чуда ничего хорошего не получиться.

[Harbour 0]

Ну-ну ... хотите contest ? Алгоритм в студию (исходник на С например), я делаю на FPGA , Вы на фине. Учтите что данные еще в CPU ввести надо и вывести - а это в пересчете на наны - уйма времени, а FPGA не нуждается в прерываниях и ping-pong буферах, можно и через HPI, но что тогда с пайплайном будет ?

Универсальность, то бишь окаменелость, DSP конвейера в том что данные движутся кажный такт в строго определенных направлениях со строго определенной пропускной способностью, т.е. имеем например в каком-нить DSP 2 datapath'а по 256 бит да конвейер на 8 инструкций и кирдык - и вот берем мы наш несчастный алгоритм и под эту arch точим и кромсаем., т.е. негде развернутся в нашем DSP, не до конца он, так сказать, программируемый. В FGPA же совсем другое дело, может чуть помуторней, но это дело привычки.

Знаете, пиписками мериться что-то неохота, да и времени нет. А если хочеться убедиться, то возьмите например простой КИХ фильтр тапа скажем на 32 и сравните. На блекфине это будет два тапа на такт, т.е. при 600 МГц 1200 мегатапов. Да, конечно, еще есть накладные расходы на настройку хардваре луп и дата адрес генератора, но это порядка 5-10 тактов. Такт 1.67 нс, таким образом вычисление очередного отсчета сигнала займет порядка (считаем по наихудшему случаю 10 тактов на инициализацию + 5 тактов на вызов функции и столько же на возврат): (10 + 5 + 5 + 32/2)*1.67нс = 36*1.67нс = 60 нс. И что?! Какая ПЛИС без параллелизма сможет такое?

Ну-у ребята, у Вас нечестный подход - FPGA давай без параллелизьму, а мы тут DSP бум юзать по полной. Напоминаю, так сказать, нить рассуждений - des00 говорил об определенном плохо распараллелливающемся алгоритме, который, типа, на DSP будет быстрее чем на FPGA. А меряться с Вами мне неинтересно - я где-то за это время речь жму (ITU compliant G726) на первом циклоне.

Что касается пересылки данных, то сведения об аппаратной поддержке этого процесса, в частности, у черного фина у Вас несколько неверные. Там есть 12-канальный DMA, который позволяет делать пересылки на максимальной скорости совершенно без участия CPU. Хоть с последовательного порта наливайте, хоть с PPI, хоть из внешней памяти во внутреннюю и обратно. Типично, скорость обмена с внешней SDRAM 133 МГц. Т.е. отнимем примерно 1% накладных на рефреш и получим (133-1.33)*16 или порядка 260 мегабайт в секунду (если непрерывно лить, а там все можно так организовать - DMA можно настроить один раз и он будет лить по дескрипторам по кругу).

Да ну ! И Вы в состоянии заливающиеся данные по DMA тут же обрабатывать, так сказать в процессе пересылки DMA -> ОЗУ ? Тут одно из двух - или память должна быть 2-портовой в DSP (в фине внутренняя - однопортовая) или нужно обрабатывать данные по времени сразу за DMA, что требует (1) быстрого алгоритма, (2) филигранной отстройки системы. Тут можно сказать что скорость подачи данных будет определять каким сложным может быть алгоритм, т.е. если скорость у нас высокая фин просто ничего не успеет сделать.

И если учесть что младший BF-531 стОит меньше $10 в розницу, то тут множно и подумать, на чем выгоднее делать. Особенно, если учесть, что сложность реализации подобных фильтров на процессоре на порядок (как минимум) меньше, чем на ПЛИС.

Да хоть даром пусть его отдают - фирма AD славится своими "достижениями" в области камней и софта, глядя на толщину errata их чипов и уникальность visualdsp как-то становится не по себе.

Резюмируя. Никто не оспаривает того тезиса, что на ПЛИС, при возможности распараллелить и не ограничиваясь по стоимости, всегда можно сделать быстрее. Сказно было лишь то, что последовательлно на проце штатные операции выходят быстрее. И это логично - ведь там тоже железа нехило навернуто - умножитель-аккумулятор, толстые и быстрые шины, быстрое АЛУ и т.д., все это аппаратно на кристале, а не разведено на универсальной логике в ПЛИС. Никакой узел в ПЛИС не может работать быстрее аналогичного узла в аппаратном процессоре, это естественно. Поэтому у ПЛИС преимущества только возможности параллелить и на нестандартных операциях - типа, развернуть слово (чтобы младшие биты стали старшими, а старшие младшими), если проц не поддерживает это на уровне инструкций.

Да и со стоимостью все супер. Вобчем где-то оно понятно, как говорят на востоке - в засохшее дерево камней не кидают, это я про DSP ;)