Тернарный оператор VS конструкция if-else, Какова логика языка? Почему одно не заменяет другое? Опции

[flammmable]

Предположим, есть конечный автомат, который в работе должен пробрасывать тактовую частоту через себя, а в состоянии IDLE установить выход тактовой частоты в единицу.

Тогда код может быть следующий:

Код

wire clk_in;
wire clk_out;
reg state;

assign clk_out = clk_in | ~(state^IDLE);

Т.е. если state и IDLE совпадают бит-в-бит, то их побитовый XOR будет равен нулю. Инвертированный ноль - это единица. Единица или clk_in - единица. В противном случае, ноль или clk_in - это clk_in.
Всё абсолютно прозрачно синтезируется.

Или код может быть такой:

Код

wire clk_in;
wire clk_out;
reg state;

assign clk_out = clk_in | (state == IDLE);//На месте синтезатора я заменил бы данную конструкцию на предыдущую

Или такой:

Код

wire clk_in;
wire clk_out;
reg state;

assign clk_out =(state == IDLE) ? 1 : clk_in;

Но почему не прокатывает следующий вариант?

Код

wire clk_in;
wire clk_out;
reg state;

always @(state)
begin
if(state == IDLE) begin
  clk_out = 1;
end
else begin
  clk_out = clk_in;
end
end

В таком варианте Квартус ругается на то, что "10137: Object on left-hand side of assignment must have a variable data type".

Не, ну нельзя, так - нельзя. Но эмм... в списке чувствительности отсутствуют posedge/negedge. В любом случае, синтезатор будет разворачивать эту конструкцию в комбинационную логику (причем, скорее всего в такую, как в первом примере). Так чего же он лезет на рожон (регистр ему подавай)? Какова логика языка? Почему так писать некорректно?

[dima32rus]

Ну вот такой теоретический пример

CODE

module cnt_test
(
//Global
input CLK_i ,
input nRESET_i ,

//Input
input IN_PULSE0_i ,
input IN_PULSE1_i ,

//Control
input ENA_CNT_i ,
input CLR_CNT_i ,

//Output of counter
output [31:0] OUT_CNT0_o32 ,
output [31:0] OUT_CNT1_o32
);

reg [31:0] out_cnt0_o32;
reg [31:0] out_cnt1_o32;
assign OUT_CNT0_o32 = out_cnt0_o32;
assign OUT_CNT1_o32 = out_cnt1_o32;

reg [7:0] state; //FSM
localparam integer sIDLE = 0,
sCOUNT = 1,
sSTOP = 2;

reg cnt_1_en;
reg cnt_1_clr;

always @(posedge CLK_i or negedge nRESET_i)
begin
if(~nRESET_i)
begin
out_cnt0_o32 <= 0;
cnt_1_en <= 0;
cnt_1_clr <= 0;
state <= sIDLE;
end
else
begin
case(state)

sIDLE:
begin
cnt_1_clr <= 0;
if(ENA_CNT_i)
state <= sCOUNT;
end

sCOUNT:
begin
if(ENA_CNT_i)
begin
if(IN_PULSE_i)
begin
out_cnt0_o32 <= out_cnt0_o32 + 1'b1;
cnt_1_en <= 1'b1;
end
else
cnt_1_en <= 0;
end
else
begin
cnt_1_en <= 0;
state <= sSTOP;
end
end

sSTOP:
begin
state <= sIDLE;
if(CLR_CNT_i)
begin
out_cnt0_o32 <= 0;
cnt_1_clr <= 1'b1;
end
end

endcase
end

end

always @(posedge CLK_i or negedge nRESET_i)
begin
if(~nRESET_i)
begin
out_cnt1_o32 <= 0;
end
else
begin
if(cnt_1_en)
out_cnt1_o32 <= out_cnt1_o32 + 1'b1;
else if(cnt_1_clr)
out_cnt1_o32 <= 0;
end
end

endmodule

Два счетчика. Один работает напрямую из автомата, второй через сигналы разрешения и сброса.
Насчет упрощения кода при выносе счетчика из автомата я ошибся - проще не получилось. Для работы встроенного счетчика достаточно всего двух строк. Выносного счетчика - целых 5. Вынос счетчика усложнил код.
Плюс на выносной счетчик будет работать с задержкой в один такт. И это надо учитывать там, где критично.
Но с точки зрения времянок выносной счетчик выиграет. Как раз за счет промежуточных триггеров на сигналах разрешения/сброса.
На практике я это не проверял, это просто рассуждения.

Warning from admin:Используйте codebox для оформления длинных блоков кода. Не загромождайте сообщения!

Сообщение отредактировал makc - Jun 8 2018, 10:27

Причина редактирования: предупреждение про codebox

[RobFPGA]

Приветствую!

...
Два счетчика. Один работает напрямую из автомата, второй через сигналы разрешения и сброса.
Насчет упрощения кода при выносе счетчика из автомата я ошибся - проще не получилось. Для работы встроенного счетчика достаточно всего двух строк. Выносного счетчика - целых 5. Вынос счетчика усложнил код.

И это еще простой случай - а если еще надо загружать разные счетчики разными значениями и считать их вверх/вниз/поперек?

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

Вот оно что - понятное дело если вы пропускаете сигналы управления через регистр то это уменьшает времянку - но это ведь разная логика работы счетчиков!!! При чем тут реализация счетчиков в FSM?

Удачи! Rob.

[dima32rus]

Вот оно что - понятное дело если вы пропускаете сигналы управления через регистр то это уменьшает времянку - но это ведь разная логика работы счетчиков!!! При чем тут реализация счетчиков в FSM?

Согласен, если через триггеры не пропускать, то, наверное, особой разницы в реализации не будет.

Упрощается автомат - банально меньше писанины. И вместо инкрементирования счетчика внутри автомата - автомат выдает сигнал разрешения работы счетчику.

Получается, наоборот. Если счетчик внутри автомата - достаточно просто одной строчкой делать инкремент там, где это надо. Если счетчик выносим, то надо выдать сигнал разрешения, а потом его еще снять. Получается 2 и более строк кода на одну только функцию. А еще есть сброс, загрузка...