ViKo

У меня 9.0 без СП, придется по-новее пошукать. ...не работает, потому что нет сумматора. Об этом я уже писал в начале. Я уже было обрадовался - вот оно! Похоже, остался еще шаг до цели :) Точно! Где можно обойтись параллельным выполнением операции, последовательное не нужно.

Приколы продолжаются. "Хэндмэйд" des00 отказался укладываться в ACEX1K (Auto device selected by fitter), наверное, каналов не хватило? Error: Cannot route source node "dff_gen[11].dffeas" of type logic cell to destination node "cnt[11]" of type I/O pin Error: Cannot route source node "dff_gen[11].dffeas" of type logic cell to destination node "lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cs_buffer[11]" of type logic cell Error: Cannot route source node "dff_gen[24].dffeas" of type logic cell to destination node "cout" of type I/O pin Error: Cannot route source node "dff_gen[24].dffeas" of type logic cell to destination node "lpm_add_sub:Add0|addcore:adder|unreg_res_node[24]" of type logic cell Error: Cannot route source node "lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cs_buffer[5]" of type logic cell to destination node "dff_gen[5].dffeas" of type logic cell Error: Cannot route source node "lpm_add_sub:Add0|addcore:adder|a_csnbuffer:result_node|cs_buffer[7]" of type logic cell to destination node "dff_gen[7].dffeas" of type logic cell Error: Can't find fit Error: Quartus II Fitter was unsuccessful. 7 errors, 0 warnings А в ACEX1K100 - влез. Немного видоизмененный (и только с асинхронным выходом переноса) влез в удвоенное количество ЛЭ. module CounterDFFEAS #(parameter WIDTH = 24) ( input Reset_n, input Clock, input Enable, input Load, input [WIDTH-1:0] Data, output [WIDTH-1:0] CntOut, output POut ); wire [WIDTH-1:0] Count; wire [WIDTH:0] Next = Count + 1; genvar i; generate for (i=0; i<WIDTH; i++) begin : ffc dffeas dffeas ( .d (Next[i]), .clk (Clock), .clrn (Reset_n), .ena (Enable), .asdata (Data[i]), .sload (Load), .q (Count[i]) ); end endgenerate assign CntOut = Count; assign POut = Next[WIDTH]; endmodule И только MWLPM_Counter, как уже говорилось, упаковался компактно. Еще одна особенность - если длина счетчика небольшая (смотрел для приведенного выше счетчика при длине 4 на Cyclone III), то цепи переноса из разряда в разряд не используются.

На то она - модульная структура. Создаете простейший модуль, симулируете, {корректируете, симулируете}, вставляете его в модуль более высокого уровня... По поводу временнОй симуляции - работая с внешними (по отношению к ПЛИС) устройствами на высокой частоте, мне приходилось внимательно рассматривать результаты временнОй симуляции, вставлять дополнительные элементы, чтобы получить желаемое, и при этом надеяться, что так оно будет и в реальном железе.

Середину почитайте!

Смотрю в картинку "Figure 2–5. Cyclone III Family Devices LEs in Arithmetic Mode" (у меня 2-5). Не могу представить, как можно сделать сумматор для счетчика, и обходной путь, когда cnt_en запрещает счет, и выход переноса для следующего разряда. Левый нижний мультиплексор сообще нарисован по-идиотски, что выбирает, чем выбирает? Дальше-то просто - sload, data3, clock, ena. Т.е., возможно, это не глюк, а суровая реальность. P.S. Впрочем, и без cnt_en результат тот же :( Upd. Устройство ЛЭ лучше смотреть в Resource Property Editor (который выскакивает в Chip Planner) - там все видно, как надо. День провозился с последним slon'ом, но так и не смог добиться того, что выдал des00 с использованием dffeas. Хочется верить, что это не глюк, а какая-то логическая нестыковка между Verilog и Cyclone. Вот и получается, что без примитивов перфект-качества не получить?

:bb-offtopic: Небось, не уйдет! Ступившему на эту дорогу, обратного пути нет. Как в мафии. :rolleyes:

Загляните в рядом стоящую ветку "Профессия RTL-дизайнер не имеет будущего". Если дочитаете до конца, наступит просветление :)

Хотел, чтобы загрузка в ACEX шла нулем, согласно архитектуре. Ваш пример работает в Cyclone III быстрее. Наверное, потому, что в Циклон загрузка идет единицей sload . to des00 Посмотрите на картинку для последнего slon'а. По-моему, все проблемы в сигнале cnt_en, который, вообще говоря, хрен знает зачем нужен. Есть же clk_en.

Хотел написать, что у меня сложилось впечатление, что Альтеровцы в Quartus намеренно душат семейства, не рекомендуемые к новым разработкам. Но Stratix IV ??

Видимо, дело, в cout (которого нет у dxp). Потому что последний slon на 24 разряда дает те же 26 "плиток". Приведите свой модуль. Ой, нет - 24 "плитки", 26 было для ACEX.

Если задействовать всё, что можно, в счетчике, то, может быть, "красивенько" уже не уложится. FUNCTION lpm_counter ( -- INPUTS data[LPM_WIDTH-1..0], clock, clk_en, cnt_en, updown, cin, aclr, aset, aconst, aload, sclr, sset, sconst, sload ) WITH ( -- PARAMETERS LPM_WIDTH, LPM_DIRECTION, LPM_MODULUS, LPM_AVALUE, LPM_SVALUE, LPM_PORT_UPDOWN, CARRY_CNT_EN, LABWIDE_SCLR, USE_NEW_VERSION ) RETURNS ( -- OUPUTS q[LPM_WIDTH-1..0], cout, eq[15..0]%, debug_out[6..0]% ); Правда, я уже не совсем понимаю, зачем...

Это - функция, в другом месте была /*! *********************************************************************** * @brief Calculate Number-of-Bits for Number * @details Вычисляет количество разрядов для представления числа * @param Number - число * @return NumBits - количество двоичных разрядов ***********************************************************************/ function integer NumBits (input integer Number); begin NumBits = 0; while (Number) begin NumBits++; Number >>= 1; end end endfunction Приоритетность нарушаю? :unsure:

to dxp Для ACEX попробуйте то же. Сам попробовал :) Все ровненько, только я длину счетчика уменьшил до 32. Значит, ваш пример недостаточно сложный.

Неужто 9.1 хуже? Или, снова... шутка? Смайлик поставьте.

Ну, вот, к примеру. module CountDownReload #(parameter PERIOD = 50000) ( input Reset_n, Clock, Enable, output reg [WIDTH:0] Count ); localparam WIDTH = NumBits(PERIOD-2); always @(negedge Reset_n, posedge Clock) if (!Reset_n) Count = 0; else if (Enable) if (Count[WIDTH]) Count = Count - 1; else Count = (1 << WIDTH) | (PERIOD-2); endmodule Для ACEX получился в виде, как на картинке. Да, сумматор использует переносы, но триггеры черт знает где, выходы берутся с других мест. А вот тот же код, разложенный в Cyclone III, 18 ЛЭ Что сказать: Quartus + Cyclone = Сила! Предыдущие семейства - в топку!

Не знаю, как последний, а Quartus 9.0 тот модуль, что я показал, скушал.

По совету участников обратился к мегафункции LPM_COUNTER, с помощью Визарда создал Verilog модуль, который можно вставлять в свой проект, причем, кое-что можно и менять, например, разрядность. Раскладывается, как положено, быстродействие отличное. Большего мне не надо. Вот он какой, модуль. module MWLPM_Counter ( aclr, clk_en, clock, cnt_en, data, sload, cout, q); input aclr; input clk_en; input clock; input cnt_en; input [23:0] data; input sload; output cout; output [23:0] q; wire sub_wire0; wire [23:0] sub_wire1; wire cout = sub_wire0; wire [23:0] q = sub_wire1[7:0]; lpm_counter lpm_counter_component ( .sload (sload), .clk_en (clk_en), .aclr (aclr), .clock (clock), .data (data), .cnt_en (cnt_en), .cout (sub_wire0), .q (sub_wire1), .aload (1'b0), .aset (1'b0), .cin (1'b1), .eq (), .sclr (1'b0), .sset (1'b0), .updown (1'b1)); defparam lpm_counter_component.lpm_direction = "UP", lpm_counter_component.lpm_port_updown = "PORT_UNUSED", lpm_counter_component.lpm_type = "LPM_COUNTER", lpm_counter_component.lpm_width = 24; endmodule Обращается к lpm_counter. А тот представляет собой AHDL файл, который, я, собственно, и пытался "изобрести". Вывод такой - если хочешь качества - используй LPM, если все равно - пиши по-простому, на Verilog.

Объясняю, что хотел сделать. Вот образец на AHDL. Для ACEX счетчик выстраивается ровненько, с цепями переноса из разряда в разряд и триггерами в тех же ЛЭ. Для Cyclone - уже нет. Хочу сделать подобное на Verilog. Title "Counter with Syncronous Reset"; %-- Library 2005 ViKo -------------------------- Counter with syncronous enable, load, reset direction - increment (default) or decrement carry-out - asyncronous, can be triggered outside Нельзя использовать слишком много индивидуальных загрузок и сбросов - не удастся разложить, не хватит каналов, можно вылететь из-за ошибки. Но можно использовать несколько сигналов для групп. %----------------------------------------------- Parameters ( Wid = 8, -- counter width Dir = "up" -- "down" or "up" ); ------------------------------------------------ Subdesign ViKoCount ( Clk : input; -- Clock Ena : input = Vcc; -- Enable (input_pulse) Dat[Wid-1..0] : input = Gnd; -- Data for load nLd[Wid-1..0] : input = Vcc; -- /Load nRes[Wid-1..0] : input = Vcc; -- /Reset Q[Wid-1..0] : output; -- Outputs P : output; -- Carry output ) ------------------------------------------------ Variable Ct[Wid-1..0] : dff; -- Counter cells Cy[Wid-1..0] : carry; -- Carry nodes ------------------------------------------------ Begin Ct[].clk = Clk; Ct0.d = ((Ct0 $ Ena) & nLd0 # Dat0 & !nLd0) & nRes0; if Dir == "down" generate Cy0 = !Ct0; -- & nRes0; else generate Cy0 = Ct0; -- & nRes0; end generate; for i in 1 to Wid-1 generate Ct[i].d = ((Ct[i] $ (Cy[i-1] & Ena)) & nLd[i] # Dat[i] & !nLd[i]) & nRes[i]; if Dir == "down" generate Cy[i] = !Ct[i] & Cy[i-1]; -- & nRes[i]; else generate Cy[i] = Ct[i] & Cy[i-1]; -- & nRes[i]; end generate; end generate; Q[] = Ct[]; P = Cy[Wid-1]; -- Out with glitch End; Согласен. Попробую и это обязательно. Вот такой код работает. Но это только "полуфабрикат". module CountPrim #(parameter WIDTH = 4) ( input Reset_n, Clock, Enable, output [WIDTH-1:0] Count, output POut, input Down ); wire [WIDTH-1:0] Fb; // feedback wire [WIDTH-1:0] Lt; // lookUp table wire [WIDTH-1:0] Cr; // carry out CARRY_SUM Cy0 (.sin(!Fb[0]), .cin(Fb[0] ^ Down), .sout(Lt[0]), .cout(Cr[0])); DFFE Ff0 (.d(Lt[0]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[0])); CARRY_SUM Cy1 (.sin(Fb[1] ^ Cr[0]), .cin((Fb[1] ^ Down) & Cr[0] ), .sout(Lt[1]), .cout(Cr[1])); DFFE Ff1 (.d(Lt[1]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[1])); CARRY_SUM Cy2 (.sin(Fb[2] ^ Cr[1]), .cin((Fb[2] ^ Down) & Cr[1]), .sout(Lt[2]), .cout(Cr[2])); DFFE Ff2 (.d(Lt[2]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[2])); CARRY_SUM Cy3 (.sin(Fb[3] ^ Cr[2]), .cin((Fb[3] ^ Down) & Cr[2]), .sout(Lt[3]), .cout(Cr[3])); DFFE Ff3 (.d(Lt[3]), .clk(Clock), .clrn(Reset_n), .prn(1), .ena(Enable), .q(Fb[3])); assign Count = Fb; assign POut = Cr[3]; endmodule

Не пахнет, потому что CARRY_SUM - это просто две цепи, одна ведет через мультиплексоры загрузки, синхронного сброса (зависит от архитектуры ПЛИС) к триггеру или еще куда подальше..., а вторая - цепь переноса, ведет ко входу переноса следующего ЛЭ. А не сумматор, как можно было бы подумать.

Между прочим, в каталоге с установленным Quartus имеется папочка systemc, с кучей файлов (только почему-то одни *.h - заголовки, что ли? или нет, это, кажется и есть файлы проектов, такое у них расширение!) Так что, может быть SystemC уже где-то совсем недалеко?

Я думаю, работа редко бывает впустую. Вот, мы узнали, что CARRY_SUM это просто два повторителя (наверное). Счетчик, "выстроенный в шеренгу", имеет регулярную структуру, предсказуемое быстродействие, близкое к предельному, не зависимые от переукладки проекта. С вашего позволения, я еще немного "потрахаюсь". Если будет результат, доложу.

Это - шутка? Гляньте, какая таблица истинности вышла: CI SI SO CO 0 0 0 0 0 1 1 0 1 0 0 1 1 1 1 1 т.е., CO повторяет CI, SO повторяет SI :) :) :)

По первому - один раз набив шишек, можно потом клепать счетчики сколь угодно раз. У меня есть нечто подобное на AHDL, мне нравится. Сразу видно на Floorplan - вот они, мои счетчики :) По второму - попробую.

Счетчики разные, счетчиков - несколько (5-6), длинные. Я могу написать Count = Count + 1, и все будет нормально. Но хотелось бы получить конкретный ответ на свой вопрос. Что-то я напутал в CARRY_SUM. Смотрел, что-то видел. Но там не было CARRY_SUM. Я понимаю так, что таблица истинности у него следующая: CI SI SO CO 0 0 0 0 0 1 1 0 1 0 1 0 1 1 0 1

...Просто хочется :)... Просто счетчиков будет некоторое количество... остальное уже сказал.