[D-Luxe 0]

В каких случаях синтезатор ставит защелки?

[Rundll 0]

В каких случаях синтезатор ставит защелки?

 

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

[Shtirlits 0]

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

Если требуется хранить константу по уровню, то получится асинхронный сброс.

Когда нужно запомнить значение сигнала по фронту - регистр.

 

[Bad0512 2]

В каких случаях синтезатор ставит защелки?

Наиболее рапространённая причина появления латчей - когда в сложных конструкциях типа if-else не прописывается поведение выходного сигнала во всех возможных вариантах входных сигналов, например "забывают" описать реакцию на else.

 

[Shtirlits 0]

Причина - стиль изложения схемы, легко допускающий ошибку.

[Maverick_ 15]

к сведению:

если нужно описать константу - пропишите это, т.е. вместо сигнала, пишем констант (VHDL)

[Rundll 0]

Наиболее рапространённая причина появления латчей - когда в сложных конструкциях типа if-else не прописывается поведение выходного сигнала во всех возможных вариантах входных сигналов, например "забывают" описать реакцию на else.

 

Собственно это я и написал))

[zomg 0]

Наиболее рапространённая причина появления латчей - когда в сложных конструкциях типа if-else не прописывается поведение выходного сигнала во всех возможных вариантах входных сигналов, например "забывают" описать реакцию на else.

Добавлю: если операторы if и case не под клоком и не прописывается поведение выходного сигнала во всех возможных вариантах, то будет защелка. Так как в неописанных вариантах нужно выдавать какой-то сигнал, то асинхронная схема будет хранить какое-то предыдущее значение в защелке. У синхронной схемы все понятно - там триггер хранит значение.

[D-Luxe 0]

А что будет если if и case под клоком и не прописывается поведение выходного сигнала во всех возможных вариантах?

[zomg 0]

2 D-Luxe

Если под клоком: значения будут меняться только когда условия в if или case выполняются, иначе не меняются.

Изменено 26 февраля, 2011 пользователем zomg

[Rundll 0]

Добавлю: если операторы if и case не под клоком и не прописывается поведение выходного сигнала во всех возможных вариантах, то будет защелка. Так как в неописанных вариантах нужно выдавать какой-то сигнал, то асинхронная схема будет хранить какое-то предыдущее значение в защелке. У синхронной схемы все понятно - там триггер хранит значение.

 

Но в любом случае, по правилам хорошего тона, так сказать, независимо от того, под клоком конструкция if/case или нет, лучше описывать все возможные случаи или использовать оператор типа when others и т.д.

[zomg 0]

2 Rundll

В принципе, да. Иначе можно случайно защелку сделать.

[Shtirlits 0]

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

Можно представлять, что записи типа a<=a; b<=b; c<=c; присутствуют неявно в начале каждого процесса.

Хотя, чем меньше надо знать (язык, компилятор, окружение, библиотеки) для понимания исходного - тем лучше.

Мне не нравится такая запись где попало внутри case: when 1 => a <= a;

Однако, когда текст большого case организован как наглядная табличка, стоит заполнить все ячейки.

Вобщем, как мне кажется, исходный текст можно оценивать по времени его понимания самым неопытным членом команды.

 

[dvladim 0]

Но в любом случае, по правилам хорошего тона, так сказать, независимо от того, под клоком конструкция if/case или нет, лучше описывать все возможные случаи или использовать оператор типа when others и т.д.

Под клоком писать конструкции типа:

counter <= counter;

значит засорять код.