stealthisname 0 Posted October 8, 2021 (edited) · Report post 19 минут назад, RobFPGA сказал: Ну так DSP может суммировать 3 числа: P = AB+C+PCIN каждое по 48 бит (AB тут не произведение а просто конкатенация входов). на первой схеме у автора темы таких входов нет, есть X1 Y2 и перенос. Есть ли возможность суммировать числа в DSP так, как указано автором темы на первой схеме? Edited October 8, 2021 by stealthisname Quote Ответить с цитированием Share this post Link to post Share on other sites
RobFPGA 0 Posted October 8, 2021 · Report post Приветствую! 35 minutes ago, stealthisname said: Есть ли возможность суммировать числа в DSP так, как указано автором темы в на первой схеме? Есть. Фактически X это А, Y это B, перенос это PCIN, Out это либо PCOUT (если к идет переносу) либо P , например // пкрвый вариант A4*B4 + PCIN -> P -----\ +-------\ | A3*B3 PCIN -> PCOUT3 \- AB + C -> P = A1B1+A2B2+A3B3+A4B4 | A2*B2 + PCIN -> P -------------/ +-------\ A1*B1 -> PCOUT1 // втрой вариант A4*B4 + PCIN -> P = A1B1+A2B2+A3B3+A4B4 +-------\ A2*B2 + PCIN -> PCOUT3 +-------\ A2*B2 + PCIN -> PCOUT2 +-------\ A1*B1 -> PCOUT1 Удачи! Rob. Quote Ответить с цитированием Share this post Link to post Share on other sites
stealthisname 0 Posted October 8, 2021 · Report post 8 минут назад, RobFPGA сказал: Фактически X это А, Yэто B, перенос это PCIN, Out это либо PCOUT (если к идет переносу) либо P , например спасибо я ошибся, сказав, что такая сумма не возможна на DSP. вычисления у автора темы могут быть реализованы так как указано на первой схеме. но в этой схеме есть незначительная неточность, которая может из-за невнимательности ввести в заблуждение. схема получается такая не считая обозначений входов, все было правильно Quote Ответить с цитированием Share this post Link to post Share on other sites
krux 0 Posted October 8, 2021 · Report post Table 2-10: Three-Input ALUMODE Operations DSP Operation: Z + X + Y + CIN и действительно, документация такое описывает. вот только есть момент, что вход PCIN должен быть выходом соседнего блока, иначе PnR не пройдёт. Quote Ответить с цитированием Share this post Link to post Share on other sites
andrew_b 0 Posted October 8, 2021 · Report post 7 часов назад, TRILLER сказал: 3. Операнды знаковые или без знаковые? Это вопрос интерпретации. Quote Ответить с цитированием Share this post Link to post Share on other sites
des00 0 Posted October 8, 2021 · Report post 10 hours ago, alexPec said: Так в том-то и дело, что даже 8 произведений за такт на ultrascale+ (speedgrade -1) на 150МГц не пролазит. Вот и пытаюсь вручную колдонуть. Ну бог с ним, за такт, я уже морально готов к 3 тактам :) Но ведь не пролезет... А больше 3 мне никак нельзя. Думал может кто знает волшебное слово для вивадо. 256 входов с умножением и сложением не сделать за такое время. Полагаю что там будет где то 30МГц тактовая. Может все же отталкиваться от тактовой? заложить 100МГц, разгонать частоту до 400-500. Ну и на каждом такте последовательно по 4 числа крутить на ДСП ядре. Первый слой - умножение с накоплением, второй-накопление, третий - широкий сумматор (можно на 3-add mode) режиме работы ячеек. Quote Ответить с цитированием Share this post Link to post Share on other sites
blackfin 0 Posted October 8, 2021 · Report post 11 hours ago, alexPec said: При синтезе в вивадо получаю в схематике примерно такое: Это примерно то, что нарисовано в PG192: Может умножать на высокой частоте и в каждом такте может умножать два новых вектора, но latency = 256. Ну и можно сконфигурировать в чисто комбинаторном варианте: Тогда и частота будет соответствующая.. Quote Ответить с цитированием Share this post Link to post Share on other sites
Aleх 0 Posted October 8, 2021 · Report post Суть сложения с накоплением, две операции вместо одной, причем - без потери разрядности, а значит и точности. Если попытаться сделать эту функцию от 256 аргументов по классическому подходу, с переполнениями будет бороться совсем тяжко, либо диапазон чисел получится маленький, меньше 8 бит. Мне кажется, это задача прдходит для сисемы остаточных классов https://habr.com/ru/post/144886/ Quote Ответить с цитированием Share this post Link to post Share on other sites
RobFPGA 0 Posted October 8, 2021 · Report post Приветствую! 3 hours ago, Aleх said: Если попытаться сделать эту функцию от 256 аргументов по классическому подходу, с переполнениями будет бороться совсем тяжко Проблем с переполнением тут нет, 48-битная разрядность многое позволяет. Проблемы у TC именно в latency - ему кровь из носу надо уложится в 2-3 такта, и именно это не получается сделать при большом количестве входов у сумматора. Удачи! Rob. Quote Ответить с цитированием Share this post Link to post Share on other sites
alexPec 0 Posted October 8, 2021 · Report post 4 минуты назад, RobFPGA сказал: Приветствую! Проблем с переполнением тут нет, 48-битная разрядность многое позволяет. Проблемы у TC именно в latency - ему кровь из носу надо уложится в 2-3 такта, и именно это не получается сделать при большом количестве входов у сумматора. Удачи! Rob. Все верно. Надо попробовать вариант с увеличенной тактовой. Тогда получится контролировать на промежуточных регистрах длину цепочки переноса. Тут может прокатить. Всем спасибо за советы! Quote Ответить с цитированием Share this post Link to post Share on other sites
TRILLER 0 Posted October 8, 2021 · Report post Вполне уверенно водится проект на 2 такта и 150МГц, если умножения делать не на dsp, а на логике. Только ресурсов жрёт прилично.src.rar Обязательно запретить использование дсп атрибутом (* use_dsp = "no" *), ну и триггер поставить после попарных сумм 8 элементов. Если Вас устроят 3 такта, то и dsp можно использовать без проблем на эту частоту. То, что Вы хотели бы получить - это очень плохо: Quote Основная проблема использования dsp - это большие времянки на входе и выходе. Сюда ещё добавляется строгая локализация в кристалле. До них банально долго тянуть данные! Поэтому, то, что уже попало в ДСП должно как можно дольше там и оставаться, а после вывода - не заходить снова. Т.е. желательно максималное использование внутренних возможностей и линий ускоренного переноса между блоками. Из моего опыта, оптимальный вариант описания dsp - это отдельный, иерархически изолированный(* keep_hierarchy = "yes" *) модуль, в котором полностью описываются операции 1 или нескольких dsp и их взаимодействие по выделенным линиям. Обязательно, как уже говорилось выше, использование атрибута use_dsp. Ещё вполне рабочий вариант, как уже предлагали, это переход на удвоенную частоту. Но там могут возникнуть проблемы с холдом(хоть и в ряд ли в Вашем случае).. 10 hours ago, andrew_b said: Это вопрос интерпретации. Умножая без знаковые операнды 16 и 8 бит - в результате получаем 24 значащих бита. В случае знаковых операндов - результат умещается в 23. Quote Ответить с цитированием Share this post Link to post Share on other sites
new123 0 Posted October 8, 2021 (edited) · Report post Однажды решил заюзать dsp в проекте для умножений. Пока проект маленький, вроде нормально, а по мере роста и заполняемости, пока до него данные дойдут, пока заберешь обратно, вечность проходит. Я бы это тоже учитывал в будущем, если надо так строго в два такта уложиться. Edited October 8, 2021 by new123 Quote Ответить с цитированием Share this post Link to post Share on other sites
alexPec 0 Posted October 8, 2021 · Report post 2 часа назад, TRILLER сказал: Вполне уверенно водится проект на 2 такта и 150МГц, если умножения делать не на dsp, а на логике. Только ресурсов жрёт прилично Спасибо! Да, интересный опыт. Но на логике много умножителей и сумматоров делать - в чип не влезет. Quote Ответить с цитированием Share this post Link to post Share on other sites
RobFPGA 0 Posted October 8, 2021 · Report post Приветствую! 2 hours ago, alexPec said: Но на логике много умножителей и сумматоров делать - в чип не влезет. На логике можно делать только сумматоры, а умножители (c регистром на выходе) в DSP. Ну и можно поиграться комбинируя сумматор частично в DSP частично в логике выбирая оптимальное распределение задержек между регистрами. Но с этим придется повозится. Удачи! Rob. Quote Ответить с цитированием Share this post Link to post Share on other sites
Doka 0 Posted October 9, 2021 · Report post On 10/7/2021 at 9:29 PM, alexPec said: Задача такая: надо за 2 такта умножить много пар чисел и сложить все результаты. Много- это 256. Причем одно число 8 бит, второе 16. В вивадо решил проверить как он это сделает. странно, что до сих пор никто не предложил "обмануть carry-chain" как описывается тут (таймметка 35:07, если ссылка некорректно вставится): Quote Ответить с цитированием Share this post Link to post Share on other sites
