[ViKo 1]

Написал прямо.

module        MultiAdder #(parameter WID = 8) (
    input    bit                    Clk,        // Clock
    input    bit    [WID-1 : 0]        A, B, C,    // Variables
    output    bit    [WID+1 : 0]        D            // output data
);
/*  Сумматор  */
    always_ff @(posedge Clk) begin
        D <= A + B + C;
    end
endmodule :    MultiAdder

Работает медленнее, чем хочу. Хочу за один такт, 4 нс.

Попробовал мегафункцию. Не помогло.

Разум говорит, лучше не будет. А внутренний голос шепчет: а если без переносов, задать 4-входовую таблицу, 3 бита из переменных + бит переноса? Если будет 8 таких каскадов, наверное, времечко здоровенное будет. А если разбить сумматор на две части...?

Вдруг кто-то занимался подобным.

[7777777alex 0]

Добрый день.

 

Проделывал похожее на виртексе

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

 

Для 6 виртекса на 8 разрядов без каких либо телодвижений частота 500-400 мгц.

 

Только попробуйте добавить

 

reg [WID-1:0] sum_r, a_r, b_r, c_r;

always @(posedge clk) begin

a_r <= a;

b_r <= b;

c_r <= c;

sum_r <= a_r + b_r + c_r;

sum <= sum_r;

end

 

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

 

Замечу, что у результата я намеренно поставил WID-1, у Xilinx это было кретично.

Не знаю как у Альтеры, но я бы поупражнялся с разрядностью результата.

 

А вообще, можно погуглить троичный сумматор для Альтеры Зайлинкс. Ссылок много.

 

Успехов

Изменено 15 июля, 2016 пользователем 7777777alex

[ViKo 1]

Разрядность суммы должна быть на 2 больше разрядности слагаемых, иначе результат не поместится.

[Timmy 1]

Разум говорит, лучше не будет. А внутренний голос шепчет: а если без переносов, задать 4-входовую таблицу, 3 бита из переменных + бит переноса? Если будет 8 таких каскадов, наверное, времечко здоровенное будет. А если разбить сумматор на две части...?

Думаю, на Cyclone3 никак не ускорить, вот у Ксайлинкса, да, есть троичные сумматоры на всех чипах с LUT6.

[7777777alex 0]

Разрядность суммы должна быть на 2 больше разрядности слагаемых, иначе результат не поместится.

 

Да это так, я предусматривал что значения a b c на самом деле не привысят WID-2 в вашей терминологии.

По крайне мере, так у Xilinx, если писать в лоб, не использую примитивов LUT6.

Если писать по честному, примитивами, как в data sheet на dsp48 для 3:2 компрессора, то можно по честному предусмотреть разряды переполнения.

 

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

 

Я поэтому и написал - поиграться с разрядностью результата, возможно и у Альтеры это что-то даст.

 

Думаю, на Cyclone3 никак не ускорить, вот у Ксайлинкса, да, есть троичные сумматоры на всех чипах с LUT6.

 

На сколько я читал мнения на англоязычных форумах, у Альтеры троичные сумматоры получаются лучше (т.е. написать в лоб и получить хорошую частоту) , но начиная с каких то кристаллов. Забыл о каких шла речь.

 

[Strob 0]

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

Между прочим у ксайлинкс (если брать их синтезатор XST) вообще разрядность суммы равна разрядности слагаемых. Так что в лоб сделать разрядность результата хоть на один разряд больше слагаемых нельзя. Нужны доп. телодвижения.

Изменено 15 июля, 2016 пользователем Barktail

[Timmy 1]

На сколько я читал мнения на англоязычных форумах, у Альтеры троичные сумматоры получаются лучше (т.е. написать в лоб и получить хорошую частоту) , но начиная с каких то кристаллов. Забыл о каких шла речь.

Да, на более продвинутых чипах у Альтеры тоже есть поддержка троичных сумматоров.

 

[one_eight_seven 3]

Если не получается сделать на уровне регистровых передач, то можно сделать на уровне ключей и вентилей (если это правда нужно).

[ViKo 1]

Если не получается сделать на уровне регистровых передач, то можно сделать на уровне ключей и вентилей (если это правда нужно).

Быстрее не будет.

[one_eight_seven 3]

Быстрее не будет.

В смысле разработки? Конечно не будет. Это же делать надо, а не просто готовое использовать.

А если в смысле скорости обработки сигнала - то тут требуются пояснения, что мешает комбинаторной функции выполняться в один такт?

[ViKo 1]

А если в смысле скорости обработки сигнала - то тут требуются пояснения, что мешает комбинаторной функции выполняться в один такт?

В Cyclone имеются логические элементы 4-входовой таблицей. В режиме счетчика таблица разделяется на 2 3-входовые, для вычисления бита и переноса.

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

Счетчик при вичислении предполагает распространение переноса от самого младшего бита до самого старшего. Или по специальным цепям переноса (в режиме счетчика), или обычными путями, как Quartus проложит. Дальше пояснять?

[one_eight_seven 3]

четчик при вичислении предполагает распространение переноса от самого младшего бита до самого старшего.

То есть, схем кроме ripple-carry вы не знаете.

 

Да, быстродействие не бесконечное, для 8 бит по схеме carry-lookahead сигналам переноса потребуется пройти 5 вентилей, чтобы распространиться до старшего бита. Аппаратная платформа при этом не сильно разрастается.

А по схеме infinite hardware - 2 вентиля (но тут правда сильно избыточный расход логических элементов получится)

 

В Cyclone имеются логические элементы 4-входовой таблицей

А это вообще к чему? Вы быстродействие наращиваете или логические элементы экономите? Если второе - то у вас уже есть решение. Но вопрос вы задали не про то, как логических элементов сэкономить.

 

P.S. Чтобы два раза не вставить. Почему распространение переноса вас беспокоит только при трёх операндах? При двух операндах перенос тоже распространяется от младших битов к старшим. Вне зависимости от метода распространения.

Изменено 16 июля, 2016 пользователем one_eight_seven

[ViKo 1]

То есть, схем кроме ripple-carry вы не знаете.

...

P.S. Чтобы два раза не вставить...

Предложите конкретное решение, например, для 3-х 2-битовых переменных, и тогда посмотрим, что кто знает и умеет. Вижу, словоблудить вы умеете. :rolleyes: А дальше?

И, да, вопрос экономии логики не стоИт. Естественно.

[Timmy 1]

Работает медленнее, чем хочу. Хочу за один такт, 4 нс.

Попробовал мегафункцию. Не помогло.

Разум говорит, лучше не будет. А внутренний голос шепчет: а если без переносов, задать 4-входовую таблицу, 3 бита из переменных + бит переноса? Если будет 8 таких каскадов, наверное, времечко здоровенное будет. А если разбить сумматор на две части...?

Вдруг кто-то занимался подобным.

Кстати, может, расскажете всю задачу? Возможно, есть способ убрать одно сложение в конвейер.

[ViKo 1]

Кстати, может, расскажете всю задачу? Возможно, есть способ убрать одно сложение в конвейер.

В цифровом фильтре хочу иметь коэффициенты 3/4, 7/8 и т.п. Если бы получилось умножить за такт, попробовал бы сделать фильтр с БИХ, "экспоненциальное усреднение" называет Р. Лайонс. Но я хотел бы еще и сами коэффициенты менять в процессе. Понял, что быстродействия не хватает. Можно аппаратные умножители задействовать, но лень и нет уверенности в успехе.

Теперь вместо БИХ фильтр с КИХ творю. И тоже столкнулся с необходимостью иметь подобные выше показанным коэффициенты. Но здесь уже могу фильтровать не за такт, а конвейером. Уже почти сделал, так что вопрос отпал. А интерес остался.