D-Luxe 0 24 февраля, 2011 Опубликовано 24 февраля, 2011 · Жалоба В каких случаях синтезатор ставит защелки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rundll 0 24 февраля, 2011 Опубликовано 24 февраля, 2011 · Жалоба В каких случаях синтезатор ставит защелки? Например, при использовании условного оператора в котором не были учтены все возможные условия срабатывания схемы, а только лишь некоторые частные случаи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 24 февраля, 2011 Опубликовано 24 февраля, 2011 · Жалоба Синтезатор ставит защелки, когда требуется запомнить значение, не константу, но причиной для этого является не фронт, а уровень. Если требуется хранить константу по уровню, то получится асинхронный сброс. Когда нужно запомнить значение сигнала по фронту - регистр. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Bad0512 2 25 февраля, 2011 Опубликовано 25 февраля, 2011 · Жалоба В каких случаях синтезатор ставит защелки? Наиболее рапространённая причина появления латчей - когда в сложных конструкциях типа if-else не прописывается поведение выходного сигнала во всех возможных вариантах входных сигналов, например "забывают" описать реакцию на else. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 25 февраля, 2011 Опубликовано 25 февраля, 2011 · Жалоба Причина - стиль изложения схемы, легко допускающий ошибку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maverick_ 15 25 февраля, 2011 Опубликовано 25 февраля, 2011 · Жалоба к сведению: если нужно описать константу - пропишите это, т.е. вместо сигнала, пишем констант (VHDL) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rundll 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба Наиболее рапространённая причина появления латчей - когда в сложных конструкциях типа if-else не прописывается поведение выходного сигнала во всех возможных вариантах входных сигналов, например "забывают" описать реакцию на else. Собственно это я и написал)) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zomg 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба Наиболее рапространённая причина появления латчей - когда в сложных конструкциях типа if-else не прописывается поведение выходного сигнала во всех возможных вариантах входных сигналов, например "забывают" описать реакцию на else. Добавлю: если операторы if и case не под клоком и не прописывается поведение выходного сигнала во всех возможных вариантах, то будет защелка. Так как в неописанных вариантах нужно выдавать какой-то сигнал, то асинхронная схема будет хранить какое-то предыдущее значение в защелке. У синхронной схемы все понятно - там триггер хранит значение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
D-Luxe 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба А что будет если if и case под клоком и не прописывается поведение выходного сигнала во всех возможных вариантах? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zomg 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 (изменено) · Жалоба 2 D-Luxe Если под клоком: значения будут меняться только когда условия в if или case выполняются, иначе не меняются. Изменено 26 февраля, 2011 пользователем zomg Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rundll 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба Добавлю: если операторы if и case не под клоком и не прописывается поведение выходного сигнала во всех возможных вариантах, то будет защелка. Так как в неописанных вариантах нужно выдавать какой-то сигнал, то асинхронная схема будет хранить какое-то предыдущее значение в защелке. У синхронной схемы все понятно - там триггер хранит значение. Но в любом случае, по правилам хорошего тона, так сказать, независимо от того, под клоком конструкция if/case или нет, лучше описывать все возможные случаи или использовать оператор типа when others и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zomg 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба 2 Rundll В принципе, да. Иначе можно случайно защелку сделать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба Внутри условия клока описывать все возможные варианты не обязательно, важно лишь знать что делаешь. Можно представлять, что записи типа a<=a; b<=b; c<=c; присутствуют неявно в начале каждого процесса. Хотя, чем меньше надо знать (язык, компилятор, окружение, библиотеки) для понимания исходного - тем лучше. Мне не нравится такая запись где попало внутри case: when 1 => a <= a; Однако, когда текст большого case организован как наглядная табличка, стоит заполнить все ячейки. Вобщем, как мне кажется, исходный текст можно оценивать по времени его понимания самым неопытным членом команды. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dvladim 0 26 февраля, 2011 Опубликовано 26 февраля, 2011 · Жалоба Но в любом случае, по правилам хорошего тона, так сказать, независимо от того, под клоком конструкция if/case или нет, лучше описывать все возможные случаи или использовать оператор типа when others и т.д. Под клоком писать конструкции типа: counter <= counter; значит засорять код. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться