|
Подсчет нулей или единиц |
|
|
|
May 13 2009, 10:51
|
Профессионал
    
Группа: Свой
Сообщений: 1 129
Регистрация: 19-07-08
Из: Санкт-Петербург
Пользователь №: 39 079

|
Цитата(SM @ May 13 2009, 14:08)  assign temp_a = (in_data & 64'h5555555555555555) + ((in_data >> 1) & 64'h5555555555555555); assign temp_b = (temp_a & 64'h3333333333333333) + ((temp_a >> 2) & 64'h3333333333333333); assign temp_c = (temp_b & 64'h0707070707070707) + ((temp_b >> 4) & 64'h0707070707070707); assign temp_d = (temp_c & 64'h000F000F000F000F) + ((temp_c >> 8) & 64'h000F000F000F000F); assign temp_e = (temp_d & 64'h0000001F0000001F) + ((temp_d >> 16) & 64'h0000001F0000001F); assign temp_f = (temp_e & 64'h000000000000003F) + ((temp_e >> 32) & 64'h000000000000003F); 119 элементов против 193 следующей реализации: Код always @(*) begin temp_f = 0; for(int i=0; i<64; i++) if(in_data[i]) temp_f++; end Синтезатор еще далек от идеала Но, зато, судя по времянке быстродействие второго способа не намного хуже, чем первого. Надо бы для проверки в TQA загнать. P.S. Пока проверял - не заметил сообщения выше
Сообщение отредактировал des333 - May 13 2009, 10:52
--------------------
|
|
|
|
|
May 13 2009, 10:52
|
Участник

Группа: Участник
Сообщений: 42
Регистрация: 26-10-07
Пользователь №: 31 743

|
А так? always @(posedge clk) begin one [7:0] = input_number[63] + input_number[62] + input_number[61] +...+input_number[0] zero[7:0] = 8'd64 - (input_number[63] + input_number[62] + input_number[61] +...+input_number[0]) end
Сообщение отредактировал PeterD - May 13 2009, 10:54
|
|
|
|
|
May 13 2009, 10:58
|
Гуру
     
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881

|
Цитата(Egel @ May 13 2009, 14:52)  Но какие частоты будут с 180 разрядным сумматором? Про дерево не совсем понял) Точно те же, как и в остальных схемах. Так как как этот зад раком не крути, а для решения задачи нучно 180 одноразрядных сумматоров (примерное количество, плюс минус от реализации и задействования их переносов). А как их расставить - как один 180-битный, или как 180 однобитных - это вам решать и это сути дела не меняет. Про дерево - для 8 бит так: wire [1:0] stage_0_0, stage_0_1; wire [2:0] stage_1_0; wire [3:0] stage_2_0; assign stage_0_0 = data[0]+data[1]+data[2]; assign stage_0_1 = data[3]+data[4]+data[5]; assign stage_1_0 = stage_0_0 + stage_0_1 + data[6]; assign stage_2_0 = stage_1_0 + data[7]; до 64 бит сами расширяйте, долго и муторно. А цикл generate продумывать мне влом.
|
|
|
|
|
May 13 2009, 18:01
|
Местный
  
Группа: Свой
Сообщений: 443
Регистрация: 22-07-06
Из: Украина, г. Харьков
Пользователь №: 19 006

|
Цитата(SM @ May 13 2009, 13:44)  А эффективнее всего это делать на дереве полных сумматоров с использованием их входов переносов, подавая везде на перенос один бит входных данных. Как раз с полными сумматорами здесь не очень-то получается, по крайней мере на Альтере. Похоже, что есть ограничения на то, откуда можно подавать данные на вход переноса в альтеровской LE. Получается, что если туда подается сигнал не с выхода переноса соседней ячейки, то приходится задействовать еще одну LE. А в этом случае уже более оптимальным получается дерево, имеющее полусумматоры на первом сложении (лучше 2 полусумматора, чем один полный).
|
|
|
|
|
May 13 2009, 21:12
|
Гуру
     
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881

|
Цитата(Artem_Petrik @ May 13 2009, 22:01)  Как раз с полными сумматорами здесь не очень-то получается, по крайней мере на Альтере. Вполне возможно. Я не преследовал цели соптимизировать именно на альтеру. Изначально моей целью была среднестатистическая технология, основанная на стандартных ячейках. Если хорошо подумать, можно родить и оптимальный вариант для альтеры, и, возможно, он будет именно таков, как Вы предлагаете.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|