[des00 25]

Как раз с полными сумматорами здесь не очень-то получается, по крайней мере на Альтере. Похоже, что есть ограничения на то, откуда можно подавать данные на вход переноса в альтеровской LE. Получается, что если туда подается сигнал не с выхода переноса соседней ячейки, то приходится задействовать еще одну LE. А в этом случае уже более оптимальным получается дерево, имеющее полусумматоры на первом сложении (лучше 2 полусумматора, чем один полный).

 

а можно пример ? для наглядности пусть будет 64-х битный вектор и сравните результат синтеза с http://electronix.ru/forum/index.php?showt...st&p=549588

 

вопрос возник не просто так. простой оценочный расчет для альетры схемы на полусуматорах 32*1 + 16*2 + 8*3 + 4*4 + 2*5 + 1*6 = 120 ячеек, схемы на "нечестных" полных сумматорах 16*2 + 8*4 + 4*5 + 2*6 + 1*7 = 103 ячейки. Сделал как вы предлагаете (если я вас правильно понял) и квартус со мной согласился :)

[Artem_Petrik 0]

вопрос возник не просто так. простой оценочный расчет для альетры схемы на полусуматорах 32*1 + 16*2 + 8*3 + 4*4 + 2*5 + 1*6 = 120 ячеек, схемы на "нечестных" полных сумматорах 16*2 + 8*4 + 4*5 + 2*6 + 1*7 = 103 ячейки.

Да, вы правы, полные сумматоры лучше. Просто показалось что будет лучше на двух LE сложить 4 бита вместо трех, а оказалось, что все не так просто. Виноват, был неправ.

 

и квартус со мной согласился

Ага, так вы с ним заодно!

[SM 0]

двух LE сложить 4 бита

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

[Maverick_ 15]

В книге Shevkoplias "Microprocessornye Structury" (стр 479) предлагают такой алгоритм. Вырезка этого алгоритма во вложении

 

Когда-то давно я реализовал на VHDL логический элемент, который считает число единиц во входных данных так

(он реализован на сумматорах)

Описание портов:

data – N разрядный вход

add – N разрядный выход

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity Vcnt1s is
    Port ( data : in std_logic_vector(15 downto 0);
           add : out std_logic_vector(4 downto 0));
end Vcnt1s;

architecture Behavioral of Vcnt1s is
begin

process (data)
variable S : std_logic_vector(4 downto 0);
begin
S := "00000";
for i in 0 to 15 loop
if data(i) = '1' then S := S + "00001";
end if;
end loop;
add <= S;
end process;

end Behavioral;

Shevkoplias.MicroprocessornyeStructury.pdf

[SM 0]

Вырезка этого алгоритма во вложении

Эту схему давал уже des333 где-то в самом начале. Она, пожалуй, самая неэффективная по ресурсам.

[Oldring 0]

Она, пожалуй, самая неэффективная по ресурсам.

 

Ваше утверждение неверно. Эта схема самая эффективная по таким ресурсам, как мыслительные усилия и время, затрачиваемые разработчиком на её проектирование с нуля :)

[SM 0]

по таким ресурсам, как мыслительные усилия и время

Ну это да, не поспоришь :) :)

[Leka 0]

А я поспорю :smile3009:

Весь проект написаный в таком стиле, окажется неконкурентноспособным, и пойдет в корзину --> эффективность "по таким ресурсам, как мыслительные усилия и время, затрачиваемые разработчиком" ,окажется равной нулю.

[Oldring 0]

А я поспорю :smile3009:

Весь проект написаный в таком стиле, окажется неконкурентноспособным, и пойдет в корзину --> эффективность "по таким ресурсам, как мыслительные усилия и время, затрачиваемые разработчиком" ,окажется равной нулю.

 

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

[sazh 8]

Эту схему давал уже des333 где-то в самом начале. Она, пожалуй, самая неэффективная по ресурсам.

 

Что интересно. Показал девушкам - программистам различные реализации полемики

http://electronix.ru/forum/index.php?showt...=59528&st=0

Они в Вашу реализацию за раз въехали. Взяли на заметку.

[Leka 0]

То есть проект "может оказаться неконкурентоспособен" но утверждение что "окажется неконкурентоспособен" - неверно.

Ок.

[Maverick_ 15]

Эту схему давал уже des333 где-то в самом начале. Она, пожалуй, самая неэффективная по ресурсам.

Чтобы спора не было надо бы кому-то просто реализовать по данному алгоритму. Потом произвести сравнение результатов синтеза :) Можно ссылку на предложенную схему des333, которая реализована по данному алгоритму (я что-то ее не увидел, может плохо смотрел :().

[SM 0]

Чтобы спора не было надо бы кому-то просто реализовать по данному алгоритму. Потом произвести сравнение результатов синтеза :) Можно ссылку на предложенную схему des333, которая реализована по данному алгоритму (я что-то ее не увидел, может плохо смотрел :().

Сообщение №6 в этой ветке. Сразу вместе со сравнением результатов синтеза с вариантом неоптимального дерева.

[Des333 0]

Эту схему давал уже des333 где-то в самом начале. Она, пожалуй, самая неэффективная по ресурсам.

Я думаю, Maverick писал про схему, указанную в pdf, а не про тот код, который написан в его посте.  :)

 

 

 

 

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

[SM 0]

Я думаю, Maverick писал про схему, указанную в pdf, а не про тот код, который написан в его посте.  :)  

А, если так, то тогда да, на этой основе никто алгоритма подсчета не предлагал. Я имел в виду именно схему, представленную кодом из поста. Однако в этом алгоритме понадобится на выходе кодер экспоненты (вычисление положения старшей 1), что тоже не сказать, что ресурсов не занимает. Да и эти вот блочки на пересечениях - в лучшем случае 1 блок 1 LUT в арифметическом режиме (или в режиме CASCADE, который был в свое время в ацексах), в худшем - 1 блок 2 LUT, и кол-во блоков пропорционально квадрату разрядности, что не выглядит эффективным.