[dimitriy91 0]

Добрый день. Я не силён в реализации алгоритмов ЦОС на ПЛИС, но необходимо потихоньку начинать осваивать.

Интересует следующий вопрос. Как правильно выбрать тип умножителя (с фиксированной точкой или плавающей запятой) для конкретного алгоритма ЦОС ?

Например какой умножитель выбрать для построения КИХ фильтра ? Какой для БИХ ? Какой для FFT ? Какой для Рида-Соломона ?

В учебных целях планирую реализовать все эти вещи на ПЛИС.

Как использовать например умножитель с помощью языка VHDL ? Знак * для std_logic_vector в тупую перемножит оба операнда в типе Unsigned integer (UINT) ? Для умножения чисел в формате с плавающей запятой на ПЛИС, необходимо каждый раз реализовывать свой умножитель (брать чужой IP CORE) или как ?

[serjj1333 0]

Здравствуйте.

Пока забудьте про floating point умножители на ПЛИС, это не то, с чего вам начинать стоит. Посмотрите UG на умножители (DSP блоки по другому в некоторых архитектурах) и для начала используйте Core generator для получения модуля умножителя. В этих блоках довольно много параметров и портов и у разных вендоров они отличаются, через генератор вы получите рабочую конфигурацию, с которой можно "поиграться", для того что бы понять что к чему. Пока вы не будете полностью понимать как имплиментируется умножитель в выбранной архитектуре лучше не использовать прямое умножение в коде, т.к. его как правило нужно описывать дополнительными констрейнами что бы он заработал на требуемой скорости. В случае с такими системами как DSP slice - это модуль в котором понапихано куча всего, лучше вообще всегда задавать операции явно, через соответсвующие примитивы.

[sallador 0]

В дополнение к serjj

 

Да, без юзергайдов никуда. Натоятельно рекомендую читать мануал.

Сам перемножитель сейчас - сложная штука. А писать программы на VHDL в стиле D = A+B*C - конечно можно, но в какие ресурсы это выльется - не всегда ясно и понятно, особенно если проект разросся до огромных размеров.

 

Помимо умножения, в том же DSP48E1 у Xilinx еще можно реализовать суммирование, сравнение, перенос, свдиг, предварительное суммирование и т.д. и т.п.

 

Параллельно чтению UG на перемножители, подумайте над простейшей реализацией того же КИХ-фильтра эдак на 16 отводов.

Причем можно реализовать тремя способами и сравнить:

1) Напрямую записать в VHDL через цикл loop или generate;

2) С помощью ip ядер умножения и суммирования;

3) C помощью CORE Generator у Xilinx взять и сразу сделать готовый КИХ на нужное число отводов с нужным числом коэффициентов.

 

По мере увеличения объема знаний - увеличивайте и сложность проекта.

К примеру, попытайтесь задействовать предварительные сумматоры в блоке DSP48E1 для реализации КИХ с симметричной характеристикой, сделайте возможность загрузки коэффициентов в блоки DSP и т.д.

 

Может показаться, что это изобретение очередного велосипеда, но для постижения ЦОС - лучше через все это пройти самому.

 

 

 

В заключение хотел бы сказать, что многие сейчас смотрят в сторону реализации алгоритмов ЦОС на С++. Конкретно для Xilinx это Vivado HLS, где можно выбирать компромисс между ресурсами и производительностью. Благодаря набору настроек и прагм - можно довольно-таки быстро получить различные решения, сравнить их между собой и выбрать приемлимое в рамках конкретной задачи.

Изменено 4 марта, 2015 пользователем sallador

[ElrondTelvanni 0]

Умножители, которые встроенные DSP-блоки, отличаются в зависимости от конкретной ПЛИС. В cyclone III например - это обычные fixed-point 18x18 умножители, а в Cyclone V - это уже более сложная конструкция переменной точности. Для cyclone III я использую синтез умножителей из HDL-кода. Причём в зависимости от типа(signed/unsigned) и разрядности входов будет синтезирован соответствующий умножитель. Также из кода можно задать наличие/отсутствие регистров на входах и выходе умножителя. При таком подходе код получается ПЛИСонезависимым, но при портировании на более сложную ПЛИС (например virtex) можно получить неоптимальное расходование ресурсов.

Что касается floating point арифметики - это довольно сложная и дорогая в плане ресурсов ПЛИС штука, но и нужна она довольно редко (например, для моделирования нелинейных систем). КИХ-и БИХ-фильтры, БПФ, и прочее обычно делаются в арифметике с фиксированной точностью, но при этом необходимо правильно выбрать разрядности всех цепей и регистров. Типичный пример для КИХ-фильтра: операнды - 16 бит, умножитель 16х16->32 бита, аккумулятор 40 бит, и на выходе от аккумулятора отрезаются 16 бит справа и 8 бит слева (с насыщением).

[serjj1333 0]

В cyclone III например - это обычные fixed-point 18x18 умножители

9x9, 18х18 появились в 4-м.

а в Cyclone V - это уже более сложная конструкция переменной точности

В принципе тут используются все теже lpm_mult с незначительными изменениями. Для разработки это прозрачно, если сравнить с использованием DSP48 в спартане, которое напоминает программирование простенького микроконтроллера по количеству нужных телодвижений :rolleyes:

КИХ-и БИХ-фильтры, БПФ, и прочее

Вот как раз в рекурсивных схемах использование fp это интересно, т.к. там требуется очень большая точность вычислений, но ТСу пока об этом лучше не париться.

[Krys 2]

Добрый день. Я не силён в реализации алгоритмов ЦОС на ПЛИС, но необходимо потихоньку начинать осваивать.

А вообще в ЦОС не на ПЛИС сильны? Почему спрашиваю - потому что из дальнейшей дискуссии чувствуется, что Вам может пока и без ПЛИС бы хватило с ЦОС поразбираться. В том же Матлабе. Попробовать различные способы представления чисел, различные разрядности, понять, какие из них Вам сгодятся под конкретную задачу. Это всё с ПЛИС никак не связано и годится при реализации хоть на чём, хоть на процессоре DSP, хоть на обычной PC-шке.

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

 

[dimitriy91 0]

А вообще в ЦОС не на ПЛИС сильны? Почему спрашиваю - потому что из дальнейшей дискуссии чувствуется, что Вам может пока и без ПЛИС бы хватило с ЦОС поразбираться. В том же Матлабе. Попробовать различные способы представления чисел, различные разрядности, понять, какие из них Вам сгодятся под конкретную задачу. Это всё с ПЛИС никак не связано и годится при реализации хоть на чём, хоть на процессоре DSP, хоть на обычной PC-шке.

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

 

Возможно вы и правы. Все выше описанные алгоритмы я реализовывал на PC (c++ и C#). Не чувствую себя проффи в ЦОС, но кое что знаю. На ПЛИС делал много проектов, но все они сводились, либо к генерированию различных сигналов, либо передача данных по различным интерфейсам. Спасибо всем огромное за расширенные ответы, очень признателен всем. Пока что всё туманно с этими умножителями.

 

Поишу инфу про шумы для различных представлений числа. Зачастую сигнал и так очень сильно зашумлён, не хочется "добивать" его окончательно шумами квантования и тд. К сожалению в памяти отложилось только про диссперсию вызванную округлением или усичением числа. =)))

Изменено 5 марта, 2015 пользователем abraziv

[Golikov 0]

откуда взялся миф что плавающая точка точнее фиксированной?

Плавающая точка менее (правильнее даже "не более") точна фиксированной, она просто позволяет сохранить общую разрядность числа, уменьшая разрядность дробной части при увеличении абсолютного значения числа. Но это как раз снижение точности.

 

Прелесть ПЛИС что в отличии от процов с фиксированным АЛУ, вы можете делать свои умножители хоть 120 битные... А работа с плавающей точкой такая же как и в проце происходит.

Сначала выравниваются порядки чисел, потом идет работа с фиксированной точкой, потом нормировка, и упаковка обратно. И это никак не влияет ни на что другое, это всего лишь представление и правила округления...

[des00 25]

Какой для Рида-Соломона ?

а зачем в РС умножитель? там все прекрасно реализуется без него, на распределенной арифметике в полях галуа.

 

[serjj1333 0]

откуда взялся миф что плавающая точка точнее фиксированной?

Допускаю, что я чего-то не понимаю, ибо в плис плавучку не пробовал, но..

как объяснить: делаю в матлабе qr декомпозицию случайной комплексной матрицы 8х8 например, и измеряю ошибку вычисления

результаты:

~3,5е-5 - fixed point x32 (27 итераций кордика)

~4.5e-13 - fixed point x63 (44 итерации кордика)

~1.5e-6 - floating point single

~3e-15 - floating point double

 

Как видно при одинаковой разрядности fixed уступает плавучке на порядок, а при двойной точности в плавучке точность на 2 порядка выше чем у фиксированной точки. Плюс для fixed point очень важно правильно выбрать размер fractional part, и смасштабировать входные данные, иначе алгоритм просто развалится. Другой вопрос что двойная точность в железе фантастика, но это уже другая песня :rolleyes:

 

Автору сорри за оффтоп..

Изменено 5 марта, 2015 пользователем serjj

[ElrondTelvanni 0]

serjj

Почему фантастика? У альтеры например есть мегафункция altera_fp_functions, где легко в несколько кликов синтезировать любую арифметическую функцию для работы с плавучкой хоть одинарной, хоть двойной точности в соответствии со 754-м стандартом. Проверено - работает. :) Ресурсов правда жрёт немало, и latency несколько тактов. Для LMS и даже RLS-алгоритмов - в самый раз.

[serjj1333 0]

Почему фантастика? У альтеры например есть мегафункция altera_fp_functions, где легко в несколько кликов синтезировать любую арифметическую функцию для работы с плавучкой хоть одинарной, хоть двойной точности в соответствии со 754-м стандартом.

Есть. UG Floating Point megafunctions от Альтеры: страница 133, там есть табличка resourse utilization для стратикса, обратите внимание во сколько раз возрастает расход ресурсов при переходе на двойную точность. ИМХО в наших реалиях никто не даст так расходывать дорогущие чипы :rolleyes:

Для LMS и даже RLS-алгоритмов - в самый раз.

Для RLS и тем более для LMS двойная точность не нужна.

[goodsoul 0]

Есть. UG Floating Point megafunctions от Альтеры: страница 133, там есть табличка resourse utilization для стратикса, обратите внимание во сколько раз возрастает расход ресурсов при переходе на двойную точность. ИМХО в наших реалиях никто не даст так расходывать дорогущие чипы :rolleyes:

 

Для RLS и тем более для LMS двойная точность не нужна.

 

 

Как правило при реализации плавающей точки сначала заканчивается логические ячейки, а только потом DSP блоки. Поэтому FP на ПЛИС привыкли считать делом очень дорогим.

Если нужна плавающая точка без расхода LE - есть Arria10. Там в каждом DSP блоке есть IEEE754 сумматор и умножитель. Аппаратные блоки.

http://www.altera.com/technology/dsp/varia...-dsp-block.html

[dimitriy91 0]

а зачем в РС умножитель? там все прекрасно реализуется без него, на распределенной арифметике в полях галуа.

 

Действительно. Затупил, извиняюсь.

[Skryppy 1]

А когда мало умножителей в ПЛИСах можно пойти на ухищрения: заменить операцию умножения операцией суммирования и сдвига числа(например число 10 можно представить как 2^3 + 2^1, а степень двойки это сдвиг числа влево). Матлаб, например, может реализовать фильтр на HDL языке с заменой умножителей на такие структуры (алгоритм CSD или Factored-CSD).