Перейти к содержанию
    

Конечный автомат в Quartus

У меня получилось, что конечный автомат с 16-ю состояниями реализован на 16 триггерах. Очевидно, на самом деле достаточно 4-х. При создании автомата использовал штатный редактор конечных автоматов Quartus с последующей генерацией VHDL- описания.

Поделитесь, кто делал: у вас то же самое?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня получилось, что конечный автомат с 16-ю состояниями реализован на 16 триггерах. Очевидно, на самом деле достаточно 4-х. При создании автомата использовал штатный редактор конечных автоматов Quartus с последующей генерацией VHDL- описания.

Поделитесь, кто делал: у вас то же самое?

В случае, если при синтезе ваша FSM была определена синтезатором как one-hot, то всё правильно, 16 триггеров - это ожидаемо.

 

Объясните, почему вы считаете, что очевидно достаточно 4-х?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В случае, если при синтезе ваша FSM была определена синтезатором как one-hot, то всё правильно, 16 триггеров - это ожидаемо.

 

Объясните, почему вы считаете, что очевидно достаточно 4-х?

Потому что 4 двоичных разряда описывают 16 различных состояний. А что такое one-hot?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

существуют различные способы хранения состояния FSM: binary, one-hot, gray и т.д.

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

к примеру, то, что вы сейчас ожидаете - это binary encoding. Этот вид обеспечивает минимальное задействование регистров, но значительное количество логики для сравнения/выбора следующего состояния, что негативно сказывается на количестве LUT. т.е. по FF - выигрыш, по LUT - проигрыш

если использовать one-hot - то по FF - проигрыш, зато по количеству LUT - выигрыш.

при этом по количеству занимаемых ALM (т.е. ячеек LUT+FF) - занимаемое место примерно одинаково

однако вариант one-hot имеет существенно более высокий потолок по скорости реализации (тактовой частоте). binary encoding как правило существенно медленнее.

 

если необходимо снижать энергопотребление - то применяется gray encoding. т.е. изменение состояния, которое по статистике имеет максимальную вероятность перехода, обеспечивает минимальное количество переключающихся регистров. в этом случае и регистров =2*M и логики много, но энергопотребление минимально.

 

кроме того, существует так называемые safe и unsafe FSM.

отличаются тем, восстанавливаются ли они при вхождении в "запрещенное" состояние. т.е. например для one-hot - любое состояние, где в "1" выставляется более 1-го регистра состояния FSM - является запрещенным.

в binary encoding таким состоянием может быть любое неописанное, например вы объявили 4 бита, но состояний, в которые реально может попасть автомат - не более 12. т.е. имеем 4 запрещенных состояния.

реализация safe FSM позволяет при вхождении в запрещенное состояние выйти из него в состояние сброса, и далее по алгоритму. в противном случае у вас получается unsafe FSM и при случайном либо нет вхождении в запрещенное состояние выход из него невозможен, т.е. требуется power-cycle (вкл-выкл) устройства.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А это точно все триггеры состояний? Может там триггеры на выходах?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А это точно все триггеры состояний? Может там триггеры на выходах?

Зачем автомату нужны " триггеры на выходах", если состояние сигналов автомата уже зафиксировано регистром автомата?

Другое дело, что начинать изучение Верилога надо не с Квартуса, а с МоделСима. Ведь Квартус, если ему не сказать о том, что требуется только RTL без привязки к кристаллу, будет работать гораздо медленнее...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Здравствуйте, недавно заинтересовался этой темой поплотнее... но не могу найти хорошего материала. Везде пишут мол используйте стиль кода предлагаемый производителем софта и всё будет в ажуре. Не могли бы Вы посоветовать какую нибудь литературу?

Изменено пользователем Грендайзер

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Здравствуйте, недавно заинтересовался этой темой поплотнее... но не могу найти хорошего материала. Везде пишут мол используйте стиль кода предлагаемый производителем софта и всё будет в ажуре. Не могли бы Вы посоветовать какую нибудь литературу?

Читайте отца-основателя Сазерленда на его сайте...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зачем автомату нужны " триггеры на выходах", если состояние сигналов автомата уже зафиксировано регистром автомата?

Другое дело, что начинать изучение Верилога надо не с Квартуса, а с МоделСима. Ведь Квартус, если ему не сказать о том, что требуется только RTL без привязки к кристаллу, будет работать гораздо медленнее...

Всё зависит от написания. Так как код не приведён - приходится гадать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Читайте отца-основателя Сазерленда на его сайте...

Спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Альтера кстати любит оне хот автоматы по умолчанию, потому у ТС и 16 регистриков получилось:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Альтера кстати любит оне хот автоматы по умолчанию, потому у ТС и 16 регистриков получилось:)

а если "подсказать" синтезатору, типа так:

module enum_fsm (input clk, reset, input int data[3:0], output int o);
enum int unsigned { S0 = 0, S1 = 2, S2 = 4, S3 = 8 } state, next_state;
always_comb begin : next_state_logic
   next_state = S0;
   case(state)
       S0: next_state = S1;
       S1: next_state = S2;
       S2: next_state = S3;
       S3: next_state = S3;
   endcase
end
always_comb begin
   case(state)
       S0: o = data[3];
       S1: o = data[2];
       S2: o = data[1];
       S3: o = data[0];
   endcase
end
always_ff@(posedge clk or negedge reset) begin
   if(~reset)
       state <= S0;
   else
       state <= next_state;
end
endmodule

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

(* syn_encoding = "user" *) reg [1:0] state;

For convenience, the Quartus II software accepts six encoding styles:

 

"default"— Choose an encoding based on the number of states in the enumeration type. If there are fewer than five states, use the "sequential" encoding. If there are more than five but fewer than 50 states, use a "one-hot" encoding. Otherwise, use a "gray" encoding.

 

"one-hot"— The default encoding style requiring N bits, where N is the number of states in the enumeration type.

 

"sequential"— Use a binary encoding in which the first state in the enumeration type has encoding 0, the second 1, and so on.

 

"gray"— Use an M-bit encoding in which the encodings for adjacent states differ by exactly one bit. An M-bit "gray" code can represent 2M states.

 

"johnson"—Use an M-bit encoding in which the encodings for adjacent states differ by exactly one bit. An M-bit "johnson" code can represent at most 2 times M states but requires less logic than a "gray" encoding.

 

"compact"— Use an encoding with fewest bits.

 

"user"— Encode each state using its value in the Verilog source. You can change the encoding of your state machine by changing the values of your state constants, .

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для прочтения в книжном виде, по конечным автоматам, могу посоветовать

 

FSM-based Digital Design using Verilog HDL

Peter Minns, Ian Elliott

Northumbria University, UK

John Wiley & Sons Ltd

ISBN 978-0470-06070-4

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для прочтения в книжном виде, по конечным автоматам, могу посоветовать

Спасибо, уже качаю!

P.S. Исключительно в целях ознакомления :biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...