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

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

:

Собственно, проблема в том, что вместо того, чтобы завести сигнал 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

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

Meteor

HardWareMan писал(а):

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

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

Код:

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

Meteor писал(а):

HardWareMan писал(а):

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

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

Meteor писал(а):

А когда

Код:

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

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

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

Реклама

DX168B

Спасибо за разъяснения. :beer:

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

Реклама

Meteor

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