Защелки в FSM Опции

[Fynjisx]

Привет Всем! Является ли использование защелок плохим стилем проектирования в FSM?

[icyrock]

Привет Всем! Является ли использование защелок плохим стилем проектирования в FSM?

На мой взгляд использование защелок никакой проблемы не составляет. У меня половина обычных триггеров, а половина защёлок. Живу и радуюсь - никаких проблем.

А использовать ветку else только для того чтобы написать что триггер должен сохранить свое значение - это только засорять код. От ошибок это не защищает.

[des333]

На мой взгляд использование защелок никакой проблемы не составляет. У меня половина обычных триггеров, а половина защёлок. Живу и радуюсь - никаких проблем.

Главный вопрос: а зачем?

[icyrock]

Главный вопрос: а зачем?

Алгоритмы у меня такие : нужно

[bogaev_roman]

Алгоритмы у меня такие : нужно

А Вы уверены, что в Вашем алгоритме без защелок не обойтись? Все-таки защелки - хитрая вещь и ИМХО лучше без них.
Да и по себе могу сказать - читая чужой код и встречая защелки (особенно в case любят опускать состояния) ну очень настораживает - как бы в неопределенность не погрузиться, особенно если обратная связь.
assign out = in & en | out & !en; - Вот такая то оплошность быстро обнаружиться, а вот если case состояний этак на 100, ну и одно забыли - хана, не обнаружишь.

Сообщение отредактировал bogaev_roman - May 27 2010, 15:17

[icyrock]

А Вы уверены, что в Вашем алгоритме без защелок не обойтись? Все-таки защелки - хитрая вещь и ИМХО лучше без них.
Да и по себе могу сказать - читая чужой код и встречая защелки (особенно в case любят опускать состояния) ну очень настораживает - как бы в неопределенность не погрузиться, особенно если обратная связь.

Вижу в использовании защёлки (когда это требуется) следующие факторы увеличивающие наглядность кода
1. Нет лишней засоряющей пространство ветви else
2. Чем реже меняет значение триггер тем меньше "ряби" и посторонних (промежуточных) значений на симуляции
3. Текст
always @(posedge clk)
if (ce)
dout<=din;
Прямо говорит что меняется значение dout тогда когда ce в единице
4. В принципе можно напрячься и избавиться от защёлок. Но это может привести к тому, что код хоть и будет работать правильно но идею алгоритма придётся расшифровывать внимательно вглядываясь в превращение входных данных в выходные.

[bogaev_roman]

always @(posedge clk)
if (ce)
dout<=din;

Это триггер-защелка (синтезирован будет как обычный триггер). Тока вот теперь ответьте на вопрос что Вы будете делать если будет вложенный оператор
if else if else и забудете первый else поставить? А вообще можно просто написать else ; И насчет читабельности я бы еще поспорил.

Сообщение отредактировал bogaev_roman - May 27 2010, 17:30

[ViKo]

Это триггер-защелка (синтезирован будет как обычный триггер).

Это - не триггер-защелка.
Защелка (Latch) - это триггер, который передает входной сигнал, когда L = 1 (прозрачный), и не передает входной сигнал, когда L = 0. В момент перехода L из 1 в 0 триггер "защелкивает" сигнал, а до этого момента сигнал на выходе мог меняться вместе с входным.

P.S. А для case есть слово default.

[bogaev_roman]

Это - не триггер-защелка.
Защелка (Latch) - это триггер, который передает входной сигнал, когда L = 1 (прозрачный), и не передает входной сигнал, когда L = 0. В момент перехода L из 1 в 0 триггер "защелкивает" сигнал, а до этого момента сигнал на выходе мог меняться вместе с входным.

P.S. А для case есть слово default.

Все-таки откопал из старого форума-конференции - вот собственно тема http://www.telesys.ru/wwwboards/fpga/270/m...ges/21837.shtml
А вот подробное описание отличий - http://www.telesys.ru/wwwboards/fpga/270/m...ges/22311.shtml
Так что то о чем говорил des333 - это latch, то о чем писал я -flip-flop and latch в общем случае, и речь шла немного о разных вещах.
Некоторым лень сознательно ставить default так же как и else - типа читается лучше да и строчек меньше, а потом начинается в крупных проектах "выковыривание" ошибки.
Интересно, а вот сходу скажет кто-нибудь - стандарт рекомендует по стилю вставлять else и default? По-моему рекомендует, хотя и не обязывает...

Сообщение отредактировал bogaev_roman - May 28 2010, 06:24

[des333]

Так что то о чем говорил des333 - это latch, то о чем писал я -flip-flop and latch в общем случае, и речь шла немного о разных вещах.

Ну, я думал, по контексту темы все поняли, что имеется в виду та защелка, которая latch. 

Это не оплошность, а осознанное решение. Ничего плохого в нем нет. Именно - триггер-защелка, применяется часто. Пример - 74HC373 - Octal 3-State Noninverting Transparent Latch.
Бывают защелки "полезные", а бывают "непредусмотренные"

Altera рекомендует не использовать latch вообще.

[ViKo]

Altera рекомендует не использовать latch вообще.

потому что у нее в каждом триггере есть нормальный тактовый вход clk

[des333]

потому что у нее в каждом триггере есть нормальный тактовый вход clk

Не понял.

Разве существуют FPGA, в которых у триггера нет нормального тактового входа?

[ViKo]

Не понял.
Разве существуют FPGA, в которых у триггера нет нормального тактового входа?

Нет, конечно. Поэтому такие же рекомендации будет давать каждый производитель ПЛИС
Когда сигнал изменяется по тактам, можно получить большее быстродействие, чем когда он меняется, когда захочет.
Это (нерекомендация latch) вытекает из неприятия "асинхронщины".

[sazh]

Нет, конечно. Поэтому такие же рекомендации будет давать каждый производитель ПЛИС
Когда сигнал изменяется по тактам, можно получить большее быстродействие, чем когда он меняется, когда захочет.
Это (нерекомендация latch) вытекает из неприятия "асинхронщины".

Потому что выходы latch изначально в неопределенном состоянии. Пока en в 1 единицу не перевести.
За это время много чего пожечь можно.