Quartus II Verilog - синтезируется лишний компонент

[DX168B]

Всем доброго дня. Уже долго бьюсь над проблемой.
Имеем такой вот код (пятиразрядный счетчик):

Код: Выделить всё

// memsel counter
reg[4:0] memsel_cnt;
always @(posedge clock or posedge reset or posedge outshift_enable) begin
	if((reset == 1'b1) || (outshift_enable == 1'b1)) begin
		memsel_cnt <= 5'd0;
	end else begin
		if(mac_run == 1'b1) begin
			memsel_cnt <= memsel_cnt + 1'b1;
		end
	end
end

Впрочем, в проекте их три (и будет еще один). И все они в результате синтезируются
в такое нечто :

Собственно, проблема в том, что вместо того, чтобы завести сигнал mac_run на входы
разрешения (ENA) триггеров memsel_cnt, Quartus фпихуивает мультиплексор между сумматором и триггерами
и замыкает с его помощью выходы триггеров на их же входы при значении управляющего сигнала mac_run=0.
Следует обратить внимание, что этот счетчик сбрасывается по двум сигналам, но есть еще
два, которые сбрасываются только общим ресетом. И они тоже синтезируются с мультиплексорами.
Что я делаю не так? Может какие-то настройки проекта покрутил, или мануал по Verilog не дочитал?

[HardWareMan]

Это называется синхронным дизайном. Т.е., ошибки нет.

[DX168B]

Да, дизайн синхронный.
Где-то мне попадалось утверждение, что D триггер с разрешающим входом и триггер без него,
но с мультиплексором на входе являются эквивалентными. Смутило то, что есть участок схемы в этом проекте,
где синтезатор явно использовал вход разрешения записи. Вот тут, к примеру:

Код: Выделить всё

   reg [31:0] results [3:0];
	always @(posedge clock or posedge reset) begin
		if(reset == 1'b1) begin
			results[0] <= 0;
			results[1] <= 0;
			results[2] <= 0;
			results[3] <= 0;
		end else begin
			if(outshift_enable == 1'b1) begin
				results[3] <= results[2];
				results[2] <= results[1];
				results[1] <= results[0];
				results[0] <= mac_result;
			end
		end
	end
	
	// Output
	reg[31:0] summ_out;
	always @(*) begin
		summ_out = results[0] + results[1] + results[2] + results[3];
	end

Все разрешающие сигналы генерируются одним конечным автоматом, выходы автомата синхронизированы тактовым сигналом всего узла.
Как и когда синтезатор принимает решение о том, как реализовать триггер с разрешением, ума не приложу.

[Meteor]

Как и когда синтезатор принимает решение о том, как реализовать триггер с разрешением, ума не приложу.

Получается если в коде

Код: Выделить всё

if(outshift_enable == 1'b1) begin
            results[3] <= results[2];
            results[2] <= results[1];
            results[1] <= results[0];
            results[0] <= mac_result;
         end

простое присваивание, то делает вход разрешения.
А когда

Код: Выделить всё

if(mac_run == 1'b1) begin
         memsel_cnt <= memsel_cnt + 1'b1;
      end

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

[HardWareMan]

[uquote="Meteor",url="/forum/viewtopic.php?p=4106427#p4106427"]

Как и когда синтезатор принимает решение о том, как реализовать триггер с разрешением, ума не приложу.

[/uquote]
Meteor, вы ошиблись с автором в цитате. Это не мои слова.

[uquote="Meteor",url="/forum/viewtopic.php?p=4106427#p4106427"]А когда

Код: Выделить всё

if(mac_run == 1'b1) begin
         memsel_cnt <= memsel_cnt + 1'b1;
      end

действие (сложение в этом варианте), то он ставит мультиплексор, видимо считая что в альтернативной ветке (отсутствующая else) данные должны храниться методом гонения с выхода на вход...[/uquote]
Так точно. Потому что считается, что синхронный триггер записывает вход каждый такт. И этот такт явно может быть гораздо чаще, чем смена сигнала чувствительности в условии.

[DX168B]

Спасибо за разъяснения.
Теперь понял, в чем таки были отличия.

[Meteor]

Meteor, вы ошиблись с автором в цитате. Это не мои слова..[/quote]
Прошу прощения, пес попутал...