[ViKo 1]

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

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

[Des333 0]

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

 

Не понял.

 

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

[ViKo 1]

Не понял.

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

Нет, конечно. Поэтому такие же рекомендации будет давать каждый производитель ПЛИС :)

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

Это (нерекомендация latch) вытекает из неприятия "асинхронщины".

[sazh 5]

Нет, конечно. Поэтому такие же рекомендации будет давать каждый производитель ПЛИС :)

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

Это (нерекомендация latch) вытекает из неприятия "асинхронщины".

 

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

За это время много чего пожечь можно.

[Maverick_ 15]

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

Я знаю что Xilinx также не рекомендует latch испльзовать.

PS Мое мнение использование latch в проектах для ПЛИС это плохая практика. Должно быть по возможности 100% RTL кодирование и синхронный дизайн (синхронная цифровая схемотехника) без использования асинхронной логики.

[sazh 5]

PS Мое мнение использование latch в проектах для ПЛИС это плохая практика.

 

Например Q-bus (МПИ шина). Асинхронный обмен. В системной шине нет клока. И на ПЛИС ложится.

От протокола обмена зависит. (Хотя это уже история)

[ViKo 1]

Пока быстродействие ПЛИС позволяет делать схему тактированной, так и нужно делать.

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

Одно из известных применений Latch - фиксация адреса по мультиплексированной шине address-data во многих микропроцессорных системах по сигналу ALE. В этом случае адрес на выходе защелки появляется раньше, чем если бы использовался синхронный триггер. Получается больше времени установления для подключенных к шине адреса устройств.

[fars 0]

Коде конвншн для РТЛ, запрещяет использовать защелки, тактирование с разными фронтами и прочее - ибо это есть неправильно и обосновано на ошибках многих зарубежних разработчиков ;)

[dvladim 0]

Интересно, а вот сходу скажет кто-нибудь - стандарт рекомендует по стилю вставлять else и default? По-моему рекомендует, хотя и не обязывает...

Насчет стандарта не скажу, а вот проверка покрытия у Кейденса выдает сообщение если отсутствует default даже если описаны все возможные состояния.

 

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

Если вы имели ввиду что конвейер на триггерах будет быстрее конвейера на латчах, то это не так. В конвейере на латчах предыдущий каскад предоставляет свой временной запас следующему. Это и позволяет при несогласованности стадий конвейера повысить тактовую по сравнению с реализацией на триггерах.

[ViKo 1]

Если вы имели ввиду что конвейер на триггерах будет быстрее конвейера на латчах, то это не так. В конвейере на латчах предыдущий каскад предоставляет свой временной запас следующему. Это и позволяет при несогласованности стадий конвейера повысить тактовую по сравнению с реализацией на триггерах.

Я сомневаюсь. Можно попытаться объяснить теоретически, что предельное быстродействие будет определяться теми же временами предустановки, удержания и распространения. Но лучше попробовать на практике. Если что-то получится, я напишу позже. Возможно, Вы и правы.

В синхронной схеме есть гарантированное время для каждой ступени.

[des00 25]

Я сомневаюсь.

ну и зря, недаром есть проекты по асинхронизации изначально синхронных устройств(например асинхронный пик16 в ~4 раза быстрее синхронного). Рости производительности оправдывает асинхру.

[murmel1 0]

есть проекты по асинхронизации изначально синхронных устройств

Ссылочку не дадите ли ?

ИМХО, для создания больших асинхронных схем требуется язык, описывающий порядок срабатывания. HDL позволяет описывать порядок срабатывания только по тактам.

[Des333 0]

ИМХО, для создания больших асинхронных схем требуется язык, описывающий порядок срабатывания. HDL позволяет описывать порядок срабатывания только по тактам.

Поясните, если не сложно.

 

 

Как это должно выглядеть в схематике? И что конкретно Вы хотите добавить к возможностям HDL, чтобы это описать?

[des00 25]

Ссылочку не дадите ли ?

гугл всё знает

dlx

arm

еще арм

[Des333 0]

гугл всё знает

dlx

arm

еще арм

 

Перехожу на асинхронщину