[stealthisname 8]

19 минут назад, RobFPGA сказал:

Ну так DSP может суммировать  3 числа: P = AB+C+PCIN каждое по 48 бит (AB тут не произведение а просто конкатенация входов).  

на первой схеме у автора темы таких входов нет, есть X1 Y2 и перенос. Есть ли возможность суммировать числа в DSP так, как указано автором темы на первой схеме?

 

Edited October 8, 2021 by stealthisname

[RobFPGA 58]

Приветствую!

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.

[stealthisname 8]

8 минут назад, RobFPGA сказал:

Фактически  X это А, Yэто B,  перенос это PCIN, Out это либо PCOUT (если к идет переносу) либо P , например 

спасибо

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

схема получается такая

не считая обозначений входов, все было правильно

[krux 9]

Table 2-10: Three-Input ALUMODE Operations

DSP Operation: Z + X + Y + CIN

 

и действительно, документация такое описывает.

вот только есть момент, что вход PCIN должен быть выходом соседнего блока, иначе PnR не пройдёт.

 

[andrew_b 23]

7 часов назад, TRILLER сказал:

3. Операнды знаковые или без знаковые?

Это вопрос интерпретации.

[des00 26]

10 hours ago, alexPec said:

Так в том-то и дело, что даже 8 произведений за такт на ultrascale+ (speedgrade -1) на 150МГц не пролазит. Вот и пытаюсь вручную колдонуть. Ну бог с ним, за такт, я уже морально готов к 3 тактам :) Но ведь не пролезет... А больше 3 мне никак нельзя. Думал может кто знает волшебное слово для вивадо. 

256 входов с умножением и сложением не сделать за такое время. Полагаю что там будет где то 30МГц тактовая. Может все же отталкиваться от тактовой? заложить 100МГц, разгонать частоту до 400-500. Ну и на каждом такте последовательно по 4 числа крутить на ДСП ядре. Первый слой - умножение с накоплением, второй-накопление, третий - широкий сумматор (можно на 3-add mode) режиме работы ячеек.

[blackfin 60]

11 hours ago, alexPec said:

При синтезе в вивадо получаю в схематике примерно такое:

Это примерно то, что нарисовано в PG192:

 

 

Может умножать на высокой частоте и в каждом такте может умножать два новых вектора, но latency = 256.

 

Ну и можно сконфигурировать в чисто комбинаторном варианте:

 

Тогда и частота будет соответствующая..

[Avex 1]

Суть сложения с накоплением, две операции вместо одной, причем - без потери разрядности, а значит и точности. Если попытаться сделать эту функцию от 256 аргументов по классическому подходу, с переполнениями будет бороться совсем тяжко, либо диапазон чисел получится маленький, меньше 8 бит.

Мне кажется, это задача прдходит для сисемы остаточных классов https://habr.com/ru/post/144886/ 

[RobFPGA 58]

Приветствую!

3 hours ago, Aleх said:

Если попытаться сделать эту функцию от 256 аргументов по классическому подходу, с переполнениями будет бороться совсем тяжко

Проблем с переполнением тут нет, 48-битная разрядность  многое позволяет. 
Проблемы  у TC   именно  в  latency - ему  кровь из носу надо уложится в  2-3 такта, и именно это не получается сделать при большом количестве входов у сумматора.   

 

Удачи!  Rob.

[alexPec 4]

4 минуты назад, RobFPGA сказал:

Приветствую!

Проблем с переполнением тут нет, 48-битная разрядность  многое позволяет. 
Проблемы  у TC   именно  в  latency - ему  кровь из носу надо уложится в  2-3 такта, и именно это не получается сделать при большом количестве входов у сумматора.   

 

Удачи!  Rob.

Все верно. Надо попробовать вариант с увеличенной тактовой. Тогда получится контролировать на промежуточных регистрах длину цепочки переноса. Тут может прокатить.

Всем спасибо за советы! 

[TRILLER 0]

Вполне уверенно водится проект на 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.

[new123 0]

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

Edited October 8, 2021 by new123

[alexPec 4]

2 часа назад, TRILLER сказал:

Вполне уверенно водится проект на 2 такта и 150МГц, если умножения делать не на dsp, а на логике. Только ресурсов жрёт прилично

Спасибо! Да, интересный опыт. Но на логике много умножителей и сумматоров делать - в чип не влезет.

[RobFPGA 58]

Приветствую!

2 hours ago, alexPec said:

Но на логике много умножителей и сумматоров делать - в чип не влезет.

На логике можно делать только сумматоры,  а умножители (c регистром на выходе) в DSP. Ну и можно поиграться комбинируя  сумматор частично в DSP частично в логике выбирая оптимальное распределение  задержек  между  регистрами. Но с этим придется повозится.

 

Удачи! Rob.

[Doka 5]

On 10/7/2021 at 9:29 PM, alexPec said:

Задача такая: надо за 2 такта умножить много пар чисел и сложить все результаты. Много- это 256. Причем одно число 8 бит, второе 16. В вивадо решил проверить как он это сделает.

странно, что до сих пор никто не предложил "обмануть carry-chain" как описывается тут (таймметка 35:07, если ссылка некорректно вставится):