Тернарный оператор 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. В любом случае, синтезатор будет разворачивать эту конструкцию в комбинационную логику (причем, скорее всего в такую, как в первом примере). Так чего же он лезет на рожон (регистр ему подавай)? Какова логика языка? Почему так писать некорректно?

[Flip-fl0p]

1. Я бы вообще никаких манипуляций с частотой не производил.
2. Если уж так нужно, обратите внимание на: altera clkctrl

[iosifk]

1. Я бы вообще никаких манипуляций с частотой не производил.
2. Если уж так нужно, обратите внимание на: altera clkctrl

Без обид.
Смотрите внимательно, то что я напишу.
Для одних - ПЛИС это кусок хлеба. И форум - это товарищи, которые помогают начать прилично зарабатывать. Поэтому их советы ценятся. Потому что на работе надо давать результат, иначе не будет зарплаты, причем результат нужен каждый день, а не когда-то потом. И я помню, что сам был в такой же ситуации. До этого я писал на VHDL, пришел на новую работу и там сказали - только Verilog. И я учился "в бою". И мне абсолютно некогда было "изобретать художества". Брал проверенные шаблоны и из них делал код, в том числе и по выходным, чтобы успеть.
А для других ПЛИС - это игра. Им результат как таковой не нужен. Они "проводят изыскания" в кусках кода, в "триггерах, нарисованных вьюерами" и т.д. Им советы, выдаваемые на форуме вроде как и нужны, но они все равно все сделают по-своему, "через Альпы".
Вот так и здесь. Есть основы:
клоки не изобретать и проект делать синхронным;
"внутри автоматов не плодить счетчики и не делать клоки.

И это написано практически во всех руководствах. Ну и что? Это же так интересно, написать что-то принципиально "свое", а потом задавать об этом вопросы на форуме. Чтобы все, кто готов помочь, бросились объяснять очевидные вещи.
Беда в том, что правильный ответ игруну вообще не нужен, потому что он быстро приводит к правильному результату. Тут как раз все надо делать все совершенно наоборот. Надо дать ссылку на кучу литературы, на методики, на головоломные статьи. Так чтобы до результата стало как можно дальше. Тогда игрун ощутит себя бесконечно крутым.
Вот как-то так....

[Viktuar]

Вот так и здесь. Есть основы:
клоки не изобретать и проект делать синхронным;
"внутри автоматов не плодить счетчики и не делать клоки.

Простите, а что плохого в счетчиках внутри автоматов?

инициализация регистров при запуске ПЛИС "в железе". На сколько понял читая материалы в сети, в 90-е регистры инициализировались исключительно нулями. Сейчас ситуация поменялась, но ряд комментаторов по старой памяти утверждают, что это невозможно и сами не используют эту удобную опцию.

Я сам с Альтерой не работал, но слышал, что там до сих пор инициализация только нулями. У lattice тоже не у всех семейств поддерживается инициализация.

[iosifk]

Простите, а что плохого в счетчиках внутри автоматов?

Синхронный проект должен работать по клокам.
Если Вы из автомата даете только одиин сигнал разрешения, то счетчик и будет работать по клокам. И по разрядам счетчика разойдется только один сигнал...
А если при описании автомата, Вы запихиваете счетчик "внутрь" комбинационной части, то что будет подано на тактовые входы счетчика? Но даже если компилятор сообразит подать туда клоки, то все равно, к комбинационной части добавятся еще N разрядов счетчика. И все это надо будет уложить в период тактовой частоты.
Поэтому я так стараюсь никогда не делать.
Вообще, примите методу проектирования, когда автомат только роздает управляющие воздействия и более ничего.
И тогда проект становится значительно легче. Вы делаете "исполнительные узлы" и потом в нужные моменты времени автоматом только даете управляющие воздействия.
Если хотите, то могу росказать подробнее.

[RobFPGA]

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

Синхронный проект должен работать по клокам.
Если Вы из автомата даете только одиин сигнал разрешения, то счетчик и будет работать по клокам. И по разрядам счетчика разойдется только один сигнал...
А если при описании автомата, Вы запихиваете счетчик "внутрь" комбинационной части, то что будет подано на тактовые входы счетчика? Но даже если компилятор сообразит подать туда клоки, то все равно, к комбинационной части добавятся еще N разрядов счетчика. И все это надо будет уложить в период тактовой частоты.
Поэтому я так стараюсь никогда не делать.

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

Успехов! Rob.

[dima32rus]

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

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