Тернарный оператор 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

[Flip-fl0p]

Да собственно с точки зрения синтезатора - ему без разницы где счетчик описан. Внутри FSM, или снаружи. Лично проверял когда только-только начинал изучать FPGA. Выдача сигнала разрешения автоматом, либо счет счетчика в каком-то из состояний синтезируются в одно и тоже.
Тут дело в другом, как я считаю. При стиле описания "все в одном":
1. Легче допустить ошибку в описании счетчика - и сложнее её обнаружить.
2. Увеличивается количество строк кода, что неизменно ухудшает его читаемость. Да и документировать такой код становится несколько сложнее. А документирование кода очень, и очень важная составляющая HDL проектов.
3. Увеличивается время отладки. Ибо чем больше строк в коде - тем дольше этот код отлаживать.
При стиле описания "Автомат управляет счетчиком":
1. Легче описывать автомат, т.е нет необходимости описывать счетчики. Счетчик пишется один раз, и далее используется повторно.
2. Упрощается автомат - банально меньше писанины. И вместо инкрементирования счетчика внутри автомата - автомат выдает сигнал разрешения работы счетчику.
3. Упрощается тестирование - не работает счтчик, значит проблема в автомате. Проще найти ошибку.
4. Отдельному описанию счетчика можно задать кучу параметров: остановка счета при максимальном значении, максимальное значение счета, направление счета, вывод своего состояния на консоль и пр. И главное - счетчик описан один раз, и дальше повторно используется, и совершенствуется добавлением новых параметров.
При таком подходе - мы имеем собственную проверенную библиотеку, которая имеет 100% работоспособность. И из этой библиотеки мы собираем свои проекты как из конструктора. За счет всевозможных настроек имеем большую гибкость, и уменьшение вероятности совершить "глупую" ошибку, которую, как правило, найти сложнее всего. Я от такого подхода вижу только полюсы.

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

Обычный счетчик с синхронной загрузкой, и сигналом разрешения загрузки. Автомат выдает сигнал разрешения загрузки и выдает данные, которые надо загрузить.